[Migrated content. Thread originally posted on 18 July 2005]

I would very much like to have control over more events in the windows runtime. For windows and controls, for instance, notification of rendering type events like paint, repaint, etc. Also when a window is activated, deactivated, etc. If you look at the events available to Win API wrapped controls in VB and in .NET it is much more extensive than acucobol-gt.

Properties,Properties,Properties :-

I would also like to be able to get access to more properties for things like list-boxes, labels, entry-fields etc. I know you could not extend the COBOL reserved list to allow every property for every control but maybe something like active-x where we can specify properties with a @ might work.

It would be useful to specify the colour (sorry "color") properties as RGB values.

---

[Migrated content. Thread originally posted on 18 July 2005]

I would very much like to have control over more events in the windows runtime. For windows and controls, for instance, notification of rendering type events like paint, repaint, etc. Also when a window is activated, deactivated, etc. If you look at the events available to Win API wrapped controls in VB and in .NET it is much more extensive than acucobol-gt.

Agreed, opening up both properties and events in a more dynamic fashion, like activex, would be great.

Although, this might adversely affect performance. Not sure.

---

[Migrated content. Thread originally posted on 18 July 2005]

I would very much like to have control over more events in the windows runtime. For windows and controls, for instance, notification of rendering type events like paint, repaint, etc. Also when a window is activated, deactivated, etc. If you look at the events available to Win API wrapped controls in VB and in .NET it is much more extensive than acucobol-gt.

I'll chime in with a "Me too" on this. As long as performance isn't hindered too much, this would be of great value - especially the events, events, events.

Rob

---

[Migrated content. Thread originally posted on 18 July 2005]

I would very much like to have control over more events in the windows runtime. For windows and controls, for instance, notification of rendering type events like paint, repaint, etc. Also when a window is activated, deactivated, etc. If you look at the events available to Win API wrapped controls in VB and in .NET it is much more extensive than acucobol-gt.

I think an interesting way to implement more dynamic event control would be to have syntax that allows designation of an event procedure for each event type we want handled for a control. Instead of just one event procedure that handles all events, there should optionally be as many event procedure declarations as there are events you want to handle per control.
For instance, if I want to handle a treeview node expanding and expanded events I could have something like:

EVENT MSG-TV-EXPANDING PROCEDURE IS TVW-EXPANDING-HANDLER
EVENT MSG-TV-EXPANDED PROCEDURE IS TVW-EXPANDED-HANDLER

By default, all other events for the treeview would be completely ignored by the runtime.
I could also use the same procedure for both but personally I prefer to designate seperate procedure names.

To me this is better than the current state of listening for all events and handling in only one procedure per control and then trying to use an environment variable event ignore list or process only list. Even worse is what happens now where the single event procedure runs for every event but does nothing when it should not have been invoked in the first place. This event chattiness is not good for thin client, and thus the patched on ignore environment variable. The event ignore/process only environment variable adds some dynamic event handling capabilities for instance when your app need to process less events in thin-client mode, but to me it's a kludge, a band-aid. The better way is to allow dynamic designation of event procedure names where you can MODIFY a control's event procedures by adding and by removing them. To me this is more programmatic and natural. What would be extremely cool is to assign multiple procedures to one event dynamically like you can do in .NET. =) They would perform in the order assigned and be unassigned by procedure name.
Designated event procedures works more like VB and .NET where you can assign a procedure to handle a specific event, and if there is no assignment, the event is ignored. For backward compatability, the current single event procedure with no event type specified should remain so as not to break applications. Thoughts?

---

[Migrated content. Thread originally posted on 18 July 2005]

I would very much like to have control over more events in the windows runtime. For windows and controls, for instance, notification of rendering type events like paint, repaint, etc. Also when a window is activated, deactivated, etc. If you look at the events available to Win API wrapped controls in VB and in .NET it is much more extensive than acucobol-gt.

Seems to make a lot of sense to me...

Rob

---