10-22-2022, 03:24 AM
(10-22-2022, 01:25 AM)Pete Wrote: I understand the mechanics, I just can't wrap my head around anything I would ever use it for. I think my coding style is not aligned with this type of approach. Actually, the whole mem thing reminds me of a matrix function I built to run a graphics GUI. While coding a key input / wp routine in C/C++, I can't say if I ever got all the pointer requirements right, but the damn thing worked anyway. Go figure. I'm just greatfull BASIC doesn't require using pointers.
The concept of this approach is neat, but only time will tell if I ever find a project that would benefit from this approach.
Pete
Currently, my little project that'll try to incorporate this method, is just a simple menu-making program. Here's my basic thinking for the menu setup:
first, register the menu and get a valid handle for it, so we can later check mouse/keyboard input against that stored in the handle's data structure.
Then add menu items, and it's at this point that we configure for their actions when triggered:
AddMenuItem "Allow FullScreen: ", "Toggle Event", _Offset(AllowFullScreen), Len(AllowFullScreen)
AddMenuItem "Set Font Size: ", "Set Event (6 - 64)", _Offset(FS), Len(FS)
AddMenuItem "Save Program", "Sub Event: SUB_SAVE", 0, 0
The first menu item says that when you click on it, you toggle the state of the variable called AllowFullScreen. If TRUE, the program would be full screen, otherwise it's just a window.
The second menu item says when you click on it, it'll pop up an input dialog for you to set the current font level with a number from 6 to 64.
The third menu item says when you click on it, it'll jump to your SUB Save and save the program for you from there.
It's a case of:
AddMenuItem (Menu Caption), (Menu Action), (Variable Associated with Action), (Variable Length Associated with Action)
Normally, I'd process a menu at the point where we check to see what was interacted with. Similar to
IF Menu(1,1) = ClickedOn Then Toggle FullScreen
If Menu(1, 2) = ClickedOn Then FontSize = GetValue (6, 64)
If Menu(1, 3) = ClickedOn Then Save
... and so on...
Problem with that is you're defining the menu in one spot, processing input on it in another, executing what happens in another spot in your code... It's a lot of jumping around in various places, and it's a PITA to make certain that it all plays together nicely when you go in 6 months from now and add another feature to that menu.
Somehow, it just seems simpler to me to define the entry AND its corresponding action at the same time and place, than it does to scatter it about in the code like the vast majority of people have been doing over the years.
At the moment, it's just a thought exercise that I'm trying to sort out to see IF I can get it to work with the tools QB64 offers us. I like the *concept* behind it; I just don't know if I can mangle the language and think outside the box enough to actually get it to work for all the things that I'm hoping I can twist it for.... YET!