Getting DM_DRAGOVER messages in dialog windows - OS2

This is a discussion on Getting DM_DRAGOVER messages in dialog windows - OS2 ; I'm a little confused, because I assumed that direct manipulation
messages like DM_DRAGOVER would be arriving at my dialog windows and
controls, but I'm not seeing this happen. What do I need to do to see
direct manipulation messages in ...

Getting DM_DRAGOVER messages in dialog windows

I'm a little confused, because I assumed that direct manipulation
messages like DM_DRAGOVER would be arriving at my dialog windows and
controls, but I'm not seeing this happen. What do I need to do to see
direct manipulation messages in dialog window controls? I'm trying to
turn a static icon into a drop target (via subclassing). I don't want
to have to use an empty container window because I think it will not be
intuitive.

--
[Reverse the parts of the e-mail address to reply.]

Re: Getting DM_DRAGOVER messages in dialog windows

Marty schrieb:
> I'm a little confused, because I assumed that direct manipulation
> messages like DM_DRAGOVER would be arriving at my dialog windows and
> controls, but I'm not seeing this happen. What do I need to do to see
> direct manipulation messages in dialog window controls? I'm trying to
> turn a static icon into a drop target (via subclassing). I don't want
> to have to use an empty container window because I think it will not be
> intuitive.
>
I seem to remember that you have to subclass (WinSubclassWindow) all
dialog windows from where you intend to process the DM_DRAGOVER message.
For the most part, you can then call the old window procedure from your
own new window procedure.

Lars

Re: Getting DM_DRAGOVER messages in dialog windows

Marty schrieb:
> I'm a little confused, because I assumed that direct manipulation
> messages like DM_DRAGOVER would be arriving at my dialog windows and
> controls, but I'm not seeing this happen. What do I need to do to see
> direct manipulation messages in dialog window controls? I'm trying to
> turn a static icon into a drop target (via subclassing). I don't want
> to have to use an empty container window because I think it will not be
> intuitive.
>
Ah, sorry, didn't see you are already subclassing:
I think, you will need to subclass the top level dialog window instead
of the individual windows (with the exception of container windows as
they already support subclassing).

Lars

Re: Getting DM_DRAGOVER messages in dialog windows

Lars Erdmann wrote:
> Marty schrieb:
>
>> I'm a little confused, because I assumed that direct manipulation
>> messages like DM_DRAGOVER would be arriving at my dialog windows and
>> controls, but I'm not seeing this happen. What do I need to do to see
>> direct manipulation messages in dialog window controls? I'm trying to
>> turn a static icon into a drop target (via subclassing). I don't want
>> to have to use an empty container window because I think it will not
>> be intuitive.
>>
> Ah, sorry, didn't see you are already subclassing:
> I think, you will need to subclass the top level dialog window instead
> of the individual windows (with the exception of container windows as
> they already support subclassing).

Would this work from the HWND returned by WinLoadDlg or do I have to get
to its actual frame window? Subclassing the HWND returned doesn't seem
very much different from just assigning a dialog window procedure in the
WinLoadDlg call. Currently I'm using WinDefDlgProc just for
prototyping, but it looks like it's time to change that. I guess the
default proc is eating the DM_ messages.

Thanks for the help.

--
[Reverse the parts of the e-mail address to reply.]

Re: Getting DM_DRAGOVER messages in dialog windows

This has become insanely frustrating. I tried just looking in my dialog
procedure and I'm not getting the messages.

I've got a simple subclassed window procedure which does nothing but
write to an output log when I get a DM_DRAGOVER message. It doesn't
even call the previous window procedure, so I can visually see which
window (/window parts) aren't updating with WM_PAINTs, etc. I load up
my dialog window and subclass it. No DRAGOVER messages. If I take the
dialog window's owner, it goes back to another application window like I
would expect. Same for frameowner. If I take the FID_CLIENT from the
dialog window, then it doesn't even stop refreshing the window when I
subclass. If I take the FID_TITLEBAR and take the owner of that, then
it stops updating the correct window, but still no DRAGOVER messages.

