On 11/2/11 3:30 AM, Jacek Kałucki wrote:
> Użytkownik Paul McNett napisał:
>> By this I meant: if we were to delay the whole _moveRecordPointer() call,
>> the form
>> couldn't update a few specific fields with the value from the current
>> record, and the
>> status bar wouldn't correctly show the current row number. It would defeat
>> the point.
>
> But when you move record pointer, you are doing that in parent, you already
> know what current row is, how may rows you have, and what row will be the
> next.
For the simple status bar updating, you are correct. But I wanted to allow for
appdev
code to do additional things as simply as possible, such as:
class MyForm(...):
def onRowNavigation(self, evt):
self.txtCustomerName.update()
self.txtCustomerAccount.update()
If the row didn't actually move, we must tell appdevs that you must do:
class MyForm(...):
def onRowNavigation(self, evt):
biz = self.getBizobj()
navrow = self.RowNavigationRow ## I guess it would be named like this
self.txtCustomerName.Value = biz.getFieldVal("cust_name", row=navrow)
self.txtCustomerAccount.Value = biz.getFieldVal("cust_account", row=navrow)
I suppose we could add some smarts to dDataControlMixin's update() code to look
for
RowNavigationRow and act accordingly, allowing for the first sample to work.
> Besides, point was that user navigates rows repetitive quickly.
> Is he able to read row numbers in 100ms interval?
In my testing the specific updates during RowNavigation are immediate and
clear. Is
that what you meant?
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]
