11-25-2022, 05:37 AM
(11-25-2022, 04:58 AM)TerryRitchie Wrote:(11-25-2022, 04:43 AM)SMcNeill Wrote: Note: I've always enjoyed Terry Ritchie's menu library, but it does one thing which doesn't always play nice with my code: It monopolizes the keyboard and mouse while active.
Yeah, that's one of the reasons I rarely used it with a lot of my own software over the years. It was a LOT of work incorporating it into Minesweeper. Looking forward to seeing your approach.
The basic concept here breaks down to this logic:
Code: (Select All)
While _MouseInput: Wend
k = _KeyHit
result = CheckMenu(k)
You have to manually update your mouse buffers yourself -- the check menu routine doesn't do that at all for you -- and you have to send it whatever keypress you want it to check against. (And even then, it only does those things if the menu is VISIBLE and ACTIVE.)
Note that the menu doesn't have any hotkey configured to automatically make it active, so by default, it won't ever interfere with any of your program's configured keystrokes. You have to manually make the menu active yourself:
Code: (Select All)
If _KeyDown(100308) Or _KeyDown(100307) Then
Select Case k
Case 109, 77 'alt-m will toggle my menu here to set it active or not
If Menu(ActiveMenu).Active Then SetMenuActive ActiveMenu, 0 Else SetMenuActive ActiveMenu, -1
End Select
End If
(If the menu is visible, and ACTIVE, but basically in stand-by mode, you can click the mouse on it to make it fully active. Otherwise, the menu does nothing at all until it's set active and ready for interaction.)
Another base concept here is that I'm not worrying about trying to support multi-level menus. Everything is just a single level branch...
For example, what we have in the demo here is just a single menu with "File, Edit, Help, and Quit". My basic idea here is that we'd start with the mainmenu and set it visible and active. The user chooses one of those options (or cancels/ clicks outside the menu), and if they choose "File", for example, then we simply pull up a different menu, display its choices (Open, Save, Recent Files, ect), and process things as normal there.
Multiple windows can be visible (such as MainMenu, FileMenu), but only one can ever be active at a time (FileMenu), which is the one we're actually interacting with. The rest are just there for past reference, and whatnot, so the user can know how they navigated to where they are now. (Provided we keep them visible, that is. After all, it's just a toggle to change visible state for us.)