Menu
▾
▴
adobe-source-devel
|
From: Thomas W. <wi...@ac...> - 2006-01-19 05:56:17
|
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." 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. Did I miss something? Thomas -- Thomas Witt wi...@ac... |
|
From: Mat M. <mm...@em...> - 2006-01-19 08:28:30
|
> -----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 |
|
From: Thomas W. <wi...@ac...> - 2006-01-19 22:26:48
|
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... |
|
From: Niki S. <nik...@gm...> - 2006-01-20 09:48:46
|
ATL supports message reflection. IIRC it's source is available. http://msdn.microsoft.com/library/en-us/dnvc60/html/atlwindow.asp?frame=3Dt= rue#atlwindow_topic11 HTH Niki Spahiev |
|
From: Ralph T. <ra...@gm...> - 2006-01-21 07:14:17
|
Unfortunately my text editor (notepad!) changed the line endings from
what is in CVS so I can't post a diff, but one "fix" is to change
group_window_proc to this:
// Forward any WM_COMMAND on to the widget that needs to receive it.
LRESULT CALLBACK group_window_proc (HWND window, UINT message, WPARAM
wParam, LPARAM lParam)
{
if (message =3D=3D WM_COMMAND)
{
bool unused (false);
return event_dispatcher::event( message, wParam, lParam, unused );
}
// do default button message processing
control_t*=09control(reinterpret_cast<control_t*>(get_user_reference(win=
dow)));
return CallWindowProc (control->default_window_proc_m, window,
message, wParam, lParam);
}
But then there's not much difference between group_window_proc and
container_window_proc which doesn't seem to be being used anymore (?)
so I think the best fix is to remove group_window_proc completely and
just use container_window_proc in place of it.
The event_dispatcher (which container_window_proc) uses works by
assigning each control a menu id when the control is created. All
WM_COMMAND and WM_NOTIFYs contain the menu id as LOWORD(wParam), the
event_dispatcher can look up the control_t* to call when it encounters
a menu id that it assigned.
After this change it looks like slider_suite still works, as does
image_size (I put the buttons into a group), and the example that
Thomas sent for unit_text now works too.
Ralph
On 1/20/06, Niki Spahiev <nik...@gm...> wrote:
> ATL supports message reflection. IIRC it's source is available.
>
> http://msdn.microsoft.com/library/en-us/dnvc60/html/atlwindow.asp?frame=
=3Dtrue#atlwindow_topic11
>
> HTH
> Niki Spahiev
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> _______________________________________________
> Adobe-source-devel mailing list
> Ado...@li...
> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
>
|
|
From: Ralph T. <ra...@gm...> - 2006-01-24 05:03:05
|
I just committed the fix for this to sandbox, as well as the fix for
another issue that Thomas found -- when there are many items in a
popup widget it will occupy the entire screen (and some items are
inaccessible).
Ralph
On 1/20/06, Ralph Thomas <ra...@gm...> wrote:
> Unfortunately my text editor (notepad!) changed the line endings from
> what is in CVS so I can't post a diff, but one "fix" is to change
> group_window_proc to this:
>
> // Forward any WM_COMMAND on to the widget that needs to receive it.
>
> LRESULT CALLBACK group_window_proc (HWND window, UINT message, WPARAM
> wParam, LPARAM lParam)
>
> {
>
> if (message =3D=3D WM_COMMAND)
> {
> bool unused (false);
> return event_dispatcher::event( message, wParam, lParam, unused )=
;
> }
>
>
> // do default button message processing
>
> control_t* control(reinterpret_cast<control_t*>(get_user_reference(w=
indow)));
>
> return CallWindowProc (control->default_window_proc_m, window,
> message, wParam, lParam);
>
> }
>
> But then there's not much difference between group_window_proc and
> container_window_proc which doesn't seem to be being used anymore (?)
> so I think the best fix is to remove group_window_proc completely and
> just use container_window_proc in place of it.
>
> The event_dispatcher (which container_window_proc) uses works by
> assigning each control a menu id when the control is created. All
> WM_COMMAND and WM_NOTIFYs contain the menu id as LOWORD(wParam), the
> event_dispatcher can look up the control_t* to call when it encounters
> a menu id that it assigned.
>
> After this change it looks like slider_suite still works, as does
> image_size (I put the buttons into a group), and the example that
> Thomas sent for unit_text now works too.
>
> Ralph
>
> On 1/20/06, Niki Spahiev <nik...@gm...> wrote:
> > ATL supports message reflection. IIRC it's source is available.
> >
> > http://msdn.microsoft.com/library/en-us/dnvc60/html/atlwindow.asp?frame=
=3Dtrue#atlwindow_topic11
> >
> > HTH
> > Niki Spahiev
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://sel.as-us.falkag.net/sel?cmdlnk&kid=103432&bid#0486&dat=121642
> > _______________________________________________
> > Adobe-source-devel mailing list
> > Ado...@li...
> > https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
> >
>
|
|
From: Thomas W. <wi...@ac...> - 2006-01-24 19:21:10
|
On Jan 23, 2006, at 9:02 PM, Ralph Thomas wrote: > I just committed the fix for this to sandbox, as well as the fix for > another issue that Thomas found -- when there are many items in a > popup widget it will occupy the entire screen (and some items are > inaccessible). > Thanks! This was really keeping me from making progress. Thomas Thomas Witt wi...@ac... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X