WM_QUERYUISTATE

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

WM_QUERYUISTATE

Steve Alan Waring
Hi,

Has anyone implemented and used this api?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/commctls/userex/topics/partsandstates.asp

I am trying to figure out when to show or hide accelerator underlining
in a custom view.

At the moment I am getting inconsistent results when querying the ui
state.

The following post by Raymond Chan sheds some light on the matter:

http://blogs.msdn.com/oldnewthing/archive/2005/05/03/414317.aspx

After reading that, I was hopeful that we would "get keyboard-cues
tracking for free" as Dolphin does call the IsDialogMessage function
(most of the time).

The problem is, I get the expected result when querying any subview of
a Dialog, but inconsistent results when querying subviews of Shells.
Some work some don't.

To experiment, I temporarily implemented:

!View methodsFor!

onLeftButtonReleased: aMouseEvent
        "Default handler for a Left button up mouse event.
        Accept the default window processing."
        "#define WM_QUERYUISTATE                 0x0129
        A non zero answer indicates key accs/focus rect should be hidden"
        Transcript
                display: (self
                                        sendMessage: 16r0129
                                        wParam: 0
                                        lParam: 0);
                cr.
        self presenter trigger: #leftButtonReleased: with: aMouseEvent.
        ^self defaultWindowProcessing: aMouseEvent.! !


Shells like: Class Browsers, and samples such as PersonalAccountShell
show the expected result (3 "Hide") when clicking on any of their
subviews.

Shells like: Inspectors, RegEdit, Notepad show the unexpected result (0
"Show") when clicking on any of their subviews.

It seems a general rule is if a Shell has a default button, then it
works as expected. But unfortunately the class browsers, which don't
have default buttons, break that rule.

Any help appreciated

Steve