Multiple checks could as well be done using Select-case-EndSelect.
Also, I prefer to have a mainloop which waits for the events, and have functional parts checking for specific events.
This is quite a standard mold you could use:
Repeat
WaitEvent()
If EventId=$803 quit=1
SomeFunction
' function call to another function
Until quit
' optionally some clean-up here..
End
Function SomeFunction()
If EventID()=...
If EventSource()=...
..
EndIf
EndIf
End Function
No need to send events around using function arguements. The events are global. Ofcourse, what you really want is that everything is local, no globals whatsoever, as they truly limit your code -and motivation- when the source gets big. As a result of this localness you want your variables hidden, e.g. "datahiding", as much as you can. It's a bit crappy to explain this to a beginner btw, because I just *know* you'll fail to see the point of this. :P
There's a tutorial in the B+ tutorial sections, made by me, which explains how to work with banks in combination with own gadgets.. apart from these own gadgets, the principle could be used for anything else.
I could say 'skip it in the first years and just toy around a bit'. The problem however is that you have Blitzplus! Would you be a B3d user then it was easy: you'd probably be doing more gamestuff and less interface stuff. But since you're messing around with B+'s gadgets you're obviously interested in GUI/applications. At a certain point it's even right, games need editors, editors are best done with a GUI system. So, if you want to focus on GUI, prepare for patience and tidyness.
Things to keep in mind about GUI:
- an interface is usually most of the work for any tool
- an interface can grow as functionality grows, it can actually grow even larger than the functionality grows
An example: your functionality is: "draw an oval of any given color, size and location"
A GUI? For a possible solution you'll need:
- a canvas to see your result
- since the user can create an oval off-screen, one must be able to scroll through the canvas
- using scrollbars
- using mousewheels
- using keyboard shortcuts (e.g. cursors, page up/dn, home/end)
- since the user can create small very ovals, one must be able to zoom in/out
- using a scrollbar
- using mousewheels
- using keyboard shortcuts
- the user might want to alter the size of the canvas, e.g. when the hostwindow gets resized or something
- the user might want to click/drag the oval and have pickup squares (like in photoshop) to resize/relocate the oval. Some users would prefer this over textfields.
- as the user can create black ovals, the user might want to be able to change the background color of the canvas
- using 3 textfields for r,g,b
- using 1 textfield for rgb (like $ffff00 for yellow)
- using a button raising a colorrequester (some standard B+ object)
- five textfields for x,y,width,height,color
- when processing the color textfield there might be incorrect values (e.g. rgb values too high or negative)
- prompt the user about it, or:
- auto-clip them yourself
- update that textfield again so that they contain the clipped values
That's all quite a lot, just to have the ideal oval tool. But it's actually this nitpicking of details that consumes most of your time when doing a proper interface.
But ok, let's assume you're up to this: you've seen that I used mousewheel/keyboard at two locations, if you want to support them at both points, you'll need to make sure they don't get mixed up.
Next problem, you or someone else makes an additional request for your oval designer: now it should also draw rects and lines. Ouch, you just hardwired all the stuff to the DrawOval function, but well, the rect won't require more arguements and the line can steal away the w and h textfields for x2 and y2. So, sofar it's all doable.
But now! You get a request for bezier-splines. DAMN, that'll require 8 parameters and perhaps another one to define the amount of line segments. Now you've not enough textfields, and your cornerpickup system in the canvas is worthless all of a sudden.
You could add more textfields, but because you keep adding things, slowly but surely your source becomes a nightmare.
Actually, I don't think I'm exaggerating this story, just look at 3dsmax or so, just observe what functionality it has in those canvases. Of course, who needs a tool to draw ovals, and who needs a tool with so many details? Even a map-editor has quite a lot of details tho, any GUI has details, more than you think!
This fact of GUI-bloat means that you'll need to make sure that you START right with your GUI, that you start in a way which is future-proof. This is actually quite hard, even for me in Blitzmax with all its language extras compared to Blitzplus. It requires extra thinking on what might be required in the future.
That's why it is SO EXTREMELY important to make tidy indented code, with enough white lines to keep things readable, and enough comments to make your code readable after 8 months of not touching it. (Even a week can be enough to obscure your memory regarding your own code!)
Ok.. </lecture> :P