The MASM Forum

I was trying to be clever, moving a TrackPopupMenu call into a proc accessed via CreateThread.

I turns out that it doesn't work with CreateThread. If I call the same proc with invoke, passing exactly the same arguments (global variables!), it works fine.

Mysteries of Windows :biggrin:

TP call
x:rcp.rpMenu    14D810B3
rcp.left        580
rcp.top        68
rcp.right      640
rcp.bottom      999
x:rcp.rpWnd    002C0B24
### TP call out      $Err$()        operation completed__

### TP in      somect          21
To thread
x:esi          14D810B3
x:edi          00000001
x:hWnd          002C0B24
useinv          0

TP thread
x:rcp.rpMenu    14D810B3
rcp.left        580
rcp.top        68
rcp.right      640
rcp.bottom      999
x:rcp.rpWnd    002C0B24
### TP thread out      $Err$()        incorrect parameter__
### TP in      somect          22
Knowing what to search for, I now found explanations on the web (https://stackoverflow.com/questions/6517541/is-it-possible-to-use-trackpopupmenu-from-a-secondary-thread):

QuoteDavid Hefferman:
You need to run this from the same thread that owns the window to which the menu is attached.

The threading rule in Windows is that windows have affinity to the thread that creates the window. Since TrackPopupMenu receives a window handle, you can assume that it must be called from that window's thread.

In practice on Windows (and all GUI frameworks that I have ever come across), everything related to the GUI should happen in the main thread.

It turns out that GetActiveWindow behaves differently:
- when called inside the proc via invoke, it returns a handle, which is not the same as the window handle
- when called via CreateThread, GetActiveWindow returns zero

The source is confused and needs MasmBasic, so I better not post it here. I just wanted to flag this behaviour just in case somebody tries the same.

P.S., fun fact: TrackPopupMenuEx has one argument less than TrackPopupMenu :smiley: