Can you explain why this happens? Here are steps to reproduce the exception:
Drag-n-drop a TextBox on a form. Add any other focusable control such as a button on the form.
Add 2 event handlers for that TextBox as follow:
private void textBox_GotFocus(object sender, EventArgs e){
((TextBox)sender).HideSelection = false; //<-- exception highlighted at here.
}
private void textBox_LostFocus(object sender, EventArgs e){
((TextBox)sender).HideSelection = true;
}
Run the form and first click on the textBox, then click on the button then click on the textBox again, and the exception will throw: "Win32Exception - error creating window handle".
The code is simply to make the HideSelection change accordingly when the textBox gets focused and loses focus.
UPDATE
I don't know why is so volatile, I created another project and now the problem is different, there is no exception but an indefinite loop which makes the textbox flicker, the form doesn't seem to responsive, the CPU usage is consumed up to about 17-20%. The last demo is still opened and that demo still has the Win32Exception thrown. Not a clue at all. Now the code of the two projects are the same but the problems are different.
Well, there are a couple of things to note.
First of all, HideSelection doesn't hide or unhide the selection. It specifies, whether the selection will be hidden (or not) when the control loses focus. So it's pointless to change it when the TextBox becomes focus'ed.
What you're doing in LostFocus is default, btw. Why there is an exception in GotFocus is burried within Windows API, I guess. Maybe some undefined state when HideSelection checks inside a focus changed event whether the TextBox has focus or not or tries to hide the selection which is not shown.
Edit: It's not the Windows API on the first hand, but the framework. It tries to "recreate the handle" in the setter of HideSelection if it is changed (don't know why yet - would have to analyse sources) and seems to fail (don't know why either).
Edit2: Finally there's some problem in Win32 DestroyWindow - which leads to skipping the creation of the new window. Maybe because the old one is "in use" in the focus change events?
Interestingly, as soon as the exception occurs (for me), the LostFocus event is fired, immediately followed by GotFocus which throws another exception a.s.o. thus blocking the GUI. Both assignments to HideSelection throw the exception.
Also, when you click the TextBox, any selection is deselected automatically. This, however, is not the reason for the problem, because the exception is thrown if you change focus by pressing Tab (whose normal behaviour is to restore focus). But it may be related (state problems).
If you actually want to restore the selection, you could do it like this:
int selStart;
int selLen;
void textBox1_LostFocus(object sender, EventArgs e)
{
selStart = textBox1.SelectionStart;
selLen = textBox1.SelectionLength;
}
void textBox1_GotFocus(object sender, EventArgs e)
{
BeginInvoke((Action)(() =>
{
textBox1.SelectionStart = selStart;
textBox1.SelectionLength = selLen;
}));
}
I repro this crash. You can easily see it going wrong by setting breakpoints on your event handlers, note how they fire over and over again before your program bombs. The explanation is a bit long winded, I'll give the short version first. The MSDN documentation for the LostFocus event gives stern warnings, both a Note and a Caution, pointing out that this is a low-level event that is dangerous. These events are also hidden in the Properties window for that reason. Fix your problem by using the Enter and Leave event instead.
The long version: the TextBox.HideSelection property is rather special. It is related to the way some properties on native Windows controls are specified. These controls are created with the CreateWindowEx() winapi function, it takes a dwExStyle and dwStyle argument, flags that specify style options for the window. The HideSelection property is such a style flag, ES_NOHIDESEL.
That presents a problem when you want to change the property. Difficult because it can only be specified when the native control is created. Winforms does something pretty heroic to deal with that limitation, it destroys the native control and re-creates it.
That can have pretty interesting side effects, to put it mildly. Most are not observable, but you do for example see the window on the screen getting destroyed and recreated. That's why it flickers. The core problem with your code is, inevitably, because the native window is getting destroyed it also loses the focus. So the LostFocus event immediately fires, right after you got the GotFocus event. Which does something unfortunate, it again changes the HideSelection property. Which forces Winforms to recreate the native control again.
This repeats over and over again when your GotFocus event handler yet again runs for the new native control. This does eventually end when Windows puts a stop to it and doesn't allow any more native windows to be created, it pulls the plug at 10,000 controls after a while. Which generates the "Error creating window handle" exception.
The Enter and Leave events should always be used for focusing events, they only fire if the user actually moved the focus, and don't fire when it happened because of other reasons, like this one. Also notable is that there's no point at all in changing the HideSelection property like you do, the property only has an affect when TextBox doesn't have the focus. The selection is never hidden when it has the focus. So the proper fix here is remove these event handlers and simply set the HideSelection property to True in the Properties window. The default value.
Cant reproduce this works for me:
private void textBox1_Leave(object sender, EventArgs e)
{
((TextBox)sender).HideSelection = false;
}
private void textBox1_Enter(object sender, EventArgs e)
{
((TextBox)sender).HideSelection = true;
}
Related
I've got the following:
private void fooForm_Enter( object sender, EventArgs e )
{
FooBar()
}
private void FooBar()
{
Console.Out.WriteLine( "Foo" );
/*
do stuff
*/
OtherControl.Focus();
}
The problem I'm experiencing here is that I get to see the text in the console twice, even though I only put focus on the fooForm once. However, if I comment out the OtherControl.focus() line, FooBar will only be called once. (No, OtherControl is not the same object as fooForm.)
What causes this and what can I do to make sure FooBar is only called once?
According to the MSDN Documentation:
Do not attempt to set focus from within the Enter, GotFocus, Leave, LostFocus, Validating, or Validated event handlers. Doing so can cause your application or the operating system to stop responding.
You appear to be doing just that.
As from MSDN:
The Enter and Leave events are hierarchical and will cascade up and down the parent chain until the appropriate control is reached.
Thus, your fooForm receives Enter event for its children too.
Also notice, from the same MSDN article:
Do not attempt to set focus from within the Enter, GotFocus, Leave, LostFocus, Validating, or Validated event handlers. Doing so can cause your application or the operating system to stop responding.
I did a bit more googling and found a good solution to achieve the functionality I wanted without setting the focus in those events as per the solution here: Alternative to set focus from within the Enter event
Following is my code to handle gotfocus and lostfocus event for all textboxes available in form.
private void Form1_Load(object sender, EventArgs e)
{
foreach (Control c in this.Controls)
{
if (c is TextBox)
{
c.GotFocus += new System.EventHandler(this.txtGotFocus);
c.LostFocus += new System.EventHandler(this.txtLostfocus);
}
}
}
private void txtGotFocus(object sender, EventArgs e)
{
TextBox tb = (TextBox)sender;
if (tb != null)
{
tb.BackColor = Color.Silver;
tb.BorderStyle = BorderStyle.FixedSingle;
}
}
private void txtLostFocus(object sender, EventArgs e)
{
TextBox tb = (TextBox)sender;
if (tb != null)
{
tb.BackColor = Color.White;
tb.BorderStyle = BorderStyle.Fixed3D;
}
}
It works fine with first textbox but when I go to next textbox by pressing tab key it will repeatedly call both events and textbox behave like blinking. After some time error message display in code like:
A callback was made on a garbage collected delegate of type 'System.Windows.Forms!System.Windows.Forms.NativeMethods+WndProc::Invoke'. This may cause application crashes, corruption and data loss. When passing delegates to unmanaged code, they must be kept alive by the managed application until it is guaranteed that they will never be called.
Whats wrong with code? Is there any solution?
c.LostFocus += new System.EventHandler(this.txtLostfocus);
LostFocus is a dangerous event, the MSDN Library article for Control.LostFocus warns about this and strongly recommends to use the Leave event instead. This is something you can see in the designer, drop a TextBox on the form and click the lightning bolt icon in the Properties window. Note how both the GotFocus and LostFocus events are not visible. You must use the Enter and Leave events instead.
Some background on what is going on here. Your program blows up because you assign the BorderStyle property. That's a "difficult" property, it is one that affects the style flag of the window, the one that's passed to the native CreateWindowEx() function. So changing the border style requires Winforms to create the native window again. This is what causes the flicker you see, the text box is destroyed and re-created, then repainted. You see that.
But that has side-effects beyond the flicker, it also causes the low-level GotFocus and LostFocus events to fire. Because the destroyed window of course also loses the focus. This interacts very poorly in your program since your LostFocus event handler changes the BorderStyle again, forcing Winforms to yet again recreate the window. And fire the GotFocus event, you change the BorderStyle yet again. This repeats over and over again, you see the textbox rapidly blinking. This doesn't go on endlessly, after 10,000 times of creating the window, the operating system pulls the plug and doesn't let your program create yet another one. The hard crash on the window procedure is the outcome.
Not a problem with the Enter and Leave events, they don't work from the low-level Windows notification so don't fire when the textbox window is recreated. You can only get rid of the one-time flicker, if it is still bothering you, by not changing the BorderStyle property.
This occurs cause you change the borderstyle. Dont ask me why, i dont know it. If you remove tb.BorderStyle = XXX it will work. I guess(!) changing the borderstyle makes the control loose its fokus (and get it again)
Edit: Hans was faster, with a much better explanation :)
With the following code, when i move the mouse into the button and click it, the final value of result is 2 instead of 1.
static int result = 0;
private void button2_MouseHover(object sender, EventArgs e)
{
result++;
}
private void button2_MouseDown(object sender, MouseEventArgs e)
{
button2.FlatStyle = FlatStyle.System;
}
I had tried different setting:
Using MouseEnter instead of MouseHover give result = 1
Only changing of FlatStyle to System will trigger MouseHover one more time after button is clicked.
If the FlatStyle of button is originally FlatStyle.System, give result = 1;
If the FlatStyle is changed to others Style(popup, flat), give result = 1;
So i guess the problem lies with the FlatStyle set to FlatStyle.System, anyone can explains this to me?
This is a fairly common quirk in Winforms. You can visualize what's going with this code:
private void button1_MouseHover(object sender, EventArgs e) {
Console.WriteLine("{0:X}, {1}", button1.Handle, DateTime.Now.TimeOfDay);
result++;
}
Look in the Output window for the displayed diagnostic. On mine:
12780286, 03:04:10.7619696
12780286, 03:04:16.2935137
12780286, 03:04:20.1062178
12780286, 03:04:23.9970596
Click
12845822, 03:04:28.9191911
12845822, 03:04:32.3099880
Note how the Handle property value changed after the click. In other words, the physical Windows window changed. This happened because you changed the FlatStyle property. Winforms implements this by destroying the button control window and recreating it. If you look really close then you can actually see this, the button briefly flickers.
There are a few properties that are implemented like this, they are "heavy" properties that requires the window to be recreated since the style flags changed. Style flags that are passed in the native CreateWindowEx() call. A change in those style flags requires another call to CreateWindowEx().
This tends to have side-effects. Destroying the old window causes its state to be lost. Winforms tries to restore the state of the new window as best it can, but there are a few it cannot get to. The "window was hovered" state is one of them. Clearly the new window has that internal state flag set to false. Which is why you get the MouseHover event again. You'll need to work around this quirk.
I want to bring the cursor to a textbox when i clicked a button. How can i do that? I tried Focus() method but it didn't not work. The code is shown below.
CsNIPAddrTextBox.Focus();
CsNIPAddrTextBox.TabIndex = 1;
Try textbox1.select(). It's the best approach to bring your cursor to your textbox. It also selects content of the texbox which makes it easier for the user to edit what's inside the textbox.
If that's a 'proper' TextBox (i.e. not custom) then simply calling Focus() should work. It might not, however, if it's read-only (I'm not sure - I've not tried. I know you can get a caret in a read-only box, which implies it can get focus). Certainly if it's not Enabled then you won't be able to set focus.
Check the CanFocus property is true - if it's not, then there might be some other reason preventing the control from receiving focus.
If that's true, however, and the caret still doesn't make it to the control - you need to verify that it is receiving it. Add an event handler for the text box's GotFocus event and breakpoint it to clarify that it gets hit. My guess is that it your breakpoint will be hit. If so - then the answer is that another process is setting focus to another control immediately after your button click occurs. For example, if you do this kind of thing in a validation event handler you'll get a similar result, because the Windows Forms pipeline is already in the process of changing controls when the handler is fired.
Also - why are you setting TabIndex=1? Generally TabIndex is set at design time and left alone (unless of course these are dynamically created). Unless you have a particular reason for doing this I'd get rid of that line. It doesn't have a bearing on why this would/wouldn't work - just an observation.
Edit again:
If you try to select a TextBox in the Click event of a TreeView, it usually fails, because after the Click event the TreeNode will be selected, making your previous Focus() or Select() useless. The workable way is, perhaps, calling them in a Timer.
Timer t = new Timer();
t.Interval = 10;
t.Tick += new EventHandler((s,ev)=>textBox2.Focus());
t.Start();
This is more like a hack though...
Set theActiveControl property of the form
ActiveControl = yourtextbox
You have to use TextBox.Select Method
For example
textbox1.Select(textbox1.Text.Length,0);
Sets the cursor to the end of the text in yout textbox.
If i read right you are talking about moving mouse cursor to the textbox? - Then you can use code like this:
System.Windows.Forms.Cursor.Position =
PointToScreen(
new Point( textBox1.Location.X + 5, textBox1.Location.Y + 5)
);
I know many of you had provided answers, but this may be useful to some who weren't able to get from previous responses.
This worked for me, setting Select() on input text had set the cursor to the textbox.
Have this in form constructor:
this.Activated += OnActivated;
Handler Code:
private void OnActivated(object sender, EventArgs eventArgs)
{
txtUser.Select();
}
if textbox.Multiline=true and/or textbox.WordWrap = true, the cursor might be hiding at the bottom of the field.
I am pasting text in textbox1.text and I need textbox1 should fire its leave event by itself.
For now I am using this following code. but i will appreciate if anyone can suggest me an elegant or better way:-
private void event()
{
textbox1.Text = SearchedText;
textbox1.Focus();
textbox2.Focus();
}
First I am pasting text, then setting up Focus on the control, then set up focus again on second control. It is firing leave event of textbox1, but any thing better?
Just call the code directly, no need to wait for an event:
private void textBox1_Leave(object sender, EventArgs e) {
mumble();
}
private void someEvent() {
textBox1.Text = SearchedText;
mumble();
}
void mumble() {
// etc...
}
Just calling textBox1_Leave(this, EventArgs.Empty) works fine too.
You should handle the TextChanged or Validated events instead of the Leave event.
To FORCE Leave, Validating and so on Events, no matter what, I've found ONE working solution.
First i tried:
ProcessTabStop(true);
ProcessTabStop(false);
instead of:
textbox1.Focus();
textbox2.Focus();
Problem with the TextBox 1 and 2 Focus() is that its only Active Component that needs Leave, Validating and so on fired, not other Controls, and besides, what if the form is dynamic, you as a programmer not necessarily have any idea what Control you are trying to Leave, that's why i changed Control.Focus() method to ProcessTabStop method above. The problem is then, if only ONE Control has TabStop true, there is no control to go to and back from. So Events are NOT Fired.
Next problem is that i not necessarily Close the Form with the mouse so Focus doesn't change, I use a Key (Ctrl+Enter) to Accept the Form, and then Leave, validating and so on are NOT fired, when i Send Form Close, as Form Close registers weather there are changes or not. But Values are set in Leave on TextBoxes, so I had to find a solution that worked no matter what i did to it. I almost gave up, actually i had a problem report all filled out, when I thought, what if i set ActiveControl to Null and then to the Control it came from. It worked, but had som "Flicker" due to color change on Parent Panel depending on Active or Inactive.
The "Workaround" that works in all cases is:
Control Old = ActiveControl;
// ActiveControl.SuspendLayout();
// ActiveControl.FindForm().SuspendLayout();
ActiveControl = null;
ActiveControl = Old;
// ActiveControl.FindForm().ResumeLayout();
// ActiveControl.ResumeLayout();
That seems to fire Leave, Validating and so on Events, no matter number of Form Controls and TabStopped Controls. You MAY need to SuspendLayout on either ActiveControl, or Form. My Control (Parent Panel) changes color when Active/Inactive, if I do not Suspend Layout on Form, parent panel gets an unwanted "flicker" effect.
Looking at the solution, it is very obvious, now I've found it, but took me half a day to try different things that solved one or another problem, but not all.
I know this a VERY old thread, but one of very few articles I've found on the subject of Forcing Leave Event to be Fired.