RE: [Adobe-source-devel] win32 group_window_proc

[Mat M. <mm...@em...>]

 

> -----Original Message-----
> From: ado...@li... 
> [mailto:ado...@li...] On 
> Behalf Of Thomas Witt
> Sent: Wednesday, January 18, 2006 9:56 PM
> To: ado...@li...
> Subject: [Adobe-source-devel] win32 group_window_proc
> 
> 
> Hi,
> 
> currently the command routing for direct child widgets of a 
> group is broken. One way to demonstrate is to put a popup in 
> a group. Changes made to the selection will not propagate to 
> adam due to the popup not getting the CBN_SELCHANGE 
> WM_COMMAND message. Put a brakepoint in 
> popup_t::implementation_t::event to see what I am talking about.
> 
> The culprit seems to be group_window_proc the comment 
> preceding its definition says:
> 
> "Groups don't forward WM_COMMANDS to their parents by 
> default. We trap the windowproc here to do so."

I added the group windowproc. Before I did we were noticing that buttons and
sliders were not working when contained in a group. IIRC, after playing
around with Spy++ it seemed to be that notifications were not making it far
enough up the containment hierarchy--they were getting stopped at the group.
When I added the group window proc to propagate messages upwards, things
began to work inside groups for the first time. Command notifications were
making it as far as the panel or dlog window_proc, from which
forward_events_to_control is called.

> This leaves me wondering why WM_COMMANDS should go to 
> parents. AFAICS they should be forwarded to children in the 
> same way it is done in the panel_window_proc. Adding a call 
> to forward_events_to_control to group_window_proc seems to 
> solve the issues with popups and cause no problems.

Doesn't passing the WM_COMMANDs to parents cause the notification to go to
panel_window_proc from which forward_events_to_control will be called? 

> Did I miss something?

I'm not an expert in this area so I couldn't say. Maybe there's a better way
to go. Do you have further thoughts?

> Thomas

 - Mat