I'm creating a dialogbox with a picture control and whenever I initialize the dialog it sets the focus to that picture control, is there any way to give dialog the default without resetting the focus from picture control?
When you get the WM_INITIDIALOG message in your dialog procecure, if you return FALSE then it will not set the focus to one of the controls in the dialog.
from http://msdn.microsoft.com/en-us/library/ms645428(VS.85).aspx
The dialog box procedure should return TRUE to direct the system to set the keyboard focus to the control specified by wParam. Otherwise, it should return FALSE to prevent the system from setting the default keyboard focus.
Normally, what you would do is set the focus to whichever control you choose in WM_INITDIALOG and then return FALSE to prevent windows from changing the focus.
Related
I am trying to make a password dialog box in a visual studio software. As soon as my password dialog box opens, I want the cursor to be placed in the edit control box so I can type password on it.
How can I put or place cursor in a text edit box in visual studio MFC without a mouse click?
Please suggest me how to do this.
static CEdit *ptrCurrentEditWindow;
BOOL GET_PASSWORD::OnInitDialog()
{
CDialog::OnInitDialog();
SetDlgItemText(IDC_PASSWORD, L"");
ptrCurrentEditWindow = &m_wnd_password;
return TRUE;
}
The documentation for CDialog::OnInitDialog explains, how to do this. The return value section has this information:
Specifies whether the application has set the input focus to one of the controls in the dialog box. If OnInitDialog returns nonzero, Windows sets the input focus to the default location, the first control in the dialog box. The application can return 0 only if it has explicitly set the input focus to one of the controls in the dialog box.
That leaves you with 2 options:
Make your edit control the first control, and have Windows handle everything for you by returning TRUE.
Move input to your edit control manually (CDialog::GotoDlgCtrl), and return FALSE.
Addressing the updated question: The implementation already does, what you need, as long as you make IDC_PASSWORD the first control in your dialog template. If you do not want to or cannot arrange for this, you'll have to manually move input focus, like this:
BOOL GET_PASSWORD::OnInitDialog()
{
CDialog::OnInitDialog();
// Not needed; an edit control is initially empty
SetDlgItemText(IDC_PASSWORD, L"");
// Set input focus to the desired control
GotoDlgCtrl(GetDlgItem(IDC_PASSWORD));
// Let the framework know, that you already set input focus
return FALSE;
}
I did a SetFocus to a button in a dialog. The button gets the dashed outline. When the user presses the return key, the dialog get a IDOK message rather than a message from the button were I set the focus. The same thing happens under other circumstances.
Why is this happening? And how can I cause the return to act as a button press?
Plain c++ windows app, no MFC, no NET.
Feature, not a bug. The [Enter] key operates the button that's marked as the default button for a dialog. Either with the DEFPUSHBUTTON in the .rc file or the BS_DEFPUSHBUTTON style flag. Which is typically the "OK" button so getting IDOK back is expected. The [Escape] key is special that way too, typically the [Cancel] button. This is bound to ring a bell if you think back on how you used dialogs before.
You click a button that has the focus by pressing the space bar instead.
In another SO question I found KB article that might help you:
If a dialog box or one of its controls currently has the input focus,
then pressing the ENTER key causes Windows to send a WM_COMMAND
message with the idItem (wParam) parameter set to the ID of the
default command button. If the dialog box does not have a default
command button, then the idItem parameter is set to IDOK by default.
When an application receives the WM_COMMAND message with idItem set to
the ID of the default command button, the focus remains with the
control that had the focus before the ENTER key was pressed. Calling
GetFocus() at this point returns the handle of the control that had
the focus before the ENTER key was pressed. The application can check
this control handle and determine whether it belongs to any of the
edit controls in the dialog box. If it does, then the user was
entering data into one of the edit controls and after doing so,
pressed ENTER. At this point, the application can send the
WM_NEXTDLGCTL message to the dialog box to move the focus to the next
control.
According to MSDN,
Dialog Box Keyboard Interface
The system provides a special keyboard interface for dialog boxes that carries out special processing for several keys. The interface generates messages that correspond to certain buttons in the dialog box or changes the input focus from one control to another. Following are the keys used in this interface and their respective actions.
...
ENTER: Sends a WM_COMMAND message to the dialog box procedure. The wParam parameter is set to IDOK or control identifier of the default push button.
Since the system intercepts and processes ENTER key pressed directly through the dialog, you'll need to handle it in your dialog box procedure by calling GetFocus() to first see which control has the focus, and perform the appropriate action for that particular control.
Does anyone know why Labels and Frames (and possibly other controls) have a TabIndex property in VB6? Is there some use for it; some feature of GUI programming I ought to be incorporating in my applications (that I am blissfully unaware of)?
To confirm what Cody said in the comments. The VB6 manual entry for TabIndex says:
Controls that can't receive the focus (Frame and Label controls) remain in the tab order but are skipped during tabbing.
but
If you press the access key for a Frame or Label control, the focus moves to the next control in the tab order that can receive the focus.
TabIndex is the property used to determine the sequence of focused controls when user presses TAB key.
If control with TabIndex=5 is focused and user presses TAB, control with TabIndex=6 will take focus.
Is there a method such that a user can click on the form itself, and in doing so remove focus from whatever object (textbox, combobox, etc) currently has it? Basically, can focus be uniformly removed from everything at once?
Setting the focus to the form itself does not work.
I thought about doing the old "hide a placeholder button behind another object" trick, but I'm really not a fan of that.
Thanks!
In VB6 a PictureBox can get focus, even if it does not contain any control.
In your case you can put a PictureBox with TabStop false, BorderStyle set to 0, TabIndex set to 0 behind every other control but not containing any focusable control and stretch it to ScaleWidth by ScaleHeight at run-time.
You have to put the labels and any windowless control in this background PictureBox too.
This way when the user clicks "on the form" the focus will "go away". With "no focus" Tab key will focus first control (the one with TabIndex set to 1).
When a form is active, something generally HAS to have focus. It sounds like you're just wanting to not "show" that a particular control has focus.
If that's the case, it's going to depend on the controls. Some have properties that control whether or not the specific control "indicates" its focus in some way.
But the built in Windows controls will always show their focus state unless you subclass them
Given this problem. I'd probably put a button on the form , then move it offscreen when the form loads. Make sure it's not a tab stop, but then when you want to hide focus, set focus specifically to the button, make sure the button is STILL in the tab order, even though it's not a tab stop, so the user can press tab while on the button and end up somewhere logical.
Don't have VB handy, but could you simply remove TabStop?
for x = 1 to me.Controls.count
me.Controls(x).TabStop = 0
next
I have a picturebox and a control on a form.
Private Sub cmdButton_Click
PictureBox.setFocus
Exit sub
End sub
The control doesn't change its appearance, nor does the picturebox.
Of course you'll need to add an If-Then clause if you want the control to respond normally sometimes.
I have a form with a progress bar and a cancel button which is displayed as a process runs. The buttons "Cancel" property is set to true so pressing escape, cancels the process.
But, as the button is the only control on the form capable of taking the focus, should the user inadvertently press enter (or space bar) while the process is running it will be cancelled.
I have prevented the Space Bar from working by setting KeyPreview to true (on the form) then setting KeyAscii to 0 but this approach deson't seem to work for the enter key as the button click event fires first.
I've tried setting the button's TabStop property to "false" - no change.
In my opinion, the Enter key should activate the cancel button. Or are you requiring the user to reach out for the mouse? why?
I suggest adding just a confirmation dialog after the user cancels the operation, so if anyone accidentally presses the Enter key have the chance to resume saying 'no, I don't want to cancel'.
But as a user I would be annoyed if the Cancel button has the focus and I can't activate it pressing the Enter key on my keyboard.
My 2 cents
Add a default button with size 1x1, no caption, no border, etc. Make a handler for it that does nothing. The Escape key will still do a cancel as it does now.