I just wanted to point out a few things about the EXPANDED and EXPANDING event notifications of the tree-view control.
The EXPANDED notification is sent by the tree-view control after it has finished expanding or collapsing the item. The EXPANDING notification is sent before the tree-view has done the expansion or collapsing. To understand this better, you need to know that when the EXPANDING notification is sent, the programmer can veto the expansion or collapse by replying to the event. That is the main purpose, in the Windows API, of the two different notifications. If you just want to know that the event happened, you would be better off handling the EXPANDED notification. However, if you want to prevent the expansion sometimes, you would want to handle the EXPANDING notification. Handling the EXPANDING notification also allows you to dynamically change the children of the item about to be expanded or collapsed. However, you also need to know the history of ooDialog to understand this. Originally in ooDialog, when an event notification was intercepted, the name of the method to invoke and some string data about the event was put into a queue and the C implementation code returned the reply to the Windows message. The queue was serviced in a secondary thread, in Rexx, that invoked the named method and sent the string data as args to the method. There was no way for the Rexx method to reply directly to the Windows message. So, there was no way for the programmer to veto the expansion or collapse. With ooRexx 4.0.0, a new native C++ API was introduced. Without going into a lot of detail about that API, one of the main advantages for ooDialog is that it now allows the programmer to directly reply to the Windows message from the Rexx event handler method and also allows objects to be sent as arguments to the event handler method. But, to prevent existing programs from breaking all the existing event connection methods need to be retro-fitted to wait for a reply from the Rexx method. For all dialog control classes and event connection methods added after 4.0.0, the default is to wait - no retro-fitting needs to be done. For existing event connection methods, the default has to remain for the interpreter to not wait for a reply, and some mechanism added to allow the programmer to change the default. You can see this ongoing work in the connectTabEvent() and connectResize() methods. The connectTreeViewEvent() method has not been retro-fitted, so there is still no way in ooDialog to veto the expansion or collapse. -- Mark Miesfeld ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Oorexx-users mailing list Oorexx-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-users
