View Issue Details

IDProjectCategoryView StatusLast Update
0005470Multi Theft Auto : San AndreasClientpublic2010-12-18 20:57
ReporterKayl Assigned ToKayl  
Status resolvedResolutionfixed 
Target Version1.1Fixed in Version1.1 
Summary0005470: [Request] Improve editbox focus control

Currently it's up to the resource creator to hack around onClientGUIClick to try to detect when an editbox "might" (sometimes it doesn't work) get focus and call guiSetInputEnabled accordingly.

It would therefore be really appreciated if:

  • Solution 1
    MTA could automatically handle the case when an editbox is being edited (when there is the flashing "|") and disable binds during editing

  • Solution 2
    Events such as "onClientGUIEditBoxFocusReceived" and "onClientGUIEditBoxFocusLost" could be added for resource creators to be able to call themselves guiSetInputEnabled but at the most appropriate times

TagsNo tags attached.


child of 0003344 closed New Feature Requests Requested features tracker 



2010-11-10 23:33

developer   ~~0012140

Last edited: 2010-11-10 23:42

I went for solution 1 and made 2 new functions:

  • guiSetInputMode( int ) : 0 = binds are executed, 1 = binds are never executed, 2 = binds are executed except when editing an (non read-only) editbox or a memo
  • int guiGetInputMode()

guiSetInputEnabled( false ) becomes an alias of guiSetInputMode ( 0 )
guiSetInputEnabled( true ) becomes an alias of guiSetInputMode ( 1 )
and guiGetInputEnabled is unchanged in case 0 (false) or 1 (true), and in case 2 it returns whether binds are currently disabled or not (since in case 2 it's dynamic depending on currently focused element).

That way, scripters can simply call guiSetInputMode ( 2 ) once and leave it as it is and never worry about the problems of typing "t" in an editbox :)

I didn't commit even if I could, because I decided to introduce this change on my own so I want to make sure you are ok with it before committing it. So, feel free to have a look at the patch attached.

I've also attached a test file, for instance try to set via the test gui, the mode to 2, then click on "close in 5 seconds" and then spam "t"s in the memo. Only when the window is closed do the t actually trigger the chatbox input.


2010-11-18 00:43

developer   ~~0012164

After discussing with lil_Toady & eAi on IRC, we decided to go for both solutions at the same time, in order to give more flexibility for the scripters.

So, new patch does:

  • change guiSetInputMode and guiGetInputMode to string versions with

  • "allow_binds" : equivalent of guiSetInputEnabled(false)

  • "no_binds" : equivalent of guiSetInputEnabled(true)

  • "no_binds_when_editing" : the new stuff

  • add 2 new gui events:

  • onClientGUIFocus : triggered when a GUI element receives focus

  • onClientGUIBlur : triggered when a GUI element looses focus
    (named suggested by eAi based on html equivalents).
    I made sure, in my implementation, that onClientGUIBlur is called before onClientGUIFocus (in the case of focus transfer) to allow scripters to "stop" things they might have "started" during the previous onClientGUIFocus.

Patch is just here for discussion, I'll remove it when commit is done after feature is validated.

Example code updated with the new stuff, including a checkbox to output the focus events in chatbox.


2010-11-18 14:40

administrator   ~~0012165

I've not looked at your code (yet), but the API looks good. It's not ideal having long strings that you pass in to the function, but I'm not sure Lua has any alternative.


2010-11-18 20:28

administrator   ~~0012166

Fixed in:


2010-12-18 20:57

viewer   ~~0012317

Issue History

Date Modified Username Field Change