TabStop = False changed (automatically) to True after compilation (VS 2008, Win form)

[vanderghast]

Problem with TabStop set to false changed to true by VS 2008 after
compilation.


Have a Window Forms Control library project, have the default user defined
control, add one text box, one frame with two radio buttons inside it
(labels kPa and psf), check the radio button kPa. (Code below).

In VS 2008, have the visual designer for the control, click on the kPa radio
button, find its TabStop property, change it to False. Save, keep the file
open though. Run (debug version is OK). Observe that the kPa radio button
CAN get the focus by using the tab key. Get out of debug mode. Check the
TabStop property for kPa, it is still to false. Close the file from the
visual designer. Open the file from the visual designer, check the TabStop
property, for kPa, it is reported to be true.

My problem is not much with the Visual Designer not being refreshed, but by
how to keep the TabStop property of the kPa radio button to FALSE. In fact,
I, well, a user, want that radio button be accessible with the mouse, but
not with the tab key, because the scenario is a form with many of these
controls, and the tab key to cycle trough the text-box parts, NOT passing
over the 'radio buttons', since 99% of the time, kPa is the right unit, the
end user simply want to type: 2 [tab] 1.8[tab] 1.44[tab] -1.1 instead of
the actual 2 [tab][tab] 1.8 [tab][tab] 1.44[tab][tab] -1.1.


The same problem exists with the disposition inside a Win Form rather than
in a UC.




------------------------------
namespace WindowsFormsControlLibrary1
{
partial class UserControl1
{
/// <summary>
/// Required designer variable.
/// </summary>
private System.ComponentModel.IContainer components = null;

/// <summary>
/// Clean up any resources being used.
/// </summary>
/// <param name="disposing">true if managed resources should be
disposed; otherwise, false.</param>
protected override void Dispose(bool disposing)
{
if (disposing && (components != null))
{
components.Dispose();
}
base.Dispose(disposing);
}

#region Component Designer generated code

/// <summary>
/// Required method for Designer support - do not modify
/// the contents of this method with the code editor.
/// </summary>
private void InitializeComponent()
{
this.textBox1 = new System.Windows.Forms.TextBox();
this.groupBox1 = new System.Windows.Forms.GroupBox();
this.radioButton1 = new System.Windows.Forms.RadioButton();
this.radioButton2 = new System.Windows.Forms.RadioButton();
this.groupBox1.SuspendLayout();
this.SuspendLayout();
//
// textBox1
//
this.textBox1.Location = new System.Drawing.Point(12, 19);
this.textBox1.Name = "textBox1";
this.textBox1.Size = new System.Drawing.Size(45, 20);
this.textBox1.TabIndex = 0;
//
// groupBox1
//
this.groupBox1.Controls.Add(this.radioButton2);
this.groupBox1.Controls.Add(this.radioButton1);
this.groupBox1.Location = new System.Drawing.Point(63, 3);
this.groupBox1.Name = "groupBox1";
this.groupBox1.Size = new System.Drawing.Size(111, 45);
this.groupBox1.TabIndex = 1;
this.groupBox1.TabStop = false;
//
// radioButton1
//
this.radioButton1.AutoSize = true;
this.radioButton1.Checked = true;
this.radioButton1.Location = new System.Drawing.Point(6, 19);
this.radioButton1.Name = "radioButton1";
this.radioButton1.Size = new System.Drawing.Size(44, 17);
this.radioButton1.TabIndex = 0;
this.radioButton1.Text = "kPa";
this.radioButton1.UseVisualStyleBackColor = true;
//
// radioButton2
//
this.radioButton2.AutoSize = true;
this.radioButton2.Location = new System.Drawing.Point(56, 19);
this.radioButton2.Name = "radioButton2";
this.radioButton2.Size = new System.Drawing.Size(39, 17);
this.radioButton2.TabIndex = 1;
this.radioButton2.Text = "psf";
this.radioButton2.UseVisualStyleBackColor = true;
//
// UserControl1
//
this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F);
this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;
this.Controls.Add(this.groupBox1);
this.Controls.Add(this.textBox1);
this.Name = "UserControl1";
this.Size = new System.Drawing.Size(183, 57);
this.groupBox1.ResumeLayout(false);
this.groupBox1.PerformLayout();
this.ResumeLayout(false);
this.PerformLayout();

}

#endregion

private System.Windows.Forms.TextBox textBox1;
private System.Windows.Forms.GroupBox groupBox1;
private System.Windows.Forms.RadioButton radioButton2;
private System.Windows.Forms.RadioButton radioButton1;
}
}

 

[Peter Duniho]

Problem with TabStop set to false changed to true by VS 2008 after
compilation.


Have a Window Forms Control library project, have the default user
defined control, add one text box, one frame with two radio buttons
inside it (labels kPa and psf), check the radio button kPa. (Code below).