I should note that when a program object or file is dragged, I get the
DM_DRAGOVER message. But not when a color or font is dragged. There's
something in the damn dialog window procedure which is handling all of
these for me, and I can't figure out how to override it. How can I find
and override the correct window procedure? Why the heck are dialog
windows so darn special anyway?? For a normal frame window, this is a
piece of cake!

Marty wrote:
> Lars Erdmann wrote:
>
>> Marty schrieb:
>>
>>> I'm a little confused, because I assumed that direct manipulation
>>> messages like DM_DRAGOVER would be arriving at my dialog windows and
>>> controls, but I'm not seeing this happen. What do I need to do to
>>> see direct manipulation messages in dialog window controls? I'm
>>> trying to turn a static icon into a drop target (via subclassing). I
>>> don't want to have to use an empty container window because I think
>>> it will not be intuitive.
>>>
>> Ah, sorry, didn't see you are already subclassing:
>> I think, you will need to subclass the top level dialog window instead
>> of the individual windows (with the exception of container windows as
>> they already support subclassing).
>
>
> Would this work from the HWND returned by WinLoadDlg or do I have to get
> to its actual frame window? Subclassing the HWND returned doesn't seem
> very much different from just assigning a dialog window procedure in the
> WinLoadDlg call. Currently I'm using WinDefDlgProc just for
> prototyping, but it looks like it's time to change that. I guess the
> default proc is eating the DM_ messages.
>
> Thanks for the help.

--
[Reverse the parts of the e-mail address to reply.]

Re: Getting DM_DRAGOVER messages in dialog windows

In <3oidnWOyRs1pZOfanZ2dnUVZ_jGdnZ2d@comcast.com>, on 01/01/2008
at 06:44 PM, Marty said:

Hi,
>No DRAGOVER messages.

Which window procedure are you subclassing? The DM_DRAGOVER messages go
to the receiving window first not to the owner or elsewhere.
>I should note that when a program object or file is dragged, I get the
>DM_DRAGOVER message.

These are probably being passed along by the receiving window. The others
are not.
>How can I find
>and override the correct window procedure?

You might find it helpful to use a combination of pmspy and pmtree. pmspy
will show you the messages and the receiving window. pmtree will help you
convert the window handles to useful names.
>Why the heck are dialog
>windows so darn special anyway??

Nothing other than that they have their own message loop and a different
default message handler. Also the standard controls tend to throw away
what they don't understand. This is what makes it messy to give a list
box DnD support.
> For a normal frame window, this is a
>piece of cake!

I suspect you find it easier because you don't have to subclass your
client window procedure to get first crack at the messages.

Also, a complex control will have several subwindows, so you need to
subclass the correct subwindow control or you will not get the behavior
you expect.

FWIW, the fm/2 sources have several examples of subclassing standard
controls to give them DnD support. This is what you will need to do to
give your dialog items this kind of support.

Re: Getting DM_DRAGOVER messages in dialog windows

Steven Levine wrote:
> In <3oidnWOyRs1pZOfanZ2dnUVZ_jGdnZ2d@comcast.com>, on 01/01/2008
> at 06:44 PM, Marty said:
>
> Hi,
>
>>No DRAGOVER messages.
>
> Which window procedure are you subclassing? The DM_DRAGOVER messages go
> to the receiving window first not to the owner or elsewhere.

Take your pick. I've subclassed the dialog window handle itself, its
"client" window (FID_CLIENT, if it has one as such), and various
controls. My ultimate goal is to use a static icon (static window
class), as a drop target within the dialog.
>>I should note that when a program object or file is dragged, I get the
>>DM_DRAGOVER message.
>
> These are probably being passed along by the receiving window. The others
> are not.

The question is not the receiving window, but the window procedure which
is processing (and unfortunately filtering) the messages. DM_DRAGOVER
messages should be sent to ALL windows that are passed over (as opposed
to DM_DROP, which is only sent to the receiving window). The messages
have to be received and passed to children from the frame window on
down. I think this is done via WM_HITTEST in dialogs, because I see
those flying around as I drag. Somehow there is a window procedure that
is executing before the point at which I can subclass the frame, based
only on the fact that it is a dialog window.
>>How can I find
>>and override the correct window procedure?
>
> You might find it helpful to use a combination of pmspy and pmtree. pmspy
> will show you the messages and the receiving window. pmtree will help you
> convert the window handles to useful names.

PMSpy with all the messages turned on (even the unknown ones) spying on
the dialog window in question reveals not a single DM_ message for
anything other than files and programs. I believe it should be showing
me all the messages for the controls in there as well.
>>Why the heck are dialog
>>windows so darn special anyway??
>
> Nothing other than that they have their own message loop and a different
> default message handler. Also the standard controls tend to throw away
> what they don't understand. This is what makes it messy to give a list
> box DnD support.

I don't mind the controls ignoring messages. Subclassing should take
care of that nicely. But the controls never get the option here. Some
top-level window procedure tosses them well in advance. It also clearly
has some default function, whereupon it will return that a presentation
parameter drop (mixed color palette, font palette, etc.) is ok. It
passes on the messages for files because it seems to want to enable the
developer to use these or let the default procedure handle them (which
returns that a drop is not possible, changing the pointer to indicate
such). But this mysterious (to me, anyway) procedure always seems to
get absolute first crack at things, and if it discards something, or
handles it (like presentation parameters), it is invisible to even
subclassed window procedures. Maybe I need to use PMSpy in queue mode
(not the window mode that I was using) to see exactly which window
handle receives the messages (which have to be going SOMEWHERE), then
desperately try to navigate through a window handle that I have to
subclass it. But my previous search through seemingly relevant handles
turned up nothing.
>> For a normal frame window, this is a
>>piece of cake!
>
> I suspect you find it easier because you don't have to subclass your
> client window procedure to get first crack at the messages.
>
> Also, a complex control will have several subwindows, so you need to
> subclass the correct subwindow control or you will not get the behavior
> you expect.

Again, I'm not yet concerned about the DM_DROP messages. At the very
least the DM_DRAGOVERs should be happening, with visually obvious
results. I'll be able to see the missing holes where I need additional
coverage in window procedures easily. Also a static icon window
wouldn't have any sub-windows in this particular case.
> FWIW, the fm/2 sources have several examples of subclassing standard
> controls to give them DnD support. This is what you will need to do to
> give your dialog items this kind of support.

Is this done in a dialog window environment? I haven't run the app, so
I'm not familiar with it at present. I've done plenty of subclassing
successfully before. It's particularly dialog windows that are
thwarting me now, seemingly. I'm sure I could just create the same
controls in a standard (as opposed to dialog) window, skipping the use
of the dialog template resource. But then I would have to re-implement
the keyboard interface for the standard look and feel (and all the other
creature comforts of dialogs), and want to avoid that with so many
controls in this particular window.

--
[Reverse the parts of the e-mail address to reply.]

Re: Getting DM_DRAGOVER messages in dialog windows

Hmm.. it looks like I need a HowTo with PMSpy. None of my DM messages
are coming up for ANYTHING, ANYWHERE. Even on windows that I know are
receiving them. I added the messages manually and told it to show me
all unknown messages. Not a peep out of PMSpy. What gives??

--
[Reverse the parts of the e-mail address to reply.]

Re: Getting DM_DRAGOVER messages in dialog windows

