Post by Chris Iverson on Mar 12, 2021 18:13:28 GMT -5
Window types GRAPHICS and TEXT are both internal tricks to allow shorthanding the graphics or texteditor commands.
These window types will create a normal window, with a full-size graphics box or text editor control as the only control on said window. It then makes the main window handle refer to the control, not the top level window.
(It also handles forwarding some of the commands intended for the top level window, like trapclose, TO the top-level window.)
That way, you can address all your graphics/text commands directly to the window, instead of needing to specify a sub-control. While it works just fine in pure LB, the façade starts to break apart when needing to interact with the API.
In particular, because the top-level window handle actually refers to the control, getting the Win32 window handle via the hwnd() function returns the control's handle, not the top-level window handle! This is significant because the menu gets applied to the top-level window, not the control.
You're looking for a menu that isn't going to be there in the first place.
This brings up a problem: you need the top-level win32 window handle, but you don't have a way to get it in native LB. But you do in the Windows API: the GetParent() API call, which returns the handle to the parent window for any window handle you specify.
OPEN "No Menu Here!" for text as #main hMain = HWND(#main)
[Menu.Destroy] 'Removes entire MenuBar
CallDLL #user32, "GetParent",_ hMain as ulong,_ hParent as ulong
calldll #user32, "SetMenu",_ hParent as ulong,_ 'handle of nongraphics window 0 as ulong,_ '0 removes the MENU BAR results as ulong