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

+ Reply to Thread
Results 1 to 14 of 14

Thread: Getting DM_DRAGOVER messages in dialog windows

  1. 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.]

  2. 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

  3. 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

  4. 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.]

  5. 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.]

  6. 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.

    Steven

    --
    --------------------------------------------------------------------------------------------
    Steven Levine MR2/ICE 3.00 beta 10pre #10183
    eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
    --------------------------------------------------------------------------------------------


  7. 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.]

  8. 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.]

  9. 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).


    --
    == == almost usable email address: Rich AT E-vertise.Com == ==
    __________________________________________________ _________________
    |
    | New! DragText v3.9 with NLS support
    Rich Walsh | A Distinctly Different Desktop Enhancement
    Ft Myers, FL | http://e-vertise.com/dragtext/
    __________________________________________________ _________________


  10. 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

    oldproc = WinSubclassWindow(WinWindowFromID(hwndUserlist, CBID_EDIT),
    DropDownListProc);

    >The question is not the receiving window, but the window procedure which
    >is processing (and unfortunately filtering) the messages.


    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.


    Steven

    --
    --------------------------------------------------------------------------------------------
    Steven Levine MR2/ICE 3.00 beta 10pre #10183
    eCS/Warp/DIY/14.103a_W4 www.scoug.com irc.ca.webbnet.info #scoug (Wed 7pm PST)
    --------------------------------------------------------------------------------------------


  11. 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.]

  12. 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.


    --
    == == almost usable email address: Rich AT E-vertise.Com == ==
    __________________________________________________ _________________
    |
    | New! DragText v3.9 with NLS support
    Rich Walsh | A Distinctly Different Desktop Enhancement
    Ft Myers, FL | http://e-vertise.com/dragtext/
    __________________________________________________ _________________


  13. 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:

    ....
    case WM_PRESPARAMCHANGED:
    char buffer[256] = { 0 };
    LONG bytesRead;
    ULONG ppType;

    ppType = LONGFROMMP( mp1 );
    if ( ppType == PP_BACKGROUNNDCOLOR ||
    ppType == PP_BACKGROUNDCOLORINDEX )
    {
    // Experimentally, in 32bpp mode, I get PP_BACKGROUNDCOLOR from
    // the mixed and solid color palette DnD.
    bytesRead = WinQueryPresParam( win, ppType, 0, NULL, 256, buffer,
    QPF_NOINHERIT );
    // (yup... I remembered the NOINHERIT, but thanks for checking...)
    if ( bytesRead > 2 && bytesRead < 5 )
    {
    // RGB or RGBA (alpha channel empty in OS/2)
    WinSendMsg( spinButtonHwnd_Red, SPBM_SETCURRENTVALUE,
    MPFROMLONG( buffer[0] ), NULL );
    WinSendMsg( spinButtonHwnd_Green, SPBM_SETCURRENTVALUE,
    MPFROMLONG( buffer[1] ), NULL );
    WinSendMsg( spinButtonHwnd_Blue, SPBM_SETCURRENTVALUE,
    MPFROMLONG( buffer[2] ), NULL );
    }
    }
    break;

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

    case WM_PRESPARAMCHANGED:
    char buffer[256] = { 0 };
    LONG bytesRead = 0;
    ULONG ppType;

    ppType = LONGFROMMP( mp1 );
    if ( ppType == PP_BACKGROUNNDCOLOR )
    {
    // Experimentally, in 32bpp mode, I get PP_BACKGROUNDCOLOR from
    // the mixed and solid color palette DnD.
    bytesRead = WinQueryPresParam( win, ppType, 0, NULL, 256, buffer,
    QPF_NOINHERIT );
    } else if ( ppType == PP_BACKGROUNDCOLORINDEX )
    {
    bytesRead = WinQueryPresParam( win, ppType, 0, NULL, 256, buffer,
    QPF_NOINHERIT | QPF_ID1COLORINDEX );
    }

    if ( bytesRead > 2 && bytesRead < 5 )
    {
    // RGB or RGBA (alpha channel empty in OS/2)
    WinSendMsg( spinButtonHwnd_Red, SPBM_SETCURRENTVALUE,
    MPFROMLONG( buffer[0] ), NULL );
    WinSendMsg( spinButtonHwnd_Green, SPBM_SETCURRENTVALUE,
    MPFROMLONG( buffer[1] ), NULL );
    WinSendMsg( spinButtonHwnd_Blue, SPBM_SETCURRENTVALUE,
    MPFROMLONG( buffer[2] ), NULL );
    }
    break;

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


    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.


    It shouldn't know how to paint itself unless your subclassed procedure
    tells it, right?

    I appreciate your discussion and patience.

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

  14. 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 :-)


    --
    == == almost usable email address: Rich AT E-vertise.Com == ==
    __________________________________________________ _________________
    |
    | New! DragText v3.9 with NLS support
    Rich Walsh | A Distinctly Different Desktop Enhancement
    Ft Myers, FL | http://e-vertise.com/dragtext/
    __________________________________________________ _________________


+ Reply to Thread