The last time I did any serious programming was 25 years ago in C with a copy of Kernighan and Ritchie. Please be gentle with an aging amateur!
In essence, it's the old nullable date picker thing. I have a solution working perfectly well with one exception. I am using a combination of a masked TextBox and a MonthCalendar. The masked TextBox simply displays any value (including null) from a data set and accepts values from the calendar. Pressing backspace in the calendar clears the masked TextBox. All This is very straightforward. All I need to do now is to hide the calendar when it loses focus. A simple example demonstrates the problem I have:
Create a form with a text box to take the initial focus, a masked text box and a hidden MonthCalendar. In the Enter event of the masked text box, I have the following code:
monthCalendar1.Visible = true;
monthCalendar1.Focus();
My intention was to put the following code into the Leave event of the MonthCalendar:
monthCalendar1.Visible = false;
For some reason, this code is triggered as soon as the calendar gets the focus and the calendar is hidden again immediately. Debugging confirms that this code is triggered. If the Leave event is empty, the MonthCalendar does indeed get the focus and retains it, because it is possible to navigate the calendar with the arrow keys.
Can anyone explain this behavior to an old fogey or, even better, give me a pointer to what I'm trying to do.
Many thanks in advance.
A work around is to delay the focus of the MonthCalendar control until after the Enter event is finished firing:
monthCalendar1.Visible = true;
this.BeginInvoke(new Action(() => { monthCalendar1.Select(); }));
Quote:
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. For more information, see the WM_KILLFOCUS topic in the "Keyboard Input Reference" section, and the "Message Deadlocks" section of the "About Messages and Message Queues" topic in the MSDN library at http://msdn.microsoft.com/library.
From MSDN. They also talk about which events happen when you get in depending on how you get in :)
Related
So I'm setting the value of a textbox, then I'll click a button to submit the search. The value in the textbox is showing what I want, but when I trigger the click of the button, the website gives me an error message on the page as if the textbox value is empty (even though I'm looking at it and it's showing what I wanted).
Now if I manually click on the button, it still thinks the textbox is empty. But if I manually click on the textbox (just click, don't change anything), then manually click on the button, it works.
So apparently there's something happening behind the scenes that requires the textbox to have had the focus before the page will recognize what's been typed in.
private void SetText(string elementID, string text)
{
foreach (HtmlWindow hw in this.webBrowser1.Document.Window.Frames)
{
HtmlElement element = hw.Document.GetElementById(elementID);
if (element != null)
{
element.SetAttribute("value", text);
// here's where I'm trying things
break;
}
}
}
Here's what I've tried (not sure all of these were even valid things, but I tried them anyway:
I've tried setting the focus on the textbox and then removing it by setting it on the button -- element.Focus() and then button.Focus() before clicking the button.
I've tried invoking the changed event -- element.InvokeMember("change"), element.InvokeMember("changed"), element.InvokeMember("onchange"), element.InvokeMember("textchanged").
I've tried invoking the focus event -- element.InvokeMember("focus").
I've tried invoking the lostfocus event -- element.InvokeMember("lostfocus").
I have no idea what it is that the webpage is expecting to be triggered when someone actually types into the textbox, but it's apparently preventing the page from "seeing" what's been placed in there by my code.
Any ideas?
Turns out there were 3 textboxes (each with a slightly different name) that are somehow interconnected. The value of all 3 must be set before the button will work properly. I thought I'd tried that, but perhaps I didn't do all 3 before, or maybe I had them in the wrong order. Ugh.
I have an interesting problem that I don't know how to solve. I wrote a form which does a password change. The form displays the current password too in a read-only TextBox (not for validation purposes; this isn't important in this case.) Each password TextBox has a button in it that when clicked, masks or unmasks the password (replacing the password characters with bullets and vice versa.) Here's an image of the whole thing:
Notice how the mask/unmask buttons are inside the text boxes, not outside of them. The buttons have been placed inside the text boxes with:
var button = new Button();
button.Width = 20;
button.Cursor = Cursors.Default;
button.FlatStyle = FlatStyle.Flat;
button.Image = SystemIcons.Shield.ToBitmap();
button.Dock = DockStyle.Right;
button.CausesValidation = false;
textBox.Controls.Add(button);
The last TextBox has validation enabled. Now the problem is, that the user is unable to click the passwork unmask button on the other text box, because the validation event fails. Thus, the user is unable to see the current password without entering a new one.
I need a way to have the password mask/unmask button be clickable even if validation is failing in the text box. I can't think of anything. Moving those buttons outside the text boxes is not an option.
The unmask buttons themselves, as well as the parents of the text boxes, all have CausesValidation set to false. Only the text boxes themselves have it set to true.
This is a .NET 2.0 C# project in Visual Studio 2010.
It's not easy to do it with the Validating event of the text box. The click event will not even reach the button when the text box loses focus. I'm thinking that you could either create your own TextBox (by extending TextBox or TextBoxBase) and hack the validation behavior there or override the form's DefWndProc and catch the mouse events + associated info (coordinates) there and still dispatch them (could get ugly) when validation fails.
One easy way out is to not rely on the Validating event anymore. Instead do the validation in the Leave event of the text box and if it fails just mark the text box as such. The user will still see there is a problem.
One more thing you need to take care of is the OK button of the dialog. You need to make sure the user won't be able to close the dialog if there are unvalidated controls on the form. Since you don't have validation support anymore, maybe you can use the Tag property to store a False (for example) when the data is not valid. On OK just iterate over all textboxes and check their tags.
The behavior for the end user will ultimately be the same, you just have to write a bit more code.
Well, I found a way where I can keep using the Validating event and still be able to click the buttons in the other text boxes. It turns out that the Button.MouseUp event is sent even if a button doesn't have focus.
So the solution is to handle both the MouseUp as well as the Click event and perform the password masking/unmasking depending on whether the text box that contains the button currently has keyboard focus or not:
button.MouseUp += (sender, e) =>
{
if (button.Parent.ContainsFocus || e.Button != MouseButtons.Left
|| !button.ClientRectangle.Contains(e.Location))
{
return;
}
textBox.UseSystemPasswordChar = !textBox.UseSystemPasswordChar;
};
button.Click += delegate
{
if (!button.Parent.ContainsFocus) {
return;
}
textBox.UseSystemPasswordChar = !textBox.UseSystemPasswordChar;
};
We do want to handle both events, because if we only handle MouseUp, then clicking the buttons with the keyboard (Tab to switch to the button, and Enter or Space to click it) would not work anymore.
I am working with a TextBox, and need to fire some logic when the textbox has lost focus.
My problem is twofold:
The Leave event is firing on every keypress for some reason, meaning the logic is run with every keypress when it should not.
When using the Focused property of the Textbox as a double-check, simply exiting out if the property is still set, it now works when the user uses the mouse to leave, but not when the user tabs out.
The Focused property of the TextBox in question is False as of when its Leave event fires when the mouse is used to change focus, but it is still True when the Leave event fires due to a Tab keypress. Seriously?
I need a workaround, because the logic firing on every keystroke is causing a problem for users right now that needs to be fixed post-haste.
I created a form with a textbox on it and attached event handler to the leave event of that text box. I then typed a bunch of stuff into said textbox. The event was not raised. I hit tab, the event was raised. I then clicked back in the textbox, typed some more, and then clicked another control and the event was raised.
I'm just saying that something else is interfering with the textbox. I would look into that a little more, or post some code demonstrating the problem.
On Windows 7 Phone, using Silverlight framework
I'd like to handle when a Button is released.
It's easy to tell when the button is pressed (Click event which is fired either when pressed or when released according to the ClickMode property)
I've played with all the other events provided with the Events editor (KeyUp, LostFocus, MouseLeave etc..)
But I'm yet to find something that is definitive in regards to getting an event when a button is released.
Ultimately, I'm trying to handle doing a click vs a long click when pressing on a button
Thanks
For your situation, KeyUp is only half of the story. You also need to handle KeyDown where you will save the current time which you will then compare to the current time value after KeyUp to determine whether the press was short or long. You also need to make sure that you track one particular key in case your handler(s) is/are intercepting all key strokes.
If for some reason ClickDown/Up don't work out you could try handling the Click event but starting with a ClickMode of press, then changing ClickMode to release on the press handler. This process, though not simple, would give you a chance to implement the down-hold and timer-release sequence that you're looking for.
I have an asp.net TextBox in which I want to check if the text entered into the TextBox is > 0. It works once I tab out or click out of the TextBox, but if I keep focus on the TextBox, it won't fire the Text Changed Event, so I have the following scenario, I want to enable something if and only if the TextBox.Text.Length = 0. Now, if I put my caret in the TextBox and delete all the characters and then leave the caret in the TextBox so it still has focus and take my mouse and click a button, it will not do what it was supposed to do because it never fired the Text Changed Event. How would something like this be handled?
friend, keyup, keydown and keypress are your friends
The best idea is to write some client-side javascript to do what you want. The TextChanged event handler requires a postback to the server, and posting back to the server before a text box loses focus is impossible. Unless that is what you intend, I would suggest the former.
you can also use the setInterval javascript method to check for a change in the value of the textbox on a timed basis. just remember, you need to use the form name followed by control name and value to reference the control.
setInterval(MethodName, 100);
function MethodName()
{
if(formname.controlid.value.length > 0)
{
//do something here
{
}