how to get position of cursor in EDIT control?? - Programmer

This is a discussion on how to get position of cursor in EDIT control?? - Programmer ; "Nobody" wrote in message news:FZzwb.12416$Bk1.8827@fed1read05... > Upon further thought... > > Tooltips have to be WS_POPUP windows, so there isn't going to be any > parent/child relationship between the edit control and tooltip. It's an owner/owned popup relationship, and the ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 23 of 23

Thread: how to get position of cursor in EDIT control??

  1. Re: how to get position of cursor in EDIT control??

    "Nobody" wrote in message
    news:FZzwb.12416$Bk1.8827@fed1read05...
    > Upon further thought...
    >
    > Tooltips have to be WS_POPUP windows, so there isn't going to be any
    > parent/child relationship between the edit control and tooltip.


    It's an owner/owned popup relationship, and the edit creates the tooltip
    with itself as the owner. Somewhere along in the creation process the system
    ups the owner to the toplevel parent, but the control sends the
    WM_NOTIFYFORMAT query to the WM_CREATE/LPCREATSTRUCT's hwndParent -- which
    still appears to be the edit's HWND at that point (which makes sense as it's
    documented to be, "identical to the parameters of the CreateWindowEx
    function").

    >
    > The edit control has 4 extra window bytes defined, which I guessed was a
    > pointer to an internal struct. Examining the pointer, I found the handle

    to
    > the tooltip control in there:
    >
    > LPBYTE lpb = (LPBYTE)GetWindowLong(hWndEdit, 0);
    > lpb += 0x11c;
    >
    > DWORD* lpdw = (DWORD*)lpb;
    >
    > *lpdw will be non zero if the tooltip is visible.
    >
    > This is a much cleaner way then the EnumWindows, but a lot less reliable.

    MS
    > is generally pretty good about maintaining backwards compatibility in APIs
    > and structs, but since this is an internal thing, it can completely change
    > in any patch or service pack or update breaking my code.


    The WM_NOTIFYFORMAT message is documented, and plays by documented rules
    with implicitly documented characteristics, and seems to work according to
    them. I'd personally be inclined to persue it over the other.

    >
    > I also put a trace in my wndproc and saw no weird messages coming through.


    What do you mean by that?

    --
    Jeff Partch [VC++ MVP]



  2. Re: how to get position of cursor in EDIT control??


    "Jeff Partch [MVP]" wrote in message
    news:ex$1SewsDHA.2388@TK2MSFTNGP12.phx.gbl...
    > "Nobody" wrote in message
    > news:FZzwb.12416$Bk1.8827@fed1read05...
    > > Upon further thought...
    > >
    > > Tooltips have to be WS_POPUP windows, so there isn't going to be any
    > > parent/child relationship between the edit control and tooltip.

    >
    > It's an owner/owned popup relationship, and the edit creates the tooltip
    > with itself as the owner. Somewhere along in the creation process the

    system
    > ups the owner to the toplevel parent, but the control sends the
    > WM_NOTIFYFORMAT query to the WM_CREATE/LPCREATSTRUCT's hwndParent -- which
    > still appears to be the edit's HWND at that point (which makes sense as

    it's
    > documented to be, "identical to the parameters of the CreateWindowEx
    > function").


    Ah, ok, I'll look into this...

    > > The edit control has 4 extra window bytes defined, which I guessed was a
    > > pointer to an internal struct. Examining the pointer, I found the handle

    > to
    > > the tooltip control in there:
    > >
    > > LPBYTE lpb = (LPBYTE)GetWindowLong(hWndEdit, 0);
    > > lpb += 0x11c;
    > >
    > > DWORD* lpdw = (DWORD*)lpb;
    > >
    > > *lpdw will be non zero if the tooltip is visible.
    > >
    > > This is a much cleaner way then the EnumWindows, but a lot less

    reliable.
    > MS
    > > is generally pretty good about maintaining backwards compatibility in

    APIs
    > > and structs, but since this is an internal thing, it can completely

    change
    > > in any patch or service pack or update breaking my code.

    >
    > The WM_NOTIFYFORMAT message is documented, and plays by documented rules
    > with implicitly documented characteristics, and seems to work according to
    > them. I'd personally be inclined to persue it over the other.
    >
    > >
    > > I also put a trace in my wndproc and saw no weird messages coming

    through.
    >
    > What do you mean by that?


    weird = undocumented a bunch of messages in the 0x1000 to 0x1100 range
    seem to go through.

    Going a little OT here, but one of my other custom controls is "Microsoft-y"
    owner draw menus like in Office / Office2000 / Office2003 / Visual Studio /
    VS.Net / VS.Net2003, etc. I have support for the personal / smart menus that
    are expandable/collapsable with a chevron menu item. My whole menu manager
    API is built on top of real menus, so I have a lot of hacks going on in
    there: subclassing #32768 windows, hooking shadow windows, creating my own
    shadow windows, over-riding menu frames to get thin borders, etc. But it
    doesn't break MFC and all the real menu / window messages are still there.

    To implement a lot of this stuff, I put traces everywhere to see what
    messages were going where. Alot of the messages going to the #32768 windows
    are internal and undocumented (but tested to be the same back down to NT
    4.0).

    These are some of the "weird" messages I found and my best guess as to what
    they do when sent to a #32768 window:

    message wParam lParam return
    0x1ef 0 0 HMENU of the menu
    represented // returns the HMENU for this #32768 (finally documented
    in latest PSDK)
    0x1e2 1 0 ???
    // seems to trigger the menu to recalculate itself with WM_MEASUREITEMs and
    resize
    0x1e5 and 0x1ed seem to be sent by the OS and pass in the currently selected
    menu in the WPARAM so the menu can update itself. I trap and patch these to
    compensate for the thinner borders.

    0x1ef gets called when an item is selected, CmdID of the item in WPARAM

    0x1eb seems to be an internal WM_NCHITTEST

    Man, I love this reverse engineering GUI stuff... I wish I could find a job
    doing that, way more fun then parsing XML all day



  3. Re: how to get position of cursor in EDIT control??

    Thanks Jeff, WM_NOTIFYFORMAT worked like a charm! Much cleaner solution.

    "Jeff Partch [MVP]" wrote in message
    news:ex$1SewsDHA.2388@TK2MSFTNGP12.phx.gbl...
    > "Nobody" wrote in message
    > news:FZzwb.12416$Bk1.8827@fed1read05...
    > > Upon further thought...
    > >
    > > Tooltips have to be WS_POPUP windows, so there isn't going to be any
    > > parent/child relationship between the edit control and tooltip.

    >
    > It's an owner/owned popup relationship, and the edit creates the tooltip
    > with itself as the owner. Somewhere along in the creation process the

    system
    > ups the owner to the toplevel parent, but the control sends the
    > WM_NOTIFYFORMAT query to the WM_CREATE/LPCREATSTRUCT's hwndParent -- which
    > still appears to be the edit's HWND at that point (which makes sense as

    it's
    > documented to be, "identical to the parameters of the CreateWindowEx
    > function").
    >
    > >
    > > The edit control has 4 extra window bytes defined, which I guessed was a
    > > pointer to an internal struct. Examining the pointer, I found the handle

    > to
    > > the tooltip control in there:
    > >
    > > LPBYTE lpb = (LPBYTE)GetWindowLong(hWndEdit, 0);
    > > lpb += 0x11c;
    > >
    > > DWORD* lpdw = (DWORD*)lpb;
    > >
    > > *lpdw will be non zero if the tooltip is visible.
    > >
    > > This is a much cleaner way then the EnumWindows, but a lot less

    reliable.
    > MS
    > > is generally pretty good about maintaining backwards compatibility in

    APIs
    > > and structs, but since this is an internal thing, it can completely

    change
    > > in any patch or service pack or update breaking my code.

    >
    > The WM_NOTIFYFORMAT message is documented, and plays by documented rules
    > with implicitly documented characteristics, and seems to work according to
    > them. I'd personally be inclined to persue it over the other.
    >
    > >
    > > I also put a trace in my wndproc and saw no weird messages coming

    through.
    >
    > What do you mean by that?
    >
    > --
    > Jeff Partch [VC++ MVP]
    >
    >




+ Reply to Thread
Page 2 of 2 FirstFirst 1 2