I have a simple PopUp Form that has 1 Command Button and two RichEdit Controls. The only control in the tab order is the Command Button. The RichEdit controls are read only. In the _WM_CREATE function I have a _SetFocus statement to set the focus to the Command Button.
The problem is the Focus is not going to the command button when the PopUp form displays. What am I doing wrong and how do I get the command button to have focus when the PopUp Form is displayed?
heres the WM_CREATE code:
Function FRMSENDREC_WM_CREATE ( _
hWndForm As Dword, _ ' handle of Form
ByVal UserData As Long _ ' optional user defined Long value
) As Long
Local st As String
st = gClaimData
Replace Chr$(28) With "~" In st
Replace Chr$(29) With "%" In st
Replace Chr$(30) With $CrLf & "^" In st
FF_Control_SetText( HWND_frmSendRec_RichEdit1, st )
FF_Control_SetFocus(HWND_frmSendRec_Command1)
End Function
When I press the Tab key after the PopUp form displays then focus will be set to the Command control. Any ideas how to fix this problem? So that the Command Control will have focus when the Popup form first displays?
Put the button to the first position of the tab order.
Quote from: Rolf Brandt on March 17, 2010, 08:08:47 PM
Put the button to the first position of the tab order.
Rolf, thanks for the suggestion but that was the first thing I tried. It didn't have any effect. Here's my Tab Order:
I just tried a form with just a Command button, nothing else. I thought the Command button should be the initial focus/tabstop but it is not.
The only way to do it is BS_DEFPUSHBUTTON but it should not be like this.
Quote from: Cho Sing Kum on March 17, 2010, 08:46:17 PM
I just tried a form with just a Command button, nothing else. I thought the Command button should be the initial focus/tabstop but it is not.
The only way to do it is BS_DEFPUSHBUTTON but it should not be like this.
Cho, How do I use BS_DEFPUSHBUTTON ?
Hi Marty,
FireFly Workspace - Properties tab - [WindowsStyles]
Cho,
Yes, the use of BS_DEFPUSHBUTTON accomplishes what I wanted to do. Thank you for the tip.
Are you guys on 3.07? I'd say yes since your screen shot shows check boxes in the tab order...but, I just made a sample of this and have no problems? I just started a new project and tossed a button and 2 richedits on a form. With the button first in tab order it gets focus, with either of the richedits first they get focus, and taking the check off the richedits (No TabStop style) I can put the button last and it gets focus. I know there was an issue in one of the previous versions that FF wasn't setting focus to the control first in tab order and/or it was focusing a control without tabstop style but first in the list, but that was fixed.
Anyone else notice when using this function it gets inserted all messed up?
FF_RichEdit_SetText( ByVal_hRichEdit_As_Long, ByVal_sBuffer_As_String, ByVal_fPlainText_As_Long_) As_LongDeclare_Function_FF_RichEditStreamSetCallback( ByRef_Parm_As_FF_RichEditSetTextParmType, ByVal_pbBuffer_As_Dword, ByVal_cb_As_Long, ByRef_pcb_As_Long )
Definitely not happening.
Although the selected rectangle is on the Command button, it is not having focus.
When the Command button has focus, hitting the Enter key will trigger the Function FORM1_COMMAND1_BN_CLICKED. Put a MsgBox "here" in there, run the project, hit the Enter key and you will know what I mean.
Edit: added a screen shot to explain visually.
There are many actions that can steal the focus. Therefore, instead of FF_Control_SetFocus(HWND_frmSendRec_Command1), post a custom message, e.g. %WM_USER + 999:
PostMessage hWndForm, %WM_USER + 999, HWND_frmSendRec_Command1, 0
And then, set the focus when you will process that message:
CASE %WM_USER + 999
IF wParam THEN SetFocus wParam ' Set the focus
EXIT FUNCTION
The Command Button being:
1) the only control to have the tabstop or
2) the first in the tabstop order,
it should get the focus when the program starts but it does not.
The same problem with Image button.
The other controls do not have this problem.
Quote from: Cho Sing Kum on March 19, 2010, 05:51:14 PM
Definitely not happening.
Although the selected rectangle is on the Command button, it is not having focus.
When the Command button has focus, hitting the Enter key will trigger the Function FORM1_COMMAND1_BN_CLICKED. Put a MsgBox "here" in there, run the project, hit the Enter key and you will know what I mean.
Edit: added a screen shot to explain visually.
Actually in your screen shot you are confusing Focus(Tab Order/SetFocus API) with Default Button(BS_DEFPUSHBUTTON). Your button in blue has no focus and only indicates it is Default. Your Button in Red has focus and is not Default. There is also a 3rd of default and focus where it has both. Focus responds to spacebar to click button, Default Button responds to Enter (when not focused and focus is in a text field) and (when in focus and default). Put a 2nd button and make only the first default and you will also see when tabbing that the default button moves to the 2nd too since focus and default follows between buttons(When at least one button is declared as Default and the tab order flows from the default to a non-default), but as soon as you tab to a text area the true Default Button has the indicator.
It is harder to see with default Win XP themes. I use the Black Zune theme where the highlight for default is orange. I also grabbed the Royale from Media Center and replaced my defaults with it and it looks better in it too.
Quote from: Roger Garstang on March 24, 2010, 02:08:18 PM
Actually in your screen shot you are confusing Focus(Tab Order/SetFocus API) with Default Button(BS_DEFPUSHBUTTON). Your button in blue has no focus and only indicates it is Default. Your Button in Red has focus and is not Default.
No, I am not confused. There is only one Command Button and it is not set as Default (that is, no BS_DEFPUSHBUTTON). It is the only control on the form that has tabstop.
It looks like the one in red on startup. It becomes the one in blue after I press the Tab key once, and it has focus, contrarily to what you are saying.
MSDN
http://msdn.microsoft.com/en-us/library/aa511453.aspx
Any command button becomes the default when users tab to it. If the input focus is on a control that isn't a command button, the command button with the default button attribute becomes the default. Only one command button in a window can be the default.
The Command button being the only control on the form with tabstop, shouldn't it then become "default" (as in being tab to) on startup? Shouldn't it look like the one in blue on startup?
And even if there are other controls on the form with tabstop and a command button in the form has the intial tabstop and there is no other button with BS_DEFPUSHBUTTON, shouldn't it also look like the one in blue too on startup?
Is not a Command Button with the input focus also be the default at that point in time? (I am not referring to BS_DEFPUSHBUTTON). Where is the input focus on startup?
I see this behaviour on VB3, 4, 5 and 6 and also on VS2002, 2003, 2005 and 2008.
Please do not be confused with BS_DEFPUSHBUTTON. I know what it is for and when to use it.
(For this matter, I also know what is a Cancel button and the ESC key, although not relevant in this discussion.)
Fact is that VB6 and PB behave differently.
Attached is a minimal project - a form with two buttons (Hello and OK) as FF3 and VB6 versions. Settings are identical in both versions. The Hello-Button is on top of the tab order (TabIndex 0 in VB) and the OK-Button has BS_DefPushButton set (Default=True in VB).
Just to make the measure full I added the same project as PBForms generated project.
- In FF3 if you press Space the Hello-Button will execute, if you press Enter then the OK-Button will execute.
- In VB if you press Space or Enter always the Hello-Button will execute though the OK-Button is the default button.
- The PBForms version behaves like VB6.
Weird...
Hi Rolf,
You did a very good test.
In VB6, the Hello-Button is on top of the tab order (TabIndex 0). Therefore, at startup, it has the input focus and therefore must be the default button (as in tab to it, per MSDN documentation). The OK button therefore has to lose its default status at startup.
MSDN
http://msdn.microsoft.com/en-us/library/aa511453.aspx
QUOTE
The default command button is invoked when users press the Enter key. It is assigned by the developer, but any command button becomes the default when users tab to it.
.
.
Any command button becomes the default when users tab to it. If the input focus is on a control that isn't a command button, the command button with the default button attribute becomes the default. Only one command button in a window can be the default.
UNQUOTE
In this case, although the user do not physically need tab to it (Hello-Button) but it is still consider to have been so since TabIndex = 0.
Your examples make this so much clearer.
Edited to add:
The PBForms version behave like FF, not VB6. I tested earlier today on PBForms 2.01. I think because underneath, both FF and PBForms use PB.
I think the test program would have been better it we would have another control on it like a text box to see how the program behaves. I tried it also with PwrDef and EZGui DDT. I noticed all act a little different which has mostly to do with where the foucus ends up after pressing OK on the messagebox.
Hi Rolf,
I have to correct myself on the PBForms example.
On Startup, it is like the one in FF. But after pressing the <Enter> key, it behave like VB6, no longer like FF.
Quote from: Rolf Brandt on March 25, 2010, 09:54:19 AM
I think the test program would have been better it we would have another control on it like a text box to see how the program behaves. I tried it also with PwrDef and EZGui DDT. I noticed all act a little different which has mostly to do with where the foucus ends up after pressing OK on the messagebox.
The input focus should return back to the Command Button that has the input focus and that trigger the messagebox.
But I think this is not the problem as long as the Command Button that has the input focus on startup is also the default (as in tab to). After taht, things should be okay already.
Exactly, it puts the focus afterwards on the Hello button.
VB isn't a good comparison. It has its own internal engine. Examining both it and the PB versions show totally different results. The buttons in the VB app aren't even Button Class windows. Neither button even has button styles including no Default Button style like the PB versions both have. It is like an app built with Delphi or some other big tool that doesn't even use real windows half the time but internal classes that it just draws and does its own thing with. On startup both PB versions have all the proper messages, notifications, and a SetFocus...the VB is missing about half of them and never even fires a SetFocus so it is all drawn and handled internal. To have it startup and draw like VB you'd need to handle the Default Button and tabs/arrows, etc yourself in a full True Windowed app where you handle all keys and tab order yourself. You'd soon find out it is a pain and all kinds of problems though. FF used to do it this way, but like most of the other PB designers including DDT, Paul has made it use Dialog Message processing so the Def Proc for Dialogs is used to automatically handle it all (WM_GETDLGCODE is usually sent to determine all the buttons and tab orders).
One way to possibly mimic VB would be to set the Default Button on load along with the Focus(No need for an additional SetFocus though as the first in tab order already gets a SetFocus in FF). So just set the Button to Default then once the form is displayed and the button has focus turn it off and set it back to the original...and if WM_GETDLGCODE/DM_GETDEFID is sent again by IsDialogMessage it should reset everything back to normal. Or your first tab order button could just be your Default button, then no issue.
Another test to see if VB behaves right is to put a textbox on that form and make it first in tab order then the non-default button then the default, and when tabbing from textbox to non-default to compare. In PB apps it only becomes Default if focus comes from a default button (most likely due to how it handles one event at a time and looks at each event/control as they come in dialog processing).
Hi Roger,
I tried that here with VB and a couple of PB designers. Put a textbox on it, set focus to textbox. All fire the CommandButton set to default and return focus to the textbox.
Hmm, looks like Paul doesn't block all messages in FF IDE too, when you click buttons it gives them focus and the default style(Only Command2 should be orange)...and playing with all this appears to have screwed up my tooltips.
(https://www.planetsquires.com/protect/forum/proxy.php?request=http%3A%2F%2Fwww.garstangs.net%2Fimages%2FWeirdError.jpg&hash=258783ed28b4e565a72ac8144e2992f4b3a74f00)
Also, here is what I meant on the app: http://www.garstangs.net/Project1.zip (http://www.garstangs.net/Project1.zip)
Tab normally and the 1st button never gets default, Shift+Tab to go backwards and it does.
I also monitored the messages to the first command button while doing this and on every Tab press WM_GETDLGCODE is sent to all controls. On normal Tab only SetFocus is done, on the reverse a BM_SETSTYLE is sent to it setting and removing the BS_DEFPUSHBUTTON by the dialog process...pretty interesting how Microsoft's Dialog procedure doesn't handle the buttons how they are documented to be handled.
Quote from: Roger Garstang on March 25, 2010, 04:31:17 PM
VB isn't a good comparison. It has its own internal engine. Examining both it and the PB versions show totally different results. The buttons in the VB app aren't even Button Class windows. Neither button even has button styles including no Default Button style like the PB versions both have. It is like an app built with Delphi or some other big tool that doesn't even use real windows half the time but internal classes that it just draws and does its own thing with. On startup both PB versions have all the proper messages, notifications, and a SetFocus...the VB is missing about half of them and never even fires a SetFocus so it is all drawn and handled internal.
It is a known fact that VB has its own runtime to handle its stuff. However it does things, it is also important to acknowledge that the end result is a GUI behaviour that is consistent with Windows' behaviour.
Quote from: Roger Garstang on March 25, 2010, 04:31:17 PM
Neither button even has button styles including no Default Button style like the PB versions both have.
I cannot see anything different between the Buttons created by FF and VB6, whether classic or XP theme. Unless I misunderstand you.
Quote from: Roger Garstang on March 25, 2010, 04:31:17 PM
To have it startup and draw like VB you'd need to handle the Default Button and tabs/arrows, etc yourself in a full True Windowed app where you handle all keys and tab order yourself. You'd soon find out it is a pain and all kinds of problems though.
To have it start up and draw like VB (we are talking here specifically about the command button button with the first tabstop not getting default) is to expect the startup GUI to be according to Windows' guideline, isn't it?
How VB6 does it, and it does it right, is not relevant here in this specific problem. FireFly is a GUI and RAD tool. This is the reason why I am using it. And I expect it to start up and draw in its own way to standard Windows behaviour.
Quote from: Roger Garstang on March 25, 2010, 05:07:59 PM
Also, here is what I meant on the app: http://www.garstangs.net/Project1.zip (http://www.garstangs.net/Project1.zip)
Tab normally and the 1st button never gets default, Shift+Tab to go backwards and it does.
Your example sidetrack from the problem in the first post. But it show up another problem.
I created one like yours with PBForms 2.01, attached with codes and exe. Button1, the non-default button, gets the default visual when tab to it both forward and backward.
Here is some info about VB's ThunderRT6 classes:
http://oreilly.com/catalog/subhookvb/chapter/ch01.html
Roger,
the example with the RichEdit is not ideal, because the RichEdit control is multiline. So it will catch and execute the Enter keys. The same happens if you use a multiline textbox. If a textbox is not multiline then the button that is set to BS_DEFPUSHBUTTON will fire.
Here VB6's ThunderRT6 textbox does not work the same - even if it is set to multiline the DefPushButton will fire. So if you are using muliline textboxes on a VB6 form you can not use a button that is set as Default=True.
In most other things the VB6 ThunderRT6 classes behave of course conform to Windows.
By the way aren't we getting lost a little from the original problem that the this thread addressed???
I don't think we are getting sidetracked at all from the problem...in fact the last page here is probably closer to solving it than the first. To Answer Cho's question on VB which Rolf already posted about the Thunder RT6 classes is that, like we already know when using something like WinSpector, VB isn't using the same "engine" to process input. That engine being the dialog way of processing. And, while they look like buttons in VB they are not true buttons. A better comparison would have been a straight C++ app...possibly even one not created in VS.
The PBforms app just posted though is interesting in that DDT fixes one of the two problems, so while it exibited the same problem of not having the button as default on Load it does do it bi-directional. Since it has been said many times over at the PB forums that DDT uses the dialog based processing that is the same as what FF uses then they must have a step Paul missed to get bi-directional. I think it can be solved with WM_GETDLGCODE. He already has a "patch" so to speak to allow tabbing out of multi-line text boxes that while non-standard I like...one step further would be perhaps a test along the same lines of checking the next control to get focus with WM_GETDLGCODE and if it doesn't return DLGC_DEFPUSHBUTTON we set the style just as I saw above when monitoring the messages. Sometimes it may send the set style twice setting the same style, but at least it will be set correctly. Same thing during the first set focus, or perhaps monitoring SetFocus messages so if someone calls it in code it will do it as well. This would then solve all problems.
Just confirmed that DDT/PBforms does most of the same steps as FF apps, just a couple missing. For some reason when a control gets focus WM_GETDLGCODE is sent to it 4 times and when it loses focus it gets WM_GETDLGCODE sent to it twice. Holding shift also rapidly sends WM_GETDLGCODE to all controls. The problem seems to be that the dialog processing only cares about focus leaving a default button. In the PBforms app when I tab from the textbox to the default it gets the 4 WM_GETDLGCODE messages and redundantly sets itself to non default then back when it was already default from the focus being in the text box. The FF app didn't do anything when focus changed from textbox to default button. So, DDT does additional things. When focus went from default to another control they both behaved the same as well.
So, I think what we need is just the initial focus if a button is not set to default in WM_SETFOCUS messages and when coming from any control not returning DLGC_DEFPUSHBUTTON from WM_GETDLGCODE to a button also not returning DLGC_DEFPUSHBUTTON since those are the only ones missing. The DLGC values are also OR'd, so will need to boolean test for the DLGC_DEFPUSHBUTTON bit.
I had a big complicated procedure checking current and next control and only changing if coming from and going to certain types, etc...but ended up just fixing it with this at the end of the WM_SETFOCUS case in the Form CodeProc in the generated Form.inc file (Right before your own code that is the subclass function for every control):
If (SendMessage(hWndControl, %WM_GETDLGCODE, 0, 0) And %DlgC_UnDefPushButton) = %DlgC_UnDefPushButton Then ' Button and Not Default
DefButton= GetDlgItem(GetParent(hWndControl), 1)
If DefButton <> 0 Then SendMessage(DefButton, %BM_SETSTYLE, %BS_PushButton, %TRUE)
If DefButton <> wParam Then SendMessage(hWndControl, %BM_SETSTYLE, %BS_DefPushButton, %TRUE)
End If
Logic with that may need some work. I tried it without a Default button declared and it seems to reverse the logic and it stops the first setfocus from working since prev focused item is nothing so wParam= 0 along with the default button then being 0. Then the multiline textboxes/richedit mess with it. Paul may need to modify his tweak for multiline tabbing to return something different for them in WM_GETDLGCODE or something so they don't capture Tab but still get the keys they need. Too many variables to keep track of and make it all work. Personally I'm fine with it behaving how it does since I've been using Windows from 3.0 days and use a lot of the old key navigation M$ changed in Win95+, but luckily kept it so far for backwards compat. I've always used spacebar for buttons and enter only for default button. Maybe if someone is liked by Bob they could ask him how he handled it in the PB forum...perhaps he has a better way we could combine with this.
FWIW- Phoenix has the same issues and more (On entry the first button gets focus and no default like FF/DDT, and when tabbing for some reason it will actually remove the default border on the 2nd button then it comes back next cycle which is weird because I see no custom code doing anything special other than it had no themes and it only passes the message to the Dialog handler like FF does)...plus it appears to force all of your Default buttons to be labeled OK. I created the same app in it hoping it would shed some light on things since he knows a lot about all the inside stuff and shares his knowledge better than PB...but it didn't get any further.
Whew! Having been away for awhile, there's a lot to catch up on!!!
Although I've read the 2 pages of this thread twice, I know I'm missing something. I haven't had a chance to try all the test code yet, so that might be what I'll do this week.
However, for me personally, it would be most helpful if someone could provide a clearly written set of guidelines that provides guidance on what's the right/best thing to do in the various situations.
For example:
- If you want to load a form and have a particular command button be the default and have focus (to ignore what the user types and only accept Enter), then do these things...(show code)
- If you want to load a form and have a textbox receive keystrokes while a command button receives Enter, then do these things...(show code)
- If...(show code)
In this way, the result of all this testing is that we have captured the "right" things to do so that we don't have to figure them out each time in the future...especially helpful to those of us who aren't programming everyday and need a periodic "quick-reference" refresher...
Thanks,
-JohnM
Quote from: John Montenigro on March 29, 2010, 10:26:14 AM
For example:
- If you want to load a form and have a particular command button be the default and have focus (to ignore what the user types and only accept Enter), then do these things...(show code)
- If you want to load a form and have a textbox receive keystrokes while a command button receives Enter, then do these things...(show code)
...
Ex1- Set style of button to BS_DEFPUSHBUTTON and put it first in Tab Order, then it will get focus and Default status. Space/Enter will then click button.
Ex2- Set style of button to BS_DEFPUSHBUTTON and put textbox first in Tab Order.
Those two should work fine. The only things not working to M$ standard found in this thread is a Non-Default Button First in Tab Order should get Default State, and Multiline Text Boxes/RichEdit tabbing to a Button not giving it a Default highlight either (Thought it was more, but appears to just be that). I think Paul can mix my last code with his tweak allowing tabbing from Multiline Textboxes to give the buttons the highlight. And, the last half of whatever he makes to apply to RichEdit since they allow tabbing out without the tweak, but still don't give the highlight.