Using Windows Mobile 6.5 and C#
The CharacterCasing property seems to be missing from WinMo 6.5 and I decide to just catch the textchanged event and set the text with ToUpper.
This works - but on every keypress, it sends the cursor back to the beginning of the string, not the end.
I know this is old, but hopefully this can help somebody else. I implemented the KeyPress event like the following.
private void TextBox_KeyPress(object sender, KeyPressEventArgs e)
{
e.KeyChar = Char.ToUpper(e.KeyChar);
}
Ritu, just to comment on your answer. You should keep in mind that this might be confusing for a user if the user has positioned the caret in the middle of the string to perform some edit and then the caret jumps to the end of the string on the key press.
An alternative might be to change the text to upper case when the edit control loses focus.
Try here such implementation.
public MainForm()
{
InitializeComponent();
InitializeUpperCaseTextBox();
}
private void InitializeUpperCaseTextBox()
{
txtbox.CharacterCasing = CharacterCasing.Upper;
//... etc.
}
The soluttion of setting the text position to the end of the string seems like would be a hassle if you ever need to edit text that you have already entered.
It's been a while since I thought about the C# event model but, one alternative might be to catch the KeyPress event and change any lowercase KeyChar values to uppercase before passing them on to the next handler.
The way you are approaching seems to be wrong.
There are so many different ways to insert data into that textbox. What about copy & paste for instance?
Just perform a .Text.ToUpper() when accessing the value of the Textbox
Save the SelectionStart and SelectionLength before changing the text. The ToUpper should make no changes to the length, so you can simply set the SelctionStart and SelectionLength back to what they had been.
Also, I would expect to get a changed event again when you set it ToUpper. I'm not sure if you also need to check that the ToUpper actually changed anything before you set Text again. It may be smart enough to check that for you when you assign the text and avoiding giving you an infinite recursive loop of change events. However, you probably don't want to alter the selection in the event handler call for the case where you aren't making a further change, only in the outer call where you are assigning back to Text. So you might as well guard recursion directly.
Something like:
bool m_InMyTextChanged = false;
private void txtMyText_TextChanged(object sender, EventArgs e)
{
if (m_InMyTextChanged)
return; // Recursive! We can bail quickly.
m_InMyTextChanged = true; // Prevent recursion when we change it.
int selectionStart = txtMyText.SelectionStart;
int selectionLength = txtMyText.SelectionLength;
string originalText = txtMyText.Text;
string newText = originalText.ToUpper();
if (newText != originalText)
{
txtMyText.Text = newText; // Will cause a new TextChanged event.
// Set the selection back *after* the assignment, which has reset them.
txtMyText.SelectionStart = selectionStart;
txtMyText.SelectionLength = selectionLength;
}
m_InMyTextChanged = false; // Allow it for next time.
}
could work. I haven't worked in Windows Mobile, but I would think this would work the same as in general for .NET.
I figured it out. So on the textChanged event, I replace the entered text with the ToUpper version. Then I set the SelectionStart property to the Text.Length to move the cursor to the end.
Related
I'm writing a text control with input filtering based on TextBox.
The main idea consists of handling TextChanging event and set correct Text and SelectionStart values.
This worked until Windows 10 Creators Update. Now when I change SelectionStart in TextChanging handler I see correct caret position in UI but next character goes to the old place.
I can not share any code right now but you can reproduce it by adding arbitrary character on each TextChanging call (and setting SelectionStart after this character).
Have Microsoft broken the backward compatibility? Have I done anything wrong?
UPD: So I've found a dirty workaround:
async void OnTextChanging(TextBox sender, TextBoxTextChangingEventArgs args)
{
var newText = HandleText(Text);
var newSelectionStart = HandleTextDiff(newText, Text);
Text = newText;
await Task.Yield();
SelectionStart = newSelectionStart;
}
Task.Yield makes the assignment of SelectionStart to run asynchronously after the control internal assignment.
That's very dirty and ugly because it causes caret blinking in some cases but the only working solution I can find.
Maybe you should try setting the SelectionLength to 0
Another option might be to use SetCaretPos Api call
[DllImport("User32.dll")]
static extern bool SetCaretPos(int x, int y);
I am having trouble with getting a value in a text box before the value is changed either by user input or programmatically.
I figure it has to do with the _TextChanged event but once this executes how do I get the old value which was already there before the change?
For example number 3 is in the text field. The number then changes to 4 how do I save 3?
Thanks in advance!
Do not store anything in the TextBox. Use it only to display/edit value.
private string value;
private void textBox1_TextChanged(object sender, EventArgs e)
{
// at this moment value is still old
var oldValue = value;
value = ((TextBox)sender).Text; // text1.Text
// here you have oldValue and new value
}
Maybe you don't want to update value after each TextChanged. Maybe you will do it when form is closed, some button is pressed, etc.
Anyhow idea should be clear: if you need to have old value, then store it somewhere yourself (as a variable, as a Tag, as application setting, exporting, etc.).
Also, take care about how user will work. If TextBox contains 3, then user may first press 4 and only then delete 3. Or user may accidentally press 54. Which of those will be old value: 3, 34, 54 ? Simply to demonstrate you, what there could be consequent problems to having concept of old value. Mayhaps you don't want it and there is better solution to what you are trying to solve by getting old value.
Why not save the current value in the textbox in a variable during the textchanged event. That way, it is the "previous" value when the event is fired again.
You can save the value of textbox in some variable.
For example
string currentVal = txtName.Text;
string currentVal can be used as a previous value in text_changed event.
Have you tried making a timer. Every tick you write the input to a string. If the input of the textbox is not equal to the content in the string, you trigger what you wanted to do. That way you can trigger a void with the old input.
private string oldInput;
....
void TimerTick(Object source, ElapsedEventArgs e)
{
if (oldInput != MyTextBox.Text) MyVoid(oldInput);
oldInput = MyTextBox.Text;
}
I am using ScintillaNET to make a basic IntelliSense editor. However, I have a problem when I call _editor.CallTip.Show("random text") in the AutoCompleteAccepted Event.
If I type pr for example, and scroll and select printf in the drop-down list, it goes to my AutoCompleteAccepted event and when I call the CallTip.Show, the rest of the word does not get added (however, without that CallTip code, the rest of the word is filled).
So, if I typed pr then it stays pr and I get my CallTip. How do I make sure the rest of the word gets inserted AND the CallTip shows?
Is the AutoCompleteAccepted Event not the right place to call it? If so, where should I call the CallTip.Show so that it works side-by-side with my AutoComplete?
Finally figured it out! The AutoCompleteAccepted Event isn't the right place to put CallTip.Show
What is going on is the fact that when AutoCompleteAccepted Event is called and you add text to the ScintillaNET control, it takes time for the UI to update and so, when you call to show the CallTip, it interferes with the text being inserted into the control.
The better way to do it is to call CallTip.Show in the TextChanged event, as they you know that the text has been inserted when the AutoCompleteAccepted Event was called.
It would now look something like this:
String calltipText = null; //start out with null calltip
...
private void Editor_TextChanged(object sender, EventArgs e)
{
if (calltipText != null)
{
CallTip.Show(calltipText); //note, you may want to assign a position
calltipText = null; //reset string
}
...
}
...
private void Editor_AutoCompleteAccepted(object sender, AutoCompleteAcceptedEventArgs e)
{
if (e.Text == "someThing")
{
/* Code to add text to control */
...
calltipText = "someKindOFText"; //assign value to calltipText
}
}
That is essentially what can be done to ensure the AutoComplete fills correctly and you get the CallTip to show.
Just note, that the CallTip MAY end up in unintended places, so it is recommended to set the value of where you want the CallTip to show up
Long time listener, first time caller here. I'm having a strange issue with the TextBox in WinRT C#/XAML that I hope someone may be able to help me with.
Basically, I'm working on creating a Custom Control that essentially requires a second TextBox to be a copy of the first, including showing the same Text, and showing the same Selected Text. Obviously for the Text requirement I simply respond to the TextChanged event on the first TextBox and set the Text of the second TextBox to the Text from the first, which works great.
For the Selected Text requirement I started with a similar solution, and my code for this is as follows:
void TextBox1_SelectionChanged(object sender, RoutedEventArgs e)
{
this.TextBox2.Select(this.TextBox1.SelectionStart, this.TextBox1.SelectionLength);
}
This seemed to work pretty well when initially used with a mouse:
But I'm having a problem when selecting text with Touch. I double-tap within the TextBox to create the first "anchor" as you do in Touch, then drag to begin the selection; but I only ever manage to select a single character normally before the selection stops. The TextBox doesn't lose focus exactly, but the behaviour is similar to that; the selection anchors disappear and I can't continue selecting anything unless I re-double-tap to start a new selection. If I remove the code to select text in TextBox2 then the Touch selection behaves perfectly in TextBox1.
I've been trying to fix this for a while and cannot, I'm not sure if I can get the desired behaviour with WinRT TextBoxes. Does anyone have any ideas? Or perhaps another way to implement a solution with two TextBoxes with this behaviour?
Thanks a lot.
So this is far from an answer, but discovered a few things that maybe will help you or others come up with a potential workaround. Apologies if these are things you've already seen and noted.
First, it's not the call to TextBox2.Select() that's the problem per se. This for instance, works fine for me
private void txt1_SelectionChanged(object sender, RoutedEventArgs e)
{
var start = TextBox1.SelectionStart;
var length = TextBox1.SelectionLength;
TextBox2.Select(3, 5);
}
unfortunately, using start and length versus the hard-coded 3 and 5, that is, the following, DOES NOT WORK:
private void txt1_SelectionChanged(object sender, RoutedEventArgs e)
{
var start = TextBox1.SelectionStart;
var length = TextBox1.SelectionLength;
TextBox2.Select(start, length);
}
I also discovered that I could select TWO characters if I started from the end, but only one from the beginning. That got me to thinking about dispatching the call to set the second selection:
private void txt1_SelectionChanged(object sender, RoutedEventArgs e)
{
var start = TextBox1.SelectionStart;
var length = TextBox1.SelectionLength;
Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPriority.Low,
() => TextBox2.Select(start, length));
}
Now I can select 2 from the front and 3 and sometimes 4 from the back. Took it a step further, and was able to select as many as six or seven with a really fast swipe.
private void txt1_SelectionChanged(object sender, RoutedEventArgs e)
{
var start = TextBox1.SelectionStart;
var length = TextBox1.SelectionLength;
Dispatcher.RunIdleAsync((v) => Highlight());
}
public void Highlight()
{
TextBox2.Select(TextBox1.SelectionStart, TextBox1.SelectionLength);
}
Seems like the trick to working around this is not setting TextBox2 until whatever vestiges of the TextBox1 SelectionChanged event have completed.
This may be worth registering on Connect.
Mine is only a partial solution as well.
I did some debugging and noticed that the SelectionChanged event is fired throughout the text selection process. In other words, a single finger "swipe" will generate multiple SelectionChanged events.
As you found out, calling TextBox.Select during a text selection gesture affects the gesture itself. Windows seems to stop the gesture after the programmatic text selection.
My workaround is to delay as long as possible calling the TextBox.Select method. This does work well, except for one edge case. Where this method fails is in the following scenario:
The user begins a select gesture, say selecting x characters. The user, without taking their finger off the screen, pauses for a second or two. The user then attempts to select more characters.
My solution does not handle the last bit in the above paragraph. The touch selection after the pause does not actually select anything because my code will have called the TextBox.Select method.
Here is the actual code. As I mentioned above, there are multiple selection changed events fired during a single selection gesture. My code uses a timer along with a counter to only do the programmatic selection when there are no longer any pending touch generated selection changed events.
int _selectCounter = 0;
const int SELECT_TIMER_LENGTH = 500;
async private void TextBox1_SelectionChanged(object sender, RoutedEventArgs e)
{
// _selectCounter is the number of selection changed events that have fired.
// If you are really paranoid, you will want to make sure that if
// _selectCounter reaches MAX_INT, that you reset it to zero.
int mySelectCount = ++_selectCounter;
// start the timer and wait for it to finish
await Task.Delay(SELECT_TIMER_LENGTH);
// If equal (mySelectCount == _selectCounter),
// this means that NO select change events have fired
// during the delay call above. We only do the
// programmatic selection when this is the case.
// Feel free to adjust SELECT_TIMER_LENGTH to suit your needs.
if (mySelectCount == _selectCounter)
{
this.TextBox2.Select(this.TextBox1.SelectionStart, this.TextBox1.SelectionLength);
}
}
I'm coding a simple text editor using Windows Forms. As in many editors, when the text changes the title bar displays an asterisk next to the title, showing that there is unsaved work. When the user saves, this goes away.
However, there is a problem. This is handled in the change event of the main text box. But this gets called too when a file is opened or the user selects "New file", so that if you open the editor and then open a file, the program says that there are unsaved changes. What is a possible solution?
I thought of having a global variable that says whether the text changed in a way that shouldn't trigger the asterisk, but there has to be a better way.
before loading data to a textbox, unassociate first the eventhandler for change
uxName.TextChanged -= uxName_TextChanged;
uxName.Text = File.ReadAllText("something.txt");
uxName.TextChanged += uxName_TextChanged;
This is a horrible solution, but every time the text change event fires, compare the value of the textbox to some variable, and if they are different store the contents on the textbox in a variable and add the asterisk. When the method is invoked via the New File dialog or any other such event that is NOT changing the text, the asterisk won't appear.
This is not a viable solution for a real text editor since the memory would quickly get out of hand on even medium-sized files. Using a finger tree or whatever data structure text editors use to compare "versions" of the text is the only real efficient solution, but the premise is the same.
http://scienceblogs.com/goodmath/2009/05/finally_finger_trees.php
Below the second picture he mentions the use of finger trees in text editors to implement an extremely cheap "undo" feature, but I'm sure you can see the validity of the tree for your problem as well.
There are no global variables in C#. You should have such an variable as an instance variable in your form (or better yet, in a model for which your form is a view), and that is perfectly fine.
This is a very simple and stupid solution. I would use a MVP design pattern for this but here the fastest and simple solution:
//Declare a flag to block the processing of your event
private bool isEventBlocked = false;
private void OnTextChanged(object sender, EventArgs e)
{
if(!isEventBlocked)
{
//do your stuff
}
}
private void OnNewFile() //OR OnOpenFile()
{
try
{
isEventBlocked = true;
CreateFile();
}
catch
{
//manage exception
}
finally
{
isEventBlocked = false;
}
}