On Wed, 2 Jan 2008 05:56:49 UTC, Marty wrote:
> I don't mind the controls ignoring messages. Subclassing should take
> care of that nicely. But the controls never get the option here. Some
> top-level window procedure tosses them well in advance. It also clearly
> has some default function, whereupon it will return that a presentation
> parameter drop (mixed color palette, font palette, etc.) is ok. It
> passes on the messages for files because it seems to want to enable the
> developer to use these or let the default procedure handle them (which
> returns that a drop is not possible, changing the pointer to indicate
> such). But this mysterious (to me, anyway) procedure always seems to
> get absolute first crack at things, and if it discards something, or
> handles it (like presentation parameters), it is invisible to even
> subclassed window procedures.

If your observations conflict with your model, perhaps your model is
wrong. In this case, it certainly is.

The font & color palettes don't use drag-and-drop in the conventional
Drg API sense. They capture the mouse and track its movement. When
you release the button, they determine the window under the pointer,
then call WinSetPresParam() on it. No DM_anything involved.

If you want to capture color & font-change events, you have to subclass
the control & intercept WM_PRESPARAMCHANGED (and pass it on to the
original wndproc if you want it to have any effect).

Re: Getting DM_DRAGOVER messages in dialog windows

In , on 01/01/2008
at 09:56 PM, Marty said:

Hi,
>Take your pick. I've subclassed the dialog window handle itself, its
>"client" window (FID_CLIENT, if it has one as such), and various
>controls. My ultimate goal is to use a static icon (static window
>class), as a drop target within the dialog.

None of the ones you mention sound right to me. For example to add DnD to
a entry field of a drop down listbox control, you need to do things like

But it is. If you subclass the right window, you will take control of the
window procedure that you need to override.
>DM_DRAGOVER
>messages should be sent to ALL windows that are passed over

True, as long as the window is at the top of the z-order.
>The messages
>have to be received and passed to children from the frame window on
>down.

It does not work that way.
>I don't mind the controls ignoring messages. Subclassing should take
>care of that nicely.

And it does.
>Some
>top-level window procedure tosses them well in advance.

If anything is tossing them, it's the message loop.
>It also clearly
>has some default function, whereupon it will return that a presentation
>parameter drop (mixed color palette, font palette, etc.) is ok.

I think Rich has explained this.

You might have found this out for yourself with pmspy. What you need to
do is turn on all messages and then start turning off the messages you
don't care about. Eventually you will see which messages are actually
doing the work.

>Maybe I need to use PMSpy in queue mode

You do, once you get the message selection down to something reasonable.

The problem with window mode is it is often difficult to select the right
window.
>At the very
>least the DM_DRAGOVERs should be happening, with visually obvious
>results.

Agreed, as long as the window procedure chooses to react to the message.
>Is this done in a dialog window environment?

No, but it does extensive subclassing of the standard controls. In
addition it fully supports DnD font and color controls, so you could see
how this is done in real life code.
>successfully before. It's particularly dialog windows that are
>thwarting me now, seemingly. I'm sure I could just create the same
>controls in a standard (as opposed to dialog) window, skipping the use
>of the dialog template resource.

A window is a window. Dialog templates just do the WInCreateWindow calls
for you.

Re: Getting DM_DRAGOVER messages in dialog windows

Rich Walsh wrote:
> On Wed, 2 Jan 2008 05:56:49 UTC, Marty wrote:
>
>
>>I don't mind the controls ignoring messages. Subclassing should take
>>care of that nicely. But the controls never get the option here. Some
>>top-level window procedure tosses them well in advance. It also clearly
>>has some default function, whereupon it will return that a presentation
>>parameter drop (mixed color palette, font palette, etc.) is ok. It
>>passes on the messages for files because it seems to want to enable the
>>developer to use these or let the default procedure handle them (which
>>returns that a drop is not possible, changing the pointer to indicate
>>such). But this mysterious (to me, anyway) procedure always seems to
>>get absolute first crack at things, and if it discards something, or
>>handles it (like presentation parameters), it is invisible to even
>>subclassed window procedures.
>
>
> If your observations conflict with your model, perhaps your model is
> wrong. In this case, it certainly is.
>
> The font & color palettes don't use drag-and-drop in the conventional
> Drg API sense. They capture the mouse and track its movement. When
> you release the button, they determine the window under the pointer,
> then call WinSetPresParam() on it. No DM_anything involved.
>
> If you want to capture color & font-change events, you have to subclass
> the control & intercept WM_PRESPARAMCHANGED (and pass it on to the
> original wndproc if you want it to have any effect).

Thank you! I was certain that I didn't have the correct picture of the
situation and this confirms it.

Now to phase II. My drop target is an icon. When a color is dropped to
it and I intercept the PRESPARAMCHANGED message, it correctly reports
that the color changed. Now the curveball... when I query the color
parameter, I get back 255, 255, 255 no matter which color is actually
dropped. I take it that static window controls don't keep track of this
(or fonts probably) for icons. Is this correct? If so, it seems my
alternative should have been to just write my own window class which
loads and displays the pointer and handles its own presentation
parameter changes, sans subclassing. That's probably the best
implementation anyway even if there was a way to make the subclassing
work, right?

Ugh... sometimes I get these Rube Golberg ideas in my head and can't see
that I'm really just trying to drop an anvil on the mouse. My own
special form of "writer's block"... ;-)

--
[Reverse the parts of the e-mail address to reply.]

Re: Getting DM_DRAGOVER messages in dialog windows

On Wed, 2 Jan 2008 09:15:50 UTC, Marty wrote:
> Now to phase II. My drop target is an icon. When a color is dropped to
> it and I intercept the PRESPARAMCHANGED message, it correctly reports
> that the color changed. Now the curveball... when I query the color
> parameter, I get back 255, 255, 255 no matter which color is actually
> dropped. I take it that static window controls don't keep track of this
> (or fonts probably) for icons. Is this correct?

Presparams are attributes that get attached to a window & should just
be there unless the window actively removes them. The msg doesn't tell
the window to save a new value (it's already saved), it says "check it
out & repaint yourself accordingly".

A sanity check or two: the msg identifies the PP that changed - is that
the value you're querying? Are you using the QPF_NOINHERIT flag? It
would be more useful to get back nothing than the owner's value.
> If so, it seems my alternative should have been to just write my own
> window class which loads and displays the pointer and handles its own
> presentation parameter changes, sans subclassing. That's probably the
> best implementation anyway even if there was a way to make the subclassing
> work, right?

I stopped creating trivial window classes years ago & instead use IBM's
quick-and-dirty method: create a static with no class-specific flags,
then subclass it & throw away the original wndproc. Any msgs your
wndproc doesn't handle get sent to WinDefWindowProc(). Since a window
_is_ whatever it's wndproc _does_, this lets you morph it into whatever
you need.

In this instance, you'd place the window above the icon so that it receives
the preparamchanged msgs. Chances are that this window will start life
with the standard background color, obscuring your icon, so you'll probably
have to invalidate the icon's window to force a repaint & make it visible.

Re: Getting DM_DRAGOVER messages in dialog windows

Rich Walsh wrote:
> On Wed, 2 Jan 2008 09:15:50 UTC, Marty wrote:
>
>>Now to phase II. My drop target is an icon. When a color is dropped to
>>it and I intercept the PRESPARAMCHANGED message, it correctly reports
>>that the color changed. Now the curveball... when I query the color
>>parameter, I get back 255, 255, 255 no matter which color is actually
>>dropped. I take it that static window controls don't keep track of this
>>(or fonts probably) for icons. Is this correct?
>
> Presparams are attributes that get attached to a window & should just
> be there unless the window actively removes them. The msg doesn't tell
> the window to save a new value (it's already saved), it says "check it
> out & repaint yourself accordingly".
>
> A sanity check or two: the msg identifies the PP that changed - is that
> the value you're querying? Are you using the QPF_NOINHERIT flag? It
> would be more useful to get back nothing than the owner's value.

My problem was I was using the QPF_ID1COLORINDEX flag. When I removed
this flag, my 255's went away and I got the RGB color indices. This is
counter-intuitive to me, and I have serious doubts if this code will
work in an 8-bit color mode. So my "working" code is this:

So perhaps my understanding of PP_BACKGROUNDCOLOR and
PP_BACKGROUNDCOLORINDEX is incorrect. Would I receive a
PP_BACKGROUNDCOLORINDEX in an 8 bpp mode and a PP_BACKGROUNDCOLOR in
non-palettized modes? If so I should probably change my code as
follows, do you agree?:

Not sure why you need a static window class as your starting point for
this. Can't just a plain old user-defined class do the same thing? You
can tell the dialog template to load any class that you register. I'm
likely missing your point.
> In this instance, you'd place the window above the icon so that it receives
> the preparamchanged msgs. Chances are that this window will start life
> with the standard background color, obscuring your icon, so you'll probably
> have to invalidate the icon's window to force a repaint & make it visible.

Re: Getting DM_DRAGOVER messages in dialog windows

On Thu, 3 Jan 2008 07:09:42 UTC, Marty wrote:
> Rich Walsh wrote:
> So perhaps my understanding of PP_BACKGROUNDCOLOR and
> PP_BACKGROUNDCOLORINDEX is incorrect. Would I receive a
> PP_BACKGROUNDCOLORINDEX in an 8 bpp mode and a PP_BACKGROUNDCOLOR
> in non-palettized modes?

No. There are 2 ways to specify a color: RGB or color index, where
color index identifies stock colors that are likely to be in the
standard palette. This is independent of the display mode.
> If so I should probably change my code as follows, do you agree?

You should differentiate between PP_BACKGROUNNDCOLOR (when spelled
correctly) and PP_BACKGROUNDCOLORINDEX simply to ensure that you get
correct results for whatever gets thrown at you. Also, your buffer
only needs to be 4 bytes max. (FYI... color indices were broken in
early versions of Warp v4 but few people noticed because most code
uses RGB values)
> > I stopped creating trivial window classes years ago & instead use IBM's
> > quick-and-dirty method: create a static with no class-specific flags,
> > then subclass it & throw away the original wndproc. Any msgs your
> > wndproc doesn't handle get sent to WinDefWindowProc(). Since a window
> > _is_ whatever it's wndproc _does_, this lets you morph it into whatever
> > you need.
>
> Not sure why you need a static window class as your starting point for
> this. Can't just a plain old user-defined class do the same thing? You
> can tell the dialog template to load any class that you register. I'm
> likely missing your point.

It saves a few lines of code, eliminates any preconditions for loading
your dialog, avoids the highly-unlikely possibility of a name collision,
etc. One tangible benefit is that you can manipulate the window in the
dialog editor which doesn't handle custom classes well.
> > In this instance, you'd place the window above the icon so that it receives
> > the preparamchanged msgs. Chances are that this window will start life
> > with the standard background color, obscuring your icon, so you'll probably
> > have to invalidate the icon's window to force a repaint & make it visible.
>
> It shouldn't know how to paint itself unless your subclassed procedure
> tells it, right?

This is all moot since you've confirmed that a static icon window will
handle presparams correctly, but for discussion's sake... The original
wndproc gets the WM_CREATE msg and initializes itself accordingly. Even
without any style flags, it would (probably) paint a background. Once you
replaced its wndproc, it would do whatever you wanted it to.

Now that I've thought about it more, I _think_ that the upper window
would have to have to handle WM_PAINT like this: WinValidateRect(hUpper)
to avoid an endless cycle of paint msgs, then WinInvalidateRect(hIcon)
(and maybe WinUpdateWindow(hIcon)) to get the actual visual content below
it displayed properly. Fortunately, you no longer have worry about whether
any of this is correct :-)