[Closed] Can I get a Handle to the ContextMenu in Windows Messenger's Options Window?

[Zohar]

If going to Windows Messenger,

then:

Menu: Options

then choosing the Privacy tab,

There are 2 ListViews there: Allow list, and Block list.

Each of those ListView controls, display the same small Context Menu, when being RightClicked.

(please see attached image from that window).

How can I get a handle to this Context Menu?

the code I wrote indeed gets some handle,

but when trying to print the # of items in the context menu, I get -1.. instead of 3.

Here's the code:

<div class='codetop'>CODE</div><div class='codemain' style='height:200px;overflow:auto'>

;this code expects the Options window to be already open, and to be on the Privacy tab

Local $hWin =WinGetHandle("Options") ;Window: Windows Messenger's Options

WinActivate ($hWin)

Local $hListView_Block =ControlGetHandle($hWin,"","[CLASSNN:SysListView322]") ;ListView: "Block list"

Local $hMenu = _GUICtrlMenu_GetMenu($hListView_Block)

ConsoleWrite($hMenu & @CRLF)

Local $iMenuItems = _GUICtrlMenu_GetItemCount($hMenu)

ConsoleWrite($iMenuItems & @CRLF)

</div>

Edited October 9, 2009 by Zohar

[MrCreatoR]

Double topic posting it's not a good way to get help.

P.S

I personaly don't have Windows Messenger installed on my system (removed), therefore i can't test anything.

[Authenticity]

As I've understood from another topic, I forgot which one, if it's an owner-drawn list box then all, but trivial, methods won't work as expected. For example, if you send message like $LVM_DELETEALLITEMS and it isn't working then it's probably an owner-drawn list-box which handles notification messages in different ways than the general notification event messages.

[Zohar]

But there's no ListBox here..

[Authenticity]

Any control can have owner-drawn style. I've just made a mistake but it's a good one

[Zohar]

But it's a simple Messenger's Option window, with a very basic ListView that does nothing special.

It is not owner drawn.

So your answer is irrevelant to here.

Thank you tho.

[Authenticity]

If it was a general one, I don't see any reason why getting the handle of a window with this 'Option' caption and enumerating it's child windows until there is a match to the name of the control's class and sending a simple LVM_DELETEALLITEMS to this control won't work .

There is also the possibility that it's intentionally design this way or made from scratch like creating child window and create all it's control on the fly, or perhaps it's not processing this kind of messages or many more ways which IMO is a direct method to despair the beginner coder. I believe that there is always a work around but in this case I have no other clues as it's not in front of my eyes, Sorry.

[Zohar]

Authenticity,

I am able to do any operation on each of the 2 ListViews there.

From _GUICtrlListView_GetItemCount($hListView), to _GUICtrlListView_GetItem($hListView,$i), to whatever else.

And the problem is not the ListView, it's Getting the ContextMenu's Handle, like the topic says..

I don't understand what's the point of answering people answers like "I don't think it's possible"..

When you know, give an answer,

when you are not sure, or don't know, what's the point in writing?

I respect your effort to help, it's very kind,

but please undetrstand that unless you got the answer,

or a clear reason for a "no" answer,

there's no use in the conversation.

[MrCreatoR]

Authenticity,

I am able to do any operation on each of the 2 ListViews there.

From _GUICtrlListView_GetItemCount($hListView), to _GUICtrlListView_GetItem($hListView,$i), to whatever else.

And the problem is not the ListView, it's Getting the ContextMenu's Handle, like the topic says..

I don't understand what's the point of answering people answers like "I don't think it's possible"..

When you know, give an answer,

when you are not sure, or don't know, what's the point in writing?

I respect your effort to help, it's very kind,

but please undetrstand that unless you got the answer,

or a clear reason for a "no" answer,

there's no use in the conversation.

But otherwise, you will continue to post and bump the topic like you did with creating this one, and post messages like «anyone?» in the old one.

