On 10/28/11 7:26 AM, Jacek Kałucki wrote:
> Użytkownik Paul McNett napisał:
>> Well I'm getting much better performance. Child bizobjs are requeried*after*
>> the
>> delay. Try setting your delay to more like 250 - the default of 100 was too
>> short in
>> my experiments.
>
> Point is that only acceptable value for me is 0 (negative would be even
> better ;-).
> Any greater causes visible delay in data updates and makes fast navigation
> very unpleasant, apart from angry users...
> It's strange that longer delay between issuing request and getting result
> performs better to you, but I shouldn't be no longer surprised with anything.
Here's the problem with the way it was before:
The user clicks the arrow to move to the next record, which results in the main
bizobj going to the next record, which results in 10 child bizobjs being
requeried,
which results in 15 grandchild bizobjs being requeried, and down the line even
to a
couple great-great-great grandchild bizobjs.
This makes browsing the main records quickly unbearable.
All my change should have done is add 250ms to that process when clicking to
the next
record, but lightning-fast response to quickly navigate to 10 or 20 records
away by
repeatedly clicking the next arrow.
I tested my app on Windows, Linux, and Mac and for all cases in my app - deep
and
wide bizobj hierarchy or single bizobj, the app is way more responsive.
To capitalize on this change, you need to add some updating of specific
controls in
the afterPointerMove hook method, or in response to the RowNavigation event,
like:
class FrmCustomers(...):
def afterPointerMove(self):
self.txtCustomerName.update()
Which will result in just that control being updated during navigation, but all
controls will update after the delay has expired.
If we made a special case for DataUpdateDelay == 0, which would bypass all
this,
would that cover you do you think? Actually, perhaps we should have a second
RowNavigationDelay as we probably want things like cancel() and delete()
resulting in
the update more immediately.
Paul
_______________________________________________
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/[email protected]
