|
Author: Paul McNett <p .AT. ulmcnett .D.O.T com>
Subject: [dabo-dev] dabo Commit 3455
Posted: 2007/10/11 11:52:55
dabo Commit
Revision 3455
Date: 2007-10-11 09:52:55 -0700 (Thu, 11 Oct 2007)
Author: Paul
Trac: http://svn.dabodev.com/trac/dabo/changeset/3455
Changed:
U trunk/dabo/ui/uiwx/dGrid.py
Log:
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.
Diff:
Modified: trunk/dabo/ui/uiwx/dGrid.py
===================================================================
--- trunk/dabo/ui/uiwx/dGrid.py 2007-10-11 15:21:02 UTC (rev 3454)
+++ trunk/dabo/ui/uiwx/dGrid.py 2007-10-11 16:52:55 UTC (rev 3455)
@@ -1612,6 +1612,9 @@
# Local count of rows in the data table
self._tableRows = 0
+ # When user selects new row, does the form have responsibility for making the change?
+ self._mediateRowNumberThroughForm = True
+
# Used to provide 'data' when the DataSet is empty.
self.emptyRowsToAdd = 0
@@ -3091,7 +3094,7 @@
bizobj = self.getBizobj()
if bizobj:
if bizobj.RowCount > newRow and bizobj.RowNumber != newRow:
- if isinstance(self.Form, dabo.ui.dForm) and not isinstance(self.DataSource, dabo.biz.dBizobj):
+ if self._mediateRowNumberThroughForm and isinstance(self.Form, dabo.ui.dForm) and not isinstance(self.DataSource, dabo.biz.dBizobj):
# run it through the form:
if not self.Form.moveToRowNumber(newRow, bizobj.DataSource):
dabo.ui.callAfter(self.refresh)
©2007 Paul McNett |
|
|
Author: Ed Leafe <ed At leafe D.OT com>
Subject: Re: [dabo-dev] dabo Commit 3455
Posted: 2007/10/11 14:24:39
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
©2007 Ed Leafe |
|
|
Author: Paul McNett <p (AT) ulmcnett DO.T com>
Subject: Re: [dabo-dev] dabo Commit 3455
Posted: 2007/10/11 15:49:04
Ed Leafe wrote:
> 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(),
Yep.
> etc. I'm assuming that those methods would cause the same flicker,
> since it's running the same code.
Just tested, and yes, same flicker. It just gets overlooked because when
you are changing records, you expect updating to take place. But it does
flicker.
> 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.
Ok, my money is on form.update(), but here goes.
...time passes...
Yes, I tried all combinations of comme
©2007 Paul McNett |
|
|
Author: Ed Leafe <ed At leafe .D.OT com>
Subject: Re: [dabo-dev] dabo Commit 3455
Posted: 2007/10/12 07:18:26
On Oct 11, 2007, at 4:49 PM, Paul McNett wrote:
> Yes, I tried all combinations of commenting/uncommenting those three
> calls, and the flickering hinges completely on the form.update() call.
Just for kicks, I modified dForm.py so that its update() method had
'return' as its first line, and ran SimpBiz. I still got flickering
when either using the keyboard or the next/prev buttons to change rows.
I then opened up a command window and typed:
f, g = dabo.ui.browse(self.PrimaryBizobj)
...to get a non-datanav grid with the exact same data. Navigating
through this grid I did not see any flickering at all. Calling f.next
() likewise did not show flicker. The key must be in the interaction
between the form, bizobj and grid under Windows.
I also tried doing some event logging, and I see multiple
GridRangeSelected events. I'll look into that aspect, too.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
©2007 Ed Leafe |
|
|
Author: Paul McNett <p /AT/ ulmcnett .DO.T com>
Subject: Re: [dabo-dev] dabo Commit 3455
Posted: 2007/10/12 08:15:38
Ed Leafe wrote:
> On Oct 11, 2007, at 4:49 PM, Paul McNett wrote:
>
>> Yes, I tried all combinations of commenting/uncommenting those three
>> calls, and the flickering hinges completely on the form.update() call.
>
> Just for kicks, I modified dForm.py so that its update() method had
> 'return' as its first line, and ran SimpBiz. I still got flickering
> when either using the keyboard or the next/prev buttons to change rows.
That is indeed unexpected. I wonder if it is being called many times?
> I then opened up a command window and typed:
>
> f, g = dabo.ui.browse(self.PrimaryBizobj)
>
> ...to get a non-datanav grid with the exact same data. Navigating
> through this grid I did not see any flickering at all. Calling f.next
> () likewise did not show flicker. The key must be in the interaction
> between the form, bizobj and grid under Windows.
You were inadvertently avoiding form mediation, because PrimaryBizobj is
a reference to a biz, not a DataSource string.
> I also tried doing some event logging, and I see multiple
> GridRangeSelected events. I'll look into that aspect, too.
Cool.
--
pkm ~ http://paulmcnett.com
©2007 Paul McNett |
|
|
Author: Ed Leafe <ed .at. leafe .D.O.T com>
Subject: Re: [dabo-dev] dabo Commit 3455
Posted: 2007/10/12 08:27:58
On Oct 12, 2007, at 9:15 AM, Paul McNett wrote:
>> I then opened up a command window and typed:
>>
>> f, g = dabo.ui.browse(self.PrimaryBizobj)
>>
>> ...to get a non-datanav grid with the exact same data. Navigating
>> through this grid I did not see any flickering at all. Calling f.next
>> () likewise did not show flicker. The key must be in the interaction
>> between the form, bizobj and grid under Windows.
>
> You were inadvertently avoiding form mediation, because
> PrimaryBizobj is
> a reference to a biz, not a DataSource string.
But that was my point: passing any object with a getDataSet() method
to browse() gets the dataset and displays it; nothing else is going
on there. I doubt that the one extra step that would happen by
resolving a string DataSouce (two quick 'if' statements and a get())
would be responsible for visual flickering.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
©2007 Ed Leafe |
|
|
Author: Paul McNett <p (at) ulmcnett D.OT com>
Subject: Re: [dabo-dev] dabo Commit 3455
Posted: 2007/10/12 09:40:48
Ed Leafe wrote:
> On Oct 12, 2007, at 9:15 AM, Paul McNett wrote:
>
>>> I then opened up a command window and typed:
>>>
>>> f, g = dabo.ui.browse(self.PrimaryBizobj)
>>>
>>> ...to get a non-datanav grid with the exact same data. Navigating
>>> through this grid I did not see any flickering at all. Calling f.next
>>> () likewise did not show flicker. The key must be in the interaction
>>> between the form, bizobj and grid under Windows.
>> You were inadvertently avoiding form mediation, because
>> PrimaryBizobj is
>> a reference to a biz, not a DataSource string.
>
> But that was my point: passing any object with a getDataSet() method
> to browse() gets the dataset and displays it; nothing else is going
> on there. I doubt that the one extra step that would happen by
> resolving a string DataSouce (two quick 'if' statements and a get())
> would be responsible for visual flickering.
The difference is how dGrid handles each case: if grid.DataSource is an
actual bizobj reference, form mediation doesn't happen so form.update()
doesn't get called. But if grid.DataSource is a string referring to a
grid's DataSource that is registered with the form, then form mediation
occurs and form.update() is called.
The browse example is actually a third case, I think, since the grid's
DataSet property was set instead of DataSource. So, there isn't a
bizobj.RowNumber to change. But this case also bypasses form.update().
form.update() is the culprit of the flickering, we've already
established that. All I was saying above was that you were getting
around the form.update() call by using browse().
--
pkm ~ http://paulmcnett.com
©2007 Paul McNett |
|
|
Author: Ed Leafe <ed /at/ leafe D.OT com>
Subject: Re: [dabo-dev] dabo Commit 3455
Posted: 2007/10/12 10:04:48
On Oct 12, 2007, at 10:40 AM, Paul McNett wrote:
> form.update() is the culprit of the flickering, we've already
> established that. All I was saying above was that you were getting
> around the form.update() call by using browse().
Did you try what I originally reported:
>> Just for kicks, I modified dForm.py so that its update() method had
>> 'return' as its first line, and ran SimpBiz. I still got flickering
>> when either using the keyboard or the next/prev buttons to change
>> rows.
That's why I'm wondering if it is the update method at all. It could
be something in the datanav/2 framework, such as the Page class's
updateGrid() method.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
©2007 Ed Leafe |
|
|
Author: Paul McNett <p (AT) ulmcnett DOT com>
Subject: Re: [dabo-dev] dabo Commit 3455
Posted: 2007/10/12 10:37:19
Ed Leafe wrote:
> On Oct 12, 2007, at 10:40 AM, Paul McNett wrote:
>
>> form.update() is the culprit of the flickering, we've already
>> established that. All I was saying above was that you were getting
>> around the form.update() call by using browse().
>
> Did you try what I originally reported:
>
>>> Just for kicks, I modified dForm.py so that its update() method had
>>> 'return' as its first line, and ran SimpBiz. I still got flickering
>>> when either using the keyboard or the next/prev buttons to change
>>> rows.
>
> That's why I'm wondering if it is the update method at all. It could
> be something in the datanav/2 framework, such as the Page class's
> updateGrid() method.
Ok, I concede that it could be that: dForm.update() results in all
contained objects getting updated, and something in datanav is causing
problems.
--
pkm ~ http://paulmcnett.com
©2007 Paul McNett |
|
|
|
