JGomes
Member Since 17 May 2011Offline Last Active Jan 16 2012 01:02 AM
Find content
Not Telling
Posts I've Made
In Topic: Game Widgets - Your Pure Gml Solution To Dll's
17 May 2011 - 11:04 PM
Tested and loved, although there are some refinements yet to be done!
It is one of the best at the moment, i dare to say, but there is something that everybody that do something like that misses: events. I couldn't find in the code anything that signals (for example) a button press/release, a window getting focus, a treeView node expanding/collapsing or a menu command selection. Only the UI system is implemented.
The suggestion i have is this. Consider a button. The common events that happens on this button are:
I don't know if this match your implementation guidelines, but every widget (or control, wich is how i'm used to name them) could have a enumerated list of associated events[names] (constants like on_button_click) and a ds_list in every instance of such widget. When a widget instance needs to respond to a user event it should first register the specific event through a function like GW_Button_SetEvent(buttonInstance, buttonEvent, userScriptIndex). GW_Button_RemEvent(...) would also be useful.
userScripIndex is the index of the script that handles the event and is called when the event occurs via script_execute(...). Note that when doing this, some arguments can be passed on as event arguments like relative mouse position, widtget's parent etc:
When and where this event is triggered must be placed is up to you to decide. I prefer this method rather than creating a function that is used to check every step whether something happened or not.
That's a good work, dude. Please, don't stop improving it.
PS: I'm from Brazil, so don't mind the typos you find in the text.
It is one of the best at the moment, i dare to say, but there is something that everybody that do something like that misses: events. I couldn't find in the code anything that signals (for example) a button press/release, a window getting focus, a treeView node expanding/collapsing or a menu command selection. Only the UI system is implemented.
The suggestion i have is this. Consider a button. The common events that happens on this button are:
- the mouse pointer enters/leaves the button area,
- the button is pressed/held down/released by left/middle/right buttons (or RETURN/SPACE keys if focused),
- the button receives/loses keyboard focus
- the button is shown/hidden
- the button is enabled/disabled
- the button is created/destroyed
- the contents/size/position of the button changes (button's text)
I don't know if this match your implementation guidelines, but every widget (or control, wich is how i'm used to name them) could have a enumerated list of associated events[names] (constants like on_button_click) and a ds_list in every instance of such widget. When a widget instance needs to respond to a user event it should first register the specific event through a function like GW_Button_SetEvent(buttonInstance, buttonEvent, userScriptIndex). GW_Button_RemEvent(...) would also be useful.
userScripIndex is the index of the script that handles the event and is called when the event occurs via script_execute(...). Note that when doing this, some arguments can be passed on as event arguments like relative mouse position, widtget's parent etc:
userScriptIndex = ds_list_find_value(dsListId,buttonEvent) // script that handles the event. script_execute(userScriptIndex, rel_mouseX, rel_mouseY, ...) //considering a script was set
When and where this event is triggered must be placed is up to you to decide. I prefer this method rather than creating a function that is used to check every step whether something happened or not.
That's a good work, dude. Please, don't stop improving it.
PS: I'm from Brazil, so don't mind the typos you find in the text.