Here is a test script that will show you that even with simple context menu there is problem (with _GUICtrlMenu_GetMenu(), not returning the correct menu handle):

expandcollapse popup

#include <GuiConstantsEx.au3>
#include <GuiMenu.au3>

$GUI = GUICreate("Test Script", 300, 200)

$LV1 = GUICtrlCreateListView("Column", 20, 40, 120, 120)
$LV2 = GUICtrlCreateListView("Column", 160, 40, 120, 120)

$CMenu1 = GUICtrlCreateContextMenu($LV1)
GUICtrlCreateMenuItem("Item1 in Menu1", $CMenu1)
GUICtrlCreateMenuItem("Item2 in Menu1", $CMenu1)

$CMenu2 = GUICtrlCreateContextMenu($LV2)
GUICtrlCreateMenuItem("Item1 in Menu2", $CMenu2)
GUICtrlCreateMenuItem("Item2 in Menu2", $CMenu2)

GUISetState(@SW_SHOW, $GUI)


;============== Here we trying to get the handle and count menu items ==============
Local $hListView_1 = ControlGetHandle($GUI, "", "SysListView321")
;Local $hListView_1 = GUICtrlGetHandle($LV1) ;It's the same

Local $hMenu = _GUICtrlMenu_GetMenu($hListView_1)
;Local $hMenu = GUICtrlGetHandle($CMenu1) ;Uncomment this one, and all works fine, so the problem is in _GUICtrlMenu_GetMenu func.

ConsoleWrite(StringFormat("Menu Handle: %s\nError code (GetMenu): %i\n", $hMenu, @error))

Local $iMenuItems = _GUICtrlMenu_GetItemCount($hMenu)

$iError = _WinAPI_GetLastError()
$sError = _WinAPI_GetLastErrorMessage()

ConsoleWrite(StringFormat("Items Count: %i\nError code (GetItemCount): %i\nError Message: %s", $iMenuItems, $iError, $sError))
;====================================================================================

While 1
    Switch GUIGetMsg()
        Case $GUI_EVENT_CLOSE
            Exit
    EndSwitch
WEnd

[MrCreatoR]

I even tried to enumerate child windows (for LV control), but there is no context menu handle in the list, only basic controls.

[Zohar]

MrCreator:)

The original post got abit long and outof focus, so I decided to gather all the information I had about it,

including the new screenshot,

and writing it in 1 message.

If I could delete the old post, I would've.

But I can't.

But you're right.

Regarding the ContextMenu:

Thanks alot for the test script!

and I am sad that even in it, the _GUICtrlMenu_GetMenu() function doesn't give the ContextMenu

The definition of _GUICtrlMenu_GetMenu(), from AutoIt's Help, is

"Retrieves the handle of the menu assigned to the given window"

Altho Controls are usually Windows, maybe this function is not that general.

Maybe it works only on windows that are real Windows and not controls?..

All my attempts to find another function havenot succeeded..

I hope there is a way to do it,

since this problem is not specific, but occurs in many places where you might want to Click a MenuItem which is in a ContextMenu, and not in a regular(MenuBar) Menu.

Thanks alot for your attempt in the script

[MrCreatoR]

Just made some searches, found this, the problem there is similar, and there is a solution for controling the context menu items. Maybe it wil help...

[Authenticity]

Pfff.. Nice one, it took this guy 5.5 years to get this answer heh. Thank for this great found MrCreatoR.

[MrCreatoR]

Ok, it's my last attempt for today. Here i tried to set a mouse hook and use «WindowFromPoint» to get the popup menu, but no luck on my side

expandcollapse popup

#include <GuiMenu.au3>

$hMenu = _WaitPopupHandle()

$sInfo = StringFormat("Menu Handle: %s\nError code (GetMenu): %i\n", $hMenu, @error)

Local $iMenuItems = _GUICtrlMenu_GetItemCount($hMenu)

$iError = _WinAPI_GetLastError()
$sError = _WinAPI_GetLastErrorMessage()

