Maxgui modification

[HenriVi]

Hi,

I would like to bring this ad-hoc behaviour of Maxgui that was introduced a long time ago back into the light. A modification was made to Windows version that broke the symmetry of the platforms and has sense brought gray hair to people that have been trying get past the problems that this behaviour presents.

So whats the issue ?

Common thing in gui apps is to process information by pressing the enter key. App gets feedback typically from a textfield. After processing, it is also common to set the focus to another textfield or return the focus back to the original textfield so that the user doesn't have to touch the mouse in between and break the flow. Currently, app can catch an enter key press with ok button. Windows guidelines say that enter key should be hardwired to ok button if it exists, so that's fine. If developer doesn't want to display a visible button it can be hidden from sight. This is fine also, but obviously more elegant solution would be to post a EVENT_KEYPRESSED or EVENT_GADGETACTION which would be more intuitively catched in the main event loop.

Now, manually setting the focus with ActivateGadget function is very difficult to achieve, as the modification sets the focus to the parent of the textfield upon pressing the key, making the textfield lose focus (and thus creating EVENT_GADGETLOSTFOCUS), but it does so repeatedly when enter is pressed and once when enter is released. I don't think that the api should prevent the developer of setting the focus where it is wanted.

Some discussion about this subject in here

So whats the solution ?

a) Delete the modification from keyboardproc function.

This would make sense as there is really no need for it. People (one ?) that wanted this have long sense moved on, and you dont need the EVENT_GADGETLOSTFOCUS to process the enter key event anyway.

Edit: Even though this modification was removed, it would be convenient to get the enter key-event with the source gadget (textfield) attached to it, so that you don't need any additional stuff to find it. See code below..

b) Fix the multiple calls to SetFocus and only process it once.

Keyboardproc allows the checking of current and previous key states via lparam variable.

Revised function code would be:

Function KeyboardProc:Byte Ptr( code, wp:WParam, lp:LParam) "win32" nodebug
	Local ev:TEvent, hwnd:Byte Ptr, tmpClassName:Short[16], mods:Int, key:Int = wp
	If code>=0 Then
		
		'Removed: http://www.blitzbasic.com/Community/posts.php?topic=72737
'		Rem
		If wp = $D Then	'$D: VK_RETURN
				
			' Test if ENTER key is been pressed or released and set the focus only once.
			' Fixes the issue of wanting to set the focus manually
			Local preState:Int =  (Int(lp) Shr 30) & 1
			Local tranState:Int =  (Int(lp) Shr 31) & 1
			
			If Not preState And Not tranState Then	'Enter pressed
				
				hwnd = GetFocus()
				If hwnd And GetClassNameW(hwnd,tmpClassName,tmpClassName.length) And String.FromWString(tmpClassName).ToUpper() = "EDIT" Then
					
					'This would be a good place to post a key event or gadgetaction event. This only applies to textfields as textareas already have this functionality (EDIT clause above)
					'..
					
					SetFocus(GetParent_(hwnd))
				EndIf
			EndIf
			
		EndIf
'		EndRem

		ev = HotkeyEventFromWp(wp)
		If ev
			'Hot-key events shouldn't be emitted if the source gadget is disabled
			If Not(TGadget(ev.source) And GadgetDisabled(TGadget(ev.source))) Then
				If Not (lp & $80000000:UInt) Then
					EmitEvent ev
					If ev.mods Then Return 1	'Key press events never reach active panels etc. if we return 1
				EndIf
			EndIf
		EndIf
	EndIf
	Return CallNextHookEx( KBMessageHook,code,wp,lp )
EndFunction

-Henri