Jump to content


JGomes

Member Since 17 May 2011
Offline Last Active Jan 16 2012 01:02 AM

Posts I've Made

In Topic: Very High Level Language Design

27 May 2011 - 10:32 AM

I'm used to think that High-Level languages are high-level because of the data it creates/manipulates (objects, for example, in contrast of bytes, arrays etc.), not because it has a code that looks like natural language. Is clear that a complex data needs a language that goes beyond mov ax [bx+4096] to be manipulated.

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:
  • 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. :)