Fixing the KEY_ENTER behavior for text fields

BlitzMax Forums/MaxGUI Module/Fixing the KEY_ENTER behavior for text fields

JoshK(Posted 2011) [#1]
Can anyone indicate how to fix the KEY_ENTER behavior for text fields? It used to work perfectly where you would press Enter when a text field was active, and the focus would be lost. This was great for editable fields that update when the gadget loses focus or the user presses enter. For some reason this behavior was changed, and I think it was a bad choice to do this.

The hidden "OK" button hack is not suitable because it will mess up the order of gadget selection when the user presses tab or shift+tab.

Last edited 2011


skidracer(Posted 2011) [#2]
This has been annoying me this week also.

Seb?


JoshK(Posted 2011) [#3]
I thought I might be able to work around this using a TextArea, but there is one problem. When the text goes beyond the width of the textarea, the slider bars appear, filling up the entire area of a single-line text area and making it impossible to change the text:


Last edited 2011


jsp(Posted 2011) [#4]
When the text goes beyond the width of the textarea, the slider bars appear, filling up the entire area of a single-line text area and making it impossible to change the text:


A Windows only solution:
Local hWnd = QueryGadget(textarea, QUERY_HWND)
SendMessageA(hWnd, EM_SHOWSCROLLBAR, Orientation, False)

For Orientation use SB_VERT or SB_HORZ
The False switches the scrollbar off

The hidden "OK" button hack is not suitable because it will mess up the order of gadget selection when the user presses tab or shift+tab.


When you put all all your textfields/textareas in a panel container, but the OK button outside, that should work.


JoshK(Posted 2011) [#5]
Local hWnd = QueryGadget(textarea, QUERY_HWND)
SendMessageA(hWnd, EM_SHOWSCROLLBAR, Orientation, False)

Unfortunately I can't rely on Windows-only commands.

When you put all all your textfields/textareas in a panel container, but the OK button outside, that should work.

That's not a solution for reasons I won't bother explaining.


skidracer(Posted 2011) [#6]
Josh, to revert to the old behavior try changing the code in win32maxguiex.bmx[529] back to:


	Function KeyboardProc( code,wparam,lparam ) "win32" nodebug
		Local ev:TEvent, hwnd%, tmpClassName:Short[16], mods:Int, key:Int = wparam
		If code>=0 Then
			'Removed: http://www.blitzbasic.com/Community/posts.php?topic=72737
'			Rem
			If wparam = $D Then	'$D: VK_RETURN
				hwnd = GetFocus()
				If hwnd And GetClassNameW(hwnd,tmpClassName,tmpClassName.length) And String.FromWString(tmpClassName).ToUpper() = "EDIT" Then
					SetFocus(GetParent_(hwnd))
				EndIf
			EndIf
'			EndRem


and rebuild modules...


JoshK(Posted 2011) [#7]
Thanks. Did it always work this way on OSX, or did OSX used to detect enter key presses as well?


skidracer(Posted 2011) [#8]
After reading topic 72737 and not finding much joy myself in above code (textfields in MaxIDE project editor still not hot return keyed) and then rereading above code I'm starting to think MaxGUI form behavior needs a few features added in the base driver to keep everyone happy.