This is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.
Developers using Visual Studio Tools for Microsoft Dynamics GP with forms that contain scrolling windows might have noticed that the LineFill events are missing from v9.0 and v10.0, this posting explains why they were missing and why they have been added back.
How Dexterity works
Dexterity can display multiple records from a table at one time using a scrolling window. Scrolling windows are used in lookup windows and many enquiry windows in BrowseOnly mode and also in transaction windows which have lines or distributions in AddsAllowed mode.
Scrolling windows have six events associated with them, these are the LinePre, LineChange, LinePost, LineFill, LineDelete and LineInsert events. Dexterity can register triggers before and after the original scripts of these six events. In Visual Studio Tools, we have the LineEnter, LineChange, LineLeave, LineDelete and LineInsert events that we can select to run BeforeOriginal or AfterOriginal, but there are no LineFill events.
Where did the LineFill events go?
To understand why the LineFill events were not included, you need understand how the LineFill event works in Dexterity….
When a scrolling window is populated with the Dexterity fill window command, the system will move to the first record in the table range and execute the LineFill event, then it will execute the equivalent of a copy from table to window command to move the contents of the table record to the scrolling window line. It will then read the next record from the table, execute the LineFill event, copy the data and so on until it either reaches the end of table or range (EOF) or completes filling the number of lines in the scrolling window.
When the LineFill event is executed, if there are scripts (or trigger scripts) associated, they will be executed. It is important to understand is the sequence or timing of the events. When the LineFill scripts are executed it is before the scrolling window fields have been populated. This is so the code can prevent that record from showing with a reject record command if it needs to.
If the script needs to populate any scrolling window fields from data in related tables, it must read the key values from the table buffer of the data read. For example: If I read in a transaction with a ‘Customer Number’ field, I must use the value of ‘Customer Number’ from the table buffer to lookup the record in the RM_Customer_MSTR table to obtain the ‘Customer Name’ so I can populate the ‘Customer Name’ field on the scrolling window. A common mistake for new Dexterity developers is to try and read the data from the window itself and always get blank or empty values.
The Version History
When Visual Studio Tools for Microsoft Dynamics GP was created for v9.00, it originally included the LineFill events. However, as Visual Studio Tools did not support accessing of table buffers, these event would be completely useless as they could never obtain any information about the record about to be displayed. So, a decision was made to remove the LineFill events before the final code was released.
When Visual Studio Tools for Microsoft Dynamics GP was updated for v10.00, the developers added support to allow access to form level table buffers. This meant that the LineFill events could actual now work. The issue was that no-one remembered to add the LineFill events themselves back to the tool.
This was quickly rectified for v10.00 Service Pack 1, which does support the LineFill events but it was not included in the documentation for Service Pack 1 or Service Pack 2. With v10.00 Service Pack 3, we will have the events and the updated documentation as well.
I hope this explains everything for you.
This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.