In VS 2008, have the visual designer for the control, click on the kPa
radio button, find its TabStop property, change it to False. Save, keep
the file open though. Run (debug version is OK). Observe that the kPa
radio button CAN get the focus by using the tab key. Get out of debug
mode. Check the TabStop property for kPa, it is still to false. Close
the file from the visual designer. Open the file from the visual
designer, check the TabStop property, for kPa, it is reported to be true.

I believe what you're seeing is by design. Note that the default value
for TabStop is actually "false". But, the Designer, and the Forms code
itself, treat two or more radio buttons as a virtual group, one that you
don't have control over tab stops for. The first radio button in a
group will get its TabStop value set to "true", and the Designer will
reset that when you reload the component being designed (form or user
cotnrol).

My problem is not much with the Visual Designer not being refreshed, but
by how to keep the TabStop property of the kPa radio button to FALSE.

You can't. The Designer will always override your setting.

However, on the assumption that not being able to tab to the control
goes hand-in-hand with the control not being able to receive focus, one
possible solution is to create your own RadioButton sub-class, and in
the constructor, set the Selectable style to false:

SetStyle(ControlStyles.Selectable, false);

A control that can't receive focus will also not be eligible to be a tab
stop.

Now, that said: your proposed design deviates from normal behavior in
what could in fact be a fairly annoying way. You will force the user to
use a mouse to change the radio button setting. For some users, this is
a serious accessibility issue, and for others it's simply a major annoyance.

Just because the majority of the time, a user will not change that
particular setting, that's no excuse for blocking them from being able
to change it easily when they want to.

I advise you to not pursue this particular design. Just because there
is in fact a way to accomplish it, that doesn't mean it's a good idea
for you to do so. The extra tab key press is an incredibly minor
inconvenience as compared to forcing a user to switch from the keyboard
to the mouse just to change one setting. Users who want to skip that
setting will quickly learn the correct key-press rhythm, and those who
occasionally do want to change it will thank you for not arbitrarily
blocking them from doing so without having to switch from the keyboard
to the mouse.

Or, another way to look at it: if you are so certain that changing the
setting is such an uncommon, useless thing for a user to do that you are
willing to make it so inconvenient for them to be able to do it, why is
that setting in that form in the first place? Why have something in the
form that you expect users to just always be skipping over? Put the
setting somewhere else, out of the way where it's not interfering with
efficient use of the rest of the UI.

Pete

 

[Harlan Messinger]

Or, another way to look at it: if you are so certain that changing the
setting is such an uncommon, useless thing for a user to do that you are
willing to make it so inconvenient for them to be able to do it, why is
that setting in that form in the first place? Why have something in the
form that you expect users to just always be skipping over? Put the
setting somewhere else, out of the way where it's not interfering with
efficient use of the rest of the UI.

That's what I was thinking. Even in cases where a user is entering
measurements as psf, however rarely that may occur, unless you expect
that any user on any occasion will want to enter some measurements as
kPa and others as psf, you ought to provide only one place on the page
for the selection of the unit.

 

[vanderghast]

Since all the units would likely be the same, for a given set of inputs,
indeed, I will change the UI.

 

[Steven0100]

Peter, I understand your thought process on this, but there are situations where the radiobutton behavior that vanderghast wants is highly desirable. For instance, I am writing a program where the user can enter values in 6 different textboxes. I have radio buttons that determine how the text in the textboxes is interpreted. Considering the nature of my program, the data in the textboxes will be changed many times during the course of a session while the radiobuttons might be changed only once, if at all. In addition, I use a number of different Panels that overlay each other. These Panels are presented according to what textbox the user is in, hence if the radiobuttons were allowed to receive a tabstop, then many times they would be hidden from view and the used would be wondering where his cursor went.

That said, my solution was to set all the radiobutton.tabstop = False during the Form load and again when the radiobutton.checkchanged event is fired. Then I reset the focus back to the textbox the user is using for input.

I realize this is an old thread, but this problem had me stumped for a long time until I realized that setting the Tabstop on the radiobuttons was not doing the trick. Frankly, I find this behavior very wrong in so many ways. When you set the Tabstop to false, you expect it to be false. I hope this helps someone else who stumbles upon this thread.

FYI, I have always considered a program user friendly when a user has 2 or 3 ways to do the same thing. In this case, the user can use the up/down cursor keys, the Tab key, and the mouse click to change which textbox they want to change. In addition, some textboxes allow input from a list with the right click of the mouse. Also, the user can compute calculated values either by clicking the Calculate button or pressing enter in any textbox. I'm sure this is standard procedure for most programmers, but frankly I've reviewed many programs that are similar in nature to what I am doing and they always get the job done, but are very awkward to use. I sure you already know this and this is more directed towards aspiring programmers, such as myself.