Is there any way to get notified BEFORE the text in a Windows::UI::Xaml::Controls::TextBox changes (TextChanged and TextChangedEventHandler work great to get notified AFTER the text changes)?
The functionality I am seeking would be loosely equivalent to iOS's shouldChangeCharactersInRange.
You could store the previous Text value from the last TextChanged event in a field and if you are not happy with the new value on TextChanged - revert to the old value. Alternatively - you could indicate an error without actually preventing a value change.
Related
I'm trying to find out why my UITableView changes the width (bigger than phone-screen). Therefore I tried to use KVO, but observeValueForKeyPath:ofObject:change:context: isn't delivering me the information about the place where the property got changed.
I also tried to set a breakpoint and follow the call stack, to see the place of change - without success - maybe it's happening in another thread.
Does anybody know how to watch a property and get the location of change?
When using an external keyboard, my UITextView fires a shouldChangeTextInRange message just fine when I press the Backspace key ("backward delete"), but if I press Delete ("forward delete") then the method is never called at all, despite the view's text changing as expected. In case it matters, I'm using Swift and the latest iOS simulator.
If this is expected behavior, can someone point me to the documentation that explains it?
More importantly, is there a workaround?
Edit: submitted rdar://18909378. I've also discovered the same behavior when using cmd+backspace and opt+backspace. Very annoying!
I'm still seeing this issue on iOS 10. The best workaround I've come up with is to listen to the field's UIControlEventEditingChanged event and grab textField.text from there. This gives you the updated contents, but doesn't allow you to prevent the delete action like shouldChangeCharactersInRange does.
I'm porting a Mac app to the iPhone and I've run into an unexpected problem.
On the Mac there's a text field that is automatically pre-selected (= first responder) when a dialog shows up. The text field shows the text you entered in the field the last time and the text is pre-selected so that if you just start typing it gets cleared away. If you want to edit the existing text instead you just hit the forwards or backwards arrow.
On the iPhone this behavior seems very hard to implement. The text view shows up with the old text and I can even get it to pre-select but whatever I do the result is not quite right.
When I use
[aTextView setMarkedText: myText
selectedRange: newRange];
the text does show up as marked and if I just start typing the old text goes away. However there's no equivalent to the cursor keys on iOS, so I cannot NOT erase the text.. which is hardly the point.
What kind of iOS idiom would be appropriate for giving the option to either edit or overwrite existing text?
Best regards,
Frank
Try this code in your UITextViewDelegate
- (BOOL)textViewShouldBeginEditing:(UITextView *)textView
{
dispatch_async(dispatch_get_main_queue(), ^{
[textView selectAll:self];
});
return YES;
}
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
OpenEdge ABL automatically close a yes/no message after a certon amount of time has pasted
I have a yes/no message box that I want to clear after 14 seconds have past. I believe the first step to do this is to get the message box's handle so that I can make it disappear
I'm afraid the simple answer is "You can't".
This is not a limitation of Progress, it is inherent in Windows message boxes no matter what programming language you use. The message box is modal to the parent application, meaning that your application freezes until the message box is closed. No matter what coding you write to close the message box, it will not run while the message box is open.
The not so simple answer offers two possibilities: To have part of your application NOT freeze when modal forms are displayed displayed requires multi-threading, which we don't talk about in polite company. The other option is to display the message box as non-modal, i.e. it does not freeze your app. To achieve this, you cannot use MESSAGE VIEW-AS ALERT-BOX, because that will ALWAYS be modal. You will have to create your own message box - a window or frame that you can display and hide as you need.
I prefer using a Frame rather than a Window. Disable the default frame, show the Message frame which contains Yes/No buttons. Your app is not frozen, but the user can only interact with the message frame. When the user clicks a button or the time is up, hide the message frame and enable the default frame again.
FRAME Message-Frame:VISIBLE = TRUE.
FRAME default-frame:SENSITIVE = FALSE.
/* do your thing */
FRAME Message-Frame:VISIBLE = FALSE.
FRAME default-frame:SENSITIVE = TRUE.
Remember to set the TOP-ONLY attribute of the message frame to TRUE, or it won't appear above the default frame.
One can use a widget's handle, or manage it directly, like so:
DEF VAR ch-field AS CHARACTER.
DEF FRAME f-test
ch-field.
ch-field:Visible = yes.
pause 14 no-message.
ch-field:visible = no.
OR - get the widget's handle, and then set it's "Visible" attribute as needed.
Playing around with my web application in the iOS 5 simulator, I noticed that iOS 5 doesn't clear placeholders immediately, only after the first input. On all other version of iOS as well as on all desktop browsers, the placeholder is immediately cleared when the user focuses on the input. I don't have access to an iOS 5 device right now but I highly doubt this is a simulator error.
Is this a bug or intended? Oddly I only found one reference to this behavior on the net, right here on SO: clearing input placeholder in iOS5
Is there a workaround for this problem? It's quite frustrating for the user when the placeholder doesn't clear immediately.
I think you are mistaken - iOS text fields always behave this way.
I don't see why this would be frustrating for the user. If anything it is helpful that the helper text stays visible until they begin typing, in case they missed it before selecting the field.
What may be confusing you is that iOS fields have a separate optional behaviour where the text is cleared when the field is selected, but note that this is the actual text that clears, not the placeholder text.
Placeholder text is the light grey text, and this always appears until the user types something.
Content text (usually black) sometimes clears when the field is focussed and sometimes doesn't, depending on how the UITextField was configured.
The jQuery solution in the SO question you linked to should let you replicate any variant of this functionality that you desire, but personally I'd advise sticking with the iOS convention of not clearing helper text until the user types something.
It is not a bug, it is a feature. You can use delegate methods to clear placeholder. (UITextFieldDelegate http://developer.apple.com/library/ios/#documentation/uikit/reference/UITextFieldDelegate_Protocol/UITextFieldDelegate/UITextFieldDelegate.html)
- (void)textFieldDidBeginEditing:(UITextField *)textField
{
[textField setPlaceholder:#""];
}
adn you should control its emptiness after finish editing.
- (void)textFieldDidEndEditing:(UITextField *)textField
{
if ([textField.text isEqualToString:#""])
[textField setPlaceholder:#"Placeholder Text"];
}