SyntaxBomb - Indie Coders

Quote from: Midimaster on April 23, 2023, 09:21:03you made only a typo:

"123".ToInt

The ToInt is a function, and so it needs always brackets:

"123".ToInt()

Just a heads up Midimaster, but your code snippets in the tutorial do not reflect this use of parenthesis.
Maybe the "new" forum has eaten them?

Thank you for the hint. When I have written .ToInt without brackets this is a typo. The compiler will not start and throws an error message. I can see a lot of lines in lesson XX where I did it.

The only possible use is .ToInt()

At the moment I cannot correct it, because the new forum software disabled editing old posts. I already asked Qube to find a solution.

Feedback for the button tutorial part: https://www.syntaxbomb.com/index.php?msg=347060950


There is a _big_ issue with your button code.
"MouseHit()" does reset the hit state! It returns the "count of hits" since the last call to "MouseHit()".
This means as soon as "button 1" checked "MouseHit(1)", all other buttons will receive "hit = 0" when they do their checks.

In your specific example/case this is not an issue.  But think of widgets with "overlap" (eg moveable windows etc). For (even simple) GUI systems you need to tackle multiple things:
- "eating events" (mouse input event -> SetHandled(true) in case of having taken care of the mouse input)
- order of widgets (z-index so to say), who gets chance first to handle an event (a widget might have a "hole in it" in which you can "click through", so it might get the event first, but skip handling it))

Regarding mouse input I have my own "MouseHandler" which gets updated and persists mouse click states until told to "Reset" (which is then done by the GUI system).

I understand that the tutorial is for now "for total beginners" but the fact that "MouseHit()" (and other similar commands) return a number which resets afterwards, is very important. As people might use it in "clicked on an item in the inventory" and wonder why clicks only randomly work.
It should not be "item checks for user input" but a "got user input, check what to do with it".

Something like this (crude approach)
Local mouseGotHit:Int = MouseHit(1)
Local mouseHitHandled:Int = False
If mouseGotHit and not mouseHitHandled then CheckButtons(mousex(), mousey(), mouseHitHandled (as var) )
If mouseGotHit and not mouseHitHandled then CheckOtherStuff_MouseHitStillNotHandled(mouseHitHandled)
The idea is to store the information "mouse was clicked" and ask all elements if they care for it. If they cared, they should tell the system (eg setting a variable or by resetting the "hit state" (here mouseGotHit).

This is also why your objects never should react to specific "input" but receive "events" (or a "signal" or so). Because then you can replace the "signal emitter" to your likes (the click can come from a network client, from a finger touch, ...). As said, this is not for "beginners" but still something you need to explain (that in this case MouseHit() is not a "state" persisted until the next tick).



bye
Ron

@Derron Thank you for your bug report. I immediately changed the source code and added an advice for pointing to this problematic.

you doing good job on Tutorials and for BlitzMax GUI as got like combo box, list box and so on

https://en.wikibooks.org/wiki/BlitzMax/Modules/MaxGUI/MaxGUI