Question on Events and Types

BlitzMax Forums/MaxGUI Module/Question on Events and Types

Saxon1974(Posted 2007) [#1]
Hello, I am having a bit of trouble in a couple of areas and have a couple of questions.

1) When handling an event using types, do you place the actions to be performed upon in the update_state method for that type that you want the action performed on?

For example, I have a TNewCanvas type and a TNewWindow type. When I resize the TNewWindow (MainWindow) Object I want to resize the TNewCanvas to fit the new size of the TNewWinow Object. Do I put the statement to reshap the canvas in the parent TNewWindow object update_state method or the TNewCanvas obect (CHild)? I am currently using an event hook to handle the resizing using a resizeWindows function. This seems to work but doesn't seem perfect.

2) I am not clear if its a good idea to have all my event handler case statements in my Type objects themselves. Is this a good idea?

3) I would like to make this application more event driven, where I check what event happened and which object it affects and take the appropriate action instead of going through each objects update_state method (This doesn't seem very effective).

I have seen Noel Cower's version wrapper but I can't say I really understand it as it doesn't have the main routine code that actually calls the different types\functions.

Sorry this is a long request but I would really appreciate any responses or direction anyone could give me. (Only been doing blitzmax for a short time).

Here is my code:




jsp(Posted 2007) [#2]
Please use a codebox when posting large code, look here: http://www.blitzbasic.com/faq/faq_entry.php?id=2

1)Yes, normally that is what you want to do.
2)That is ok if you filter only those events you need in that specific type.
3)I think here is your biggest problem as the update state method doesn't work as you expect. In every call of the update you add another hook? You would do this only once. Actually it works the other way around. Create a type, register it once in the hook and do nothing... When an event occurs the registered hook function is run and you filter your needed event and react on it as you want.


Saxon1974(Posted 2007) [#3]
Sorry, Im new here, so just use the tags ? Will do from now on.

When you say create a type and register it once in the hook and do nothing. I don't really understand what you mean. Are saying only have the hook function in one of the types? Can you provide an example?

Maybe you mean create the hook outside of the types before I start my for loop?


jsp(Posted 2007) [#4]
Look at this example.
Watch the debuglog output while resizing the window or clicking on the upper or lower canvas.



[EDIT]
The lower canvas is maintained by the waitevent queue, that is quite ok for all gadgets which don't need to react on events while you drag something (e.g. A slider movement or window resize). The upper canvas hooks itself (only once during creation) into the event queue and doesn't do anything then. When there is an event the OnEvent Method is called and filters those events it want to do something on (calls here for update)...


Saxon1974(Posted 2007) [#5]
Thank you this is very helpful, I understand now how to hook a type (Itself) to an event hook.

What If I have 2 canvas's on my window and want them both resized when I resize the window\and maximize it?

Is it a bad idea to have 2 canvas's on one window? I realize having them overlap is a bad idea, so they do not.

Here is the code you sent but I modified it so that I have 2 canvas types and they both attach themselves to the hook and then get updated at the same time when an event occurs. (I moved the hook functions out of the types for re-usability to minimize code)

Is this a bad idea to update them at the same time? I have been having some trouble getting both of my canvas's to resize to the window properly in my other project (One I originally sent), it seems like it works about 90% of the time and other times it doesn't resize one of the canvas's or both.

Here is your code that I update, would this be a good way to do it? Or is it better practice to only have 1 canvas on a window use a hook and any others handled a different way?




Saxon1974(Posted 2007) [#6]
Aaarg, sorry I didnt use the codebox the first time I just used Code tags. I tried to update it, but apparently the update of a post to add codebox tags doesnt work?


TaskMaster(Posted 2007) [#7]
No, your codebox ending has the slash in the wrong direction...

/codebox


Saxon1974(Posted 2007) [#8]
Ahh, what a dork:) Fixed now in both posts.


jsp(Posted 2007) [#9]
Two canvas should be no problem. This is what your example also does. And yes overlapping is a bad idea. Just keep in mind to init the correct canvas always before writing to it (as in the example).

Here is the code you sent but I modified it


Although this looks a good approach it is not! Why? Because every time you add something you re-add another already existing event-type connection. You can see it just best in your example when you run it and only single click onto one canvas, the result is 2 times the debuglog output! That means although you only once clicked, your hooked routine was run twice and both canvas switch it's color although only the one clicked onto should.

Is this a bad idea to update them at the same time?


Try to separate always the logic from the drawing. They can be updated of course in one cycle but every canvas should have it's own routine for it.

Here is your code that I update, would this be a good way to do it? Or is it better practice to only have 1 canvas on a window use a hook and any others handled a different way?


I think this is just a personal thing. I would say it depends a bit on the structure of the program. For my personal taste it doesn't make sense to make a certain thing too complicated if it's not needed. The hook functions are very nice but need more work. The waitevent queue is easy but is somewhat limited. In the past i worked always with callbacks (hooks in BM), they are more direct, but although they can be considered more advanced they can give you some headache when it comes to complete eventqueue swapping.

I post you another example, maybe things are getting clearer then. You will find only one type as before (a bit modified) which will be created 4 times. Every time the type is build it hooks itself into the eventqueue. When the event occurs it sorts out itself where it belongs to. Canvas 4 for instance stays always red in this update! Of course there are many other ways to do it...
Setting the layout for every canvas gives the freedom to adjust them to the window.




Saxon1974(Posted 2007) [#10]
Excellent example, this helps very much thank you! I wasn't real clear on how to handle events for different objects so this make it clear.