Re: [Adobe-source-devel] win32 group_window_proc

[Thomas W. <wi...@ac...>]

Mat,

DISCLAIMER: I am not an win32 gui expert and I've been known to be wrong 
in the past.

Mat Marcus wrote:
>  
> 
> 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.

I did some reading in the MSDN documentation about WM_COMMAND. 
WM_COMMAND messages are always send to the parent of the widget 
generating the command message. The rationale behind this is to make 
certain idioms easier. E.g. in a dialog the button clicked command can 
directly handled in the dialog code without doing anything in the button 
code. Whether this is a good idea I can't say but it sure does not fit 
the composition approach used for eve widgets where each widget reports 
its own state changes.

Given this I think that every potential parent widget should forward 
WM_COMMAND to its children. In our case these are dialog/panels/groups 
and whatever I missed.

> 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 kind of works but seems to be an unnecessary twisted way of message 
routing. The reason it only kind of works is that not all command 
messages are forwarded. Those for combo boxes aren't.

> 
> 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? 

Yep but see above.

> 
>> 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?

I am mildly confident that passing them to children directly is the 
right way to go.

Thomas

-- 
Thomas Witt
wi...@ac...