On Oct 11, 2007, at 12:52 PM, Paul McNett wrote:
> Added a private attribute to dGrid to determine whether to mediate
> bizobj row changes through the form (True, the default) or through
> the bizobj directly. Setting _mediateRowNumberThroughForm to False
> completely removed the flickering on Windows for my grids, and I
> don't have any particular need for the form mediation. We can
> discuss whether to make this a property, or whether to take away
> form mediation completely (I haven't thought this through, so I
> don't know what my opinion is), or perhaps we can clean up
> dForm._moveToRowNum() enough so that it doesn't cause such a
> performance hit. For now, the attribute provides a way for me to
> provide a better-performing grid to my customer.
OK, I understand the need for a quick fix, but we need to find out
what it is in the form method that is causing the flicker, since all
that the form code does is call _moveRecordPointer(), which is the
underlying code for all record navigation, such as next(), last(),
etc. I'm assuming that those methods would cause the same flicker,
since it's running the same code.
The main points that could be causing the flicker are:
- the call to form.activeControlValid()
- the call to form.update()
- the delayed call to dabo.ui.callAfter(self.raiseEvent,
dEvents.RowNumChanged)
Try this: keep the attribute set as is, so that there is no flicker.
Then add each of the above calls one at a time to the grid code, in
order to see which re-introduces the flicker. We can then focus on
improving or side-stepping that call, so that we don't have the
potential for the UI being out-of-sync with the data.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
Searchable Archives: http://leafe.com/archives/search/dabo-dev
This message: http://leafe.com/archives/byMID/dabo-dev/[EMAIL PROTECTED]
