I have ran into another small snag. I searched the forums and even check the PB forums, but not finding what I need. Basically I am trying to make the <ENTER> key work like the <TAB> key to tab between text boxes.
Any help is appreciated,
Gary
Here is a global way of changing the behaviour of pressing the ENTER key while inside a TextBox (or really any EDIT control class).
http://www.planetsquires.com/protect/forum/index.php?topic=2272.msg17800#msg17800
It catches the incoming message in the message pump and modifies it before it ultimately gets acted upon by the Form/Control.
Thanks Paul,
I will give this a try.
Gary
Paul,
What would be the best approach if I only wanted to do this for certain controls on the form? In other words, there are some text/edit boxes on the form that cannot respond to the <ENTER> key. So would I create similar code in the individual controls KEYDOWN event or?
I have experimented with this a little bit, but doesn't seem to be working as expected.
Thanks,
Gary
Gary,
Quote from: Gary Stout on January 09, 2015, 04:45:36 PM
I have experimented with this a little bit, but doesn't seem to be working as expected.
Could you post your experimental code or project? Otherwise we are left wondering how you implemented it and what you mean by not working as expected.
David
Sure David,
Here is some test code I tried adding to the Textbox custom area, which may not be the correct way at all, but I am still learning ???
I believe this snippet was adapted from code that Paul suggested for the FF_PumpHook.
Does FF offer a way to SetNextTab or SetPrevTab....once I have the <ENTER> working as expected, in my old app I also allow the user to navigate through fields with the arrow keys, so having the ability to either go to the next control in tab order or the previous tab order is helpful. I can probably get around this by setting focus to a particular control, but that would not allow you to scroll backwards through the tab order.
Sorry to be a pain....In the short time that I have been working with FF this go-around, I am already becoming more familiar with how things operate, but still on the up hill swing of the learning curve. :-\
Function CONTRIBUTIONS_TXTTITHE_CUSTOM ( _
ControlIndex As Long, _ ' index in Control Array
hWndForm As Dword, _ ' handle of Form
hWndControl As Dword, _ ' handle of Control
wMsg As Long, _ ' type of message
wParam As Dword, _ ' first message parameter
lParam As Long _ ' second message parameter
) As Long
Select Case wMsg
Case %WM_KEYDOWN
If wParam = %VK_RETURN Then
Static zClass As Asciiz * 50
GetClassName hWndControl, zClass, SizeOf(zClass)
If UCase$(zClass) = "EDIT" Then
' change the key to be a "TAB" that should move us to the next control
wParam = %VK_TAB
End If
End If
End Select
End Function
Thanks again,
Gary
I think I might be getting a little closer. Some more experimenting and searching these forums and the PB forums has got to this point in the KEYUP event.
Am I headed in the right direction?
Select Case nVirtKey
Case %VK_RETURN
FF_Control_SetFocus(GetNextDlgTabItem(Contributions.hWnd,GetFocus,0))
Function = %TRUE ' prevent key from making it to the TextBox
Case %VK_DOWN
FF_Control_SetFocus(GetNextDlgTabItem(Contributions.hWnd,GetFocus,0))
Function = %TRUE ' prevent key from making it to the TextBox
Case %VK_UP
FF_Control_SetFocus(GetNextDlgTabItem(Contributions.hWnd,GetFocus,1))
Function = %TRUE ' prevent key from making it to the TextBox
End Select
Quote from: Gary Stout on January 09, 2015, 08:18:39 PMDoes FF offer a way to SetNextTab or SetPrevTab
See if the "Tab Order" tab on the FireFly Workspace is what you are looking for. F9 will bring the FF Workspace dialog up it it isn't already.
I won't be able to look into the code you posted until probably tomorrow. I'm busy with other things right now. Thanks for posting it.
David
Thanks David,
I have the tab order set using the Tab Order Editor...no problems there. I just wasn't sure how to navigate via code through the tab order and it looks like GetNextDlgTabItem is what I needed for that. I am making some progress, but always open to suggestions or an easier way to do things.
Gary
Sorry Gary,
If I had taken more care when I read your post, or had time to look at the code you posted, I could have figured out that what I suggested wasn't what you needed. It was all there (looking back at it now), I just didn't see it.
I like the snippet from the KEYUP event. Seem pretty elegant to me.
So, as is stands right now, is it still not working as intended?
Hi Gary, sorry that I didn't mention the GetNextDlgTabItem api. I was working on an example for you this afternoon using GetNextDlgTabItem but couldn't capture the ENTER key. Then I remembered that the ENTER key gets eaten a lot by Windows during TranslateMessage in the pump. Need to use WM_GETDLGCODE to ensure ENTER key is available. I never got to that point yet in my example. :)
Just thinking that an easy way to handle your problem is to continue to use the FF_PUMPHOOK example but only respond to TextBoxes that are flagged as such. An easy way to flag those controls is to set FF_CONTROL_SETTAG with a special text, say, "PROCESSENTER" and then test for that using FF_CONTROL_GETTAG. You can then easily designate those controls in the PropertyList using the "Tag" or "Tag2" property.
Select Case Msg.Message
Case %WM_KEYDOWN
If Msg.wParam = %VK_RETURN Then
If FF_Control_GetTag(Msg.hWnd) = "PROCESSENTER" Then
' change the key to be a "TAB" that should move us to the next control
Msg.wParam = %VK_TAB
End If
End If
End Select
Thanks Paul!
I like this method. I learned something new from your explanation...the use of TAG's. I now see how these could be very useful for just the thing I am trying to do. I am going to try moving all the code over to the FF_PumpHook, which definitely simplifies things versus having to add the code I was using to each textbox.
That brings me to another thought or question....If I have multiple forms, with obviously multiple textboxes, is it possible to use this same routine throughout all of the forms, or would the FF_PumpHook code be form specific?
David,
It is still a work in progress, but as I learn a little here and there, I am getting closer to trying to replicate the old program. It's not quite where I am trying to go with it, but from what I have learned over the last few days, I think I can apply the principles and make it happen.
Hi Gary - happy to hear that the solution works for you! Yes, there is only one FF_PUMPHOOK that will get called for all Forms in the application.
If there are other things in your old program that you would like myself and other FF'ers here to comment on then by all means we're all ears :)
On this very same topic....
Sorry to budge in the conversation, but it seems to be the same concept.
To make ESCAPE close any form should then it must go in here as well?
Just then how do you know which form it must close?
Petrus,
Something like this....(untested but I am using similar code for other purposes)
Case %WM_KEYUP
If Msg.wParam = %VK_RETURN Then
If GetParent(Msg.hWnd) = HWND_CONTRIBUTIONS Then
FF_CloseForm (HWND_MAINFORM)
End If
End If
Peter,
Gary's example is correct about how to do it. Just replace the %VK_RETURN with %VK_ESCAPE.
But, as to where it should go, it depends on what you are trying to do.
In Gary's case, it had to go in the pump hook because he was trying to get to the message early (before the editbox could do it's default behavior).
What I have discovered, by using a form with no controls, is that the Form itself doesn't get WM_ESCAPE messages (someone correct me if I am wrong). So there is no one-place you can put your code to process the escape key in FF's "Breakout msg handler routines". So, this is another case where you should put it in FF_PUMPHOOK. That way, you won't have to check for Escape in each controls msg handler.
In some of my programs, the user can cancel an edit (of an editbox for instance) with the escape key. So, I have a global edit_flag that is set and cleared when any control is gaining or loosing focus. In a case like that, the Escape handling routine in the pumphook would need to check to see if any fields are in edit mode (and changes have been made). If an edit is going on, it would not process the Escape key.
In VB6 we had a keypreview function.
That i used so when the user pressed ESC he would close the form.
It was just a Case /End case in the keypreview directory. Very simple.
Keypresses works much faster on a tool you know well than the mouse.
So whatever form except main is currently open should close back to the form it was created from.