TextField Focus Loss
BlitzMax Forums/MaxGUI Module/TextField Focus Loss
| ||
| Hi, When I have focus on a TextField and press the Enter button, the TextField looses focus, and if I try to use ActivateGadget on it right away it'll just loose focus instantly again. I've tried using SetGadgetFilter, but the Enter button will not show up. Anyone know how to solve this? Just enter a text and press Enter, the textfield will loose focus and will not get it back even though I use ActivateGadget when the button gets pressed. How it should work is that the Textfield should get focus again, but it doesn't for me.. Thanks |
| ||
| Tried it in OSX and the textfield remains in focus after Enter. -David |
| ||
| Works OK on WinXP BMax 1.24 with full syncmods. |
| ||
| Appears to work on GTKMaxGUI on Linux too : pressing Enter leaves focus on the text field. |
| ||
| It's strange, I removed all modules and re-downloaded them from Synchronize Modules, and still doesn't work. Anyone have an idea on what could be wrong? :/ Oh, And I'm using WinXP SP2, with BMax 1.24. Thanks :) |
| ||
| Do you have 'Quick Build' turned on? Gives sometimes strange effects, so turn it off. And try to delete the .bmx folder where your source file is located. |
| ||
| I never use 'Quick Build', Tried the Delete .bmx folder thing, Didn't work either :/ It has always been like this, I remember trying to create a chat application a long time ago, had the same problem then. Very annyoing :S Any more ideas? :P Thanks |
| ||
| I tried the example on 2 other machines, WinXP no SP and WinXP SP1, same thing happens there, TextField looses focus when I press enter. So it's not only my machine it happens on. No clues? :/ Thanks :) |
| ||
| I also am seeing the Text Field lose the focus. No idea why... |
| ||
| After playing with this a bit more. I found that pressing Enter in a text field causes it to lose focus. So, my guess is the problem you are seeing is the order of events. Your button is getting the Enter press, then your text field is getting the enter press. When the button gets the enter press, it clears the box and gives it focus, but then I think the text field is then getting the enter press which causes it to lose focus. Funny thing is, the text field does not give any events when it gets the enter press except EVENT_GADGETLOSTFOCUS. I tried this without the button and the text field loses focus on Enter, sends the EVENT_GADGETLOSTFOCUS and that is it. |
| ||
| Had another look and I *do* lose focus. I think this has been reported before though here Not sure how it got put in the bugbin although BRL did get purge bug reports so they could start again some time ago. |
| ||
| Thanks for looking things up a bit TaskMaster, I've come up with a 'Hack' solution to the problem. Just in case anyone else experience this problem and want to solve it. Thanks :) |
| ||
| any good solution to this "bug" yet? |
| ||
| This behaviour was actually requested as a feature a while back but looking at this thread, a lot of people don't like it so I'll "fix" it for the next release. Cheers for bringing it to my attention. |
| ||
| thanks! |
| ||
| No, please don't change this behavior! With most text values, you only want to update whatever the gadget controls when the focus is lost, not every time the user types a character! The enter key is a good way to make the text field update with the lost focus event. |
| ||
| I think it'd be better to add a LIVEUPDATE flag or something for creating the gadget, rather than making that the default behavior. It could prove to be fairly slow for most uses, so it doesn't seem like a good thing to change, to me. |
| ||
| It could prove to be fairly slow for most uses, so it doesn't seem like a good thing to change, to me This isn't really what we're proposing a change to. EVENT_GADGETACTION is generated whenever the text in a textfield/textarea changes - if a block of text is pasted in, then only one event should be generated, but obviously if the user is typing directly into the field, it will generate one event per character as the text is changing one character at a time. And remember, you don't have to update your program after every EVENT_GADGETACTION - only if you want to. The enter key is a good way to make the text field update with the lost focus event. I completely understand as I have wanted this type of behaviour in my own apps. But if that is the behaviour you want, can't you just catch the enter key like so? ' createtextfield.bmx
Import MaxGui.Drivers
Strict
Local window:TGadget, textfield:TGadget, button:TGadget
window = CreateWindow("My Window",30,20,320,200)
textfield=CreateTextField(4,4,120,22,window)
SetGadgetText( textfield,"A textfield gadget" )
' have an OK button to catch return key
button=CreateButton("OK",130,4,80,24,window,BUTTON_OK)
HideGadget button
ActivateGadget textfield
While WaitEvent()
Print CurrentEvent.ToString()
Select EventID()
Case EVENT_GADGETLOSTFOCUS
Select EventSource()
Case textfield
Update()
EndSelect
Case EVENT_GADGETACTION
Select EventSource()
Case textfield
Print "Textfield changed!"
Case button
ActivateGadget button
End Select
Case EVENT_WINDOWCLOSE
End
End Select
Wend
Function Update()
Notify "Update()"
EndFunction |
| ||
| Why should I have to change all my code for behavior that should be the default, and is already implemented correctly? No one has put up a good argument to the contrary, and I use MaxGUI for some really complex apps. |
| ||
| No one has put up a good argument to the contrary It's not cross platform? Also this way is far more flexible, as you can do other things as well as cause the text-field to lose focus. Edit: People who want to mimic the previous behaviour can do so by creating a button on the same parent as the textfield, with a BUTTON_OK style flag (this can be hidden if necessary), and handling the button's EVENT_GADGETACTION to activate the button when pressed (as show in my code example above). Alternatively though, this EVENT_GADGETACTION could be used to move the focus onto the next gadget in the form which may not have been possible previously, or call an update function if necessary. |
| ||
| I would like it as Zeke requested it. The problem now is that once you hit return and the textfield lost the focus, you are not able any more as user to switch (tab-key) to the next textfield or gadget. This is a big disadvantage. If the focus would stay, that's not a problem and we still could update our stuff with the OK-Button. |
| ||
| MaxGUI v1.34 has now been released. |
| ||
| bump |
| ||
| Another work around is to call the activate event a 2ond time. and use wait event in between. i think this whold work on all platforms but havent tryed it on windows 8 only.. Strict Import MaxGui.Drivers AppTitle = "*** TCPIP test client ***" Global FLAGS:Int ' Comment/uncomment any of the following lines to experiment with the different styles. FLAGS:| WINDOW_TITLEBAR 'FLAGS:| WINDOW_RESIZABLE FLAGS:| WINDOW_MENU FLAGS:| WINDOW_STATUS FLAGS:| WINDOW_CLIENTCOORDS 'FLAGS:| WINDOW_HIDDEN FLAGS:| WINDOW_ACCEPTFILES 'FLAGS:| WINDOW_TOOL 'FLAGS:| WINDOW_CENTER Local window:TGadget = CreateWindow( "Client ", 100, 100, 350, 250, Null, FLAGS ) Local area:TGadget = CreateTextArea( 10,20,250,100,window,0) Local chatbar:TGadget = CreateTextField ( 10,130,250,20,window,0) Local chatOK:TGadget = CreateButton (" send ",10,150,250,20,window,BUTTON_OK) While WaitEvent() Print CurrentEvent.ToString() Select EventID() Case EVENT_GADGETACTION Print "Inspector gadget actions.." Select EventSource() Case chatOK Print "Ok has ben selected" SetGadgetText chatbar,"" ActivateGadget chatbar WaitEvent ActivateGadget chatbar End Select Case EVENT_WINDOWCLOSE End Case EVENT_APPTERMINATE End End Select Wend |
   |