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.

posted at: 18:10 | path: /Tips | permalink