Sometimes, even if you know the framework as well as I do, you re-
discover a feature that you had forgotten about. This happened
tonight as I was going over the interaction between a grid and its
form, so I thought I'd pass it along.
When any of the events that cause the current record pointer to move
are handled by the form, it generates a dEvents.RowNumChanged event,
to which grids can bind so that they can update their display. The
form code looked like:
dabo.ui.callAfter(self.raiseEvent, dEvents.RowNumChanged)
and the event handler in the grid would run this code:
try:
self.CurrentRow = self.getBizobj().RowNumber
except AttributeError:
pass
In other words, the grid knew that the row had changed, but had no
idea what the new row was. It had to then get a reference to the
bizobj for that grid, if any, and then ask that bizobj for its
current row number.
Why is this inefficient? Because the code that raised the event
*knew* the old and new row numbers; the fact that they were different
was why it was raising the event in the first place. Then I
remembered that you can pass data along to raiseEvent(); any keyword
parameters you add are set as event data. So I changed the form code
to read:
dabo.ui.callAfter(self.raiseEvent, dEvents.RowNumChanged,
newRowNumber=biz.RowNumber, oldRowNumber=oldRowNum)
...and now the grid's event handler can just reference those values
directly! They will have the same names as the parameter keys:
try:
self.CurrentRow = evt.newRowNumber
except AttributeError:
pass
This may be a small savings overall, but I thought that it
illustrated a handy mechanism built into the Dabo event class that
you might use to improve your applications.
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/dabo-users/[EMAIL PROTECTED]