$sInfo &= StringFormat("Items Count: %i\nError code (GetItemCount): %i\nError Message: %s", $iMenuItems, $iError, $sError)

MsgBox(262144+64, "Menu Test", $sInfo)

Func _WaitPopupHandle()
    Local Const $WH_MOUSE_LL = 14
    
    Local $hCallback_KeyHook = DllCallbackRegister("_GetPopupHandle_Callback", "int", "int;ptr")
    Local $hM_Module = DllCall("kernel32.dll", "hwnd", "GetModuleHandle", "ptr", 0)
    
    Local $hM_Hook = DllCall("user32.dll", "hwnd", "SetWindowsHookEx", "int", $WH_MOUSE_LL, _
        "ptr", DllCallbackGetPtr($hCallback_KeyHook), "hwnd", $hM_Module[0], "dword", 0)
    
    While Not IsDeclared("h__Popup__Handle")
        Sleep(10)
    WEnd
    
    If IsPtr($hCallback_KeyHook) Then
        DllCallbackFree($hCallback_KeyHook)
        $hCallback_KeyHook = 0
    EndIf
    
    If IsArray($hM_Hook) And $hM_Hook[0] > 0 Then
        DllCall("user32.dll", "int", "UnhookWindowsHookEx", "hwnd", $hM_Hook[0])
        $hM_Hook[0] = 0
    EndIf
    
    Return Eval("h__Popup__Handle")
EndFunc

Func _GetPopupHandle_Callback($nCode, $wParam)
    Local Const $MOUSE_SECONDARYUP_EVENT = 517
    Local $iEvent = BitAND($wParam, 0xFFFF)
    
    If $iEvent = $MOUSE_SECONDARYUP_EVENT Then
        Sleep(100)
        Local $aMouse_Pos = MouseGetPos()
        MouseMove($aMouse_Pos[0]+10, $aMouse_Pos[1]+10, 0)
        Assign("h__Popup__Handle", _GetHoveredWnd(), 2)
    EndIf
    
    Return 0
EndFunc

Func _GetHoveredWnd($aMouse_Pos=0)
    If Not IsArray($aMouse_Pos) Then $aMouse_Pos = MouseGetPos()
    Local $aRet = DllCall("User32.dll", "hWnd", "WindowFromPoint", "long", $aMouse_Pos[0], "long", $aMouse_Pos[1])
    
    Return $aRet[0]
EndFunc

WindowFromPoint return only the parent window handle (or the control handle that is currently under the mouse cursor/under the contextmenu as well).

[Zohar]

The guy who asked the question in that devx forum, asked it in

09-24-2002 and received an answer in

01-31-2007 hehehe:))

the poor thing had to wait 4.5 years

anyhow

I have read the answer, and what he did there is quite amazing,

tho I couldn't believe everyne has this problem.

I thought it's only me, choosing the wrong AutoIt function or something..

anyhow, what he did in his first solution, could've been much simpler, like my current workaround:

I cause the ContextMenu to appear via Send("{APPSKEY}") - this is the button on the keyboard that opens ContextMenus.

Then I do Send() with 1 letter, which is the MenuItem's Accelerator Letter.

So those 2 simple operations: Send("{APPSKEY}") and Send() with the accelerator letter,

cause the execution of the desired menu item.

The problem is,

that If you want to check the Enabled state of a MenuItem,

all those keyboard games that I did, will not help you:)

So that's why getting the ContextMenu Handle is needed.

Unfortunately his first solution(the WM_COMMAND solution) will not do it.

The second Solution, using Hooks, probably will.

I couldn't believe it's gonna be that wild

Since I now discovered, thanks to you, that this is a general problem,

I will continue tomorrow morning and check the example you made, and also try to search google, maybe someone found some nice trick.

If not then maybe I will abandon it.

Thank you very much for your ideas and help!!

Zohar

Edited January 26, 2009 by Zohar