I am trying to debug a tricky situation with auto-correction not getting correctly handled in a TextBox, but I am stuck:
I cannot find how the tapping of an auto-correction suggestion in the SIP gets communicated to the TextBox.
I have traced the KeyUp, KeyDown, TextInput, TextInputStart and TextInputUpdate events, but they do not seem to be involved in the update of the Text in the TextBox object.
Background:
When a language other than Greek is used, auto-correction works as it should for a TextBox in my app. However, when the language is set to Greek, nothing happens when tapping on the suggested word ... On the other hand, in TextBoxes in standard phone apps (e.g. adding text in the Notes section of a contact) Greek auto-correction works perfectly. So, my first guess is that there is something wrong with the TextBox rather than with the SIP. My plan is to subclass TextBox, modifying only its auto-correction handling parts.
Any help would be much appreciated,
Gerasimos
Update:
I made a few tests and this seems to be a problem in all non standard apps. Specifically, I tested the eBay and SkyMap applications and in both cases English auto-corrections work, while Greek do not.
The problem is easy to reproduce:
put a textbox in an application (with an inputScope that has auto-corrections enabled)
use a Greek keyboard layout
tap 1-2 random letters.
tap on one of the proposed auto-corrections. Only the final space is introduced, and in cases that the cursor is between two spaces (as I preferred to test it) nothing happens.
So, I believe that there is a bug somewhere in the framework part and not in the application code. Now, if we could find how this auto-correction tapping is communicated to the TextBox... :-)
You should not be able to interrupt the SIP directly, You can edit the content of the textbox after the value has been entered/changed. Alternatively, you can implement something like an autosuggest if your intentions are to change the content instead of the visuals.
Related
While developing a Chrome translation detection I came across a weird Chrome behaviour:
When a page is translated by google, quite often it is not possible to type text into input fields on the translated page. With normal text fields, text may be shown in reverse order. With password fields, no typed chars are shown (so the * representing a char). When I switch back to the original language, all of a sudden the text is shown, so Chrome seems to save it somewhere but just does not display it.
Sometimes the language is not detected correct, so I use the "This page is not in ..." functionality of Chrome to set it to the correct value. This seemed to be the reason for this strange behaviour in the first place. But after quite a few tests, it may not be the problem. In both cases (with setting the correct language or not) it works sometimes, but ore often it does not. I could not find a pattern so far.
This happens on other computers of other people as well, so it does not seem to be a problem with my computer.
It is a page developed with Vaadin and Spring and the page this came up was the login page. I use the LoginForm functionality of Vaadin, so maybe that's a possible reason for this behaviours. I tested the translation on other pages with input fields as well, and there it seems to work. But I'm not sure if this isn't just Murphys law.
Anyone any idea about this?
How do you prevent the user from changing anything other than the text in a Win32 Rich Edit control?
(i.e. They shouldn't be able to change the formatting of any text, add graphics, etc.; if they copy-paste new text, only the text should be kept, and associated formatting should be discarded.)
I've never found a particularly elegant way to handle this: what I've done in the past is:
1) Catch WM_KEYDOWN messages for the control and discard all formatting keys (Ctrl+E,J,R,L,1,2,5,+, and Ctrl+Shift+A,7)
2) Catch all paste operations by catching WM_COMMAND messages with an id of ID_EDIT_PASTE, and replace the paste message with a message EM_PASTESPECIAL,CF_UNICODETEXT to the control. (This is with MFC: Depending on what framework or language you're using, this may require catching Ctrl+V and similar rather than ID_EDIT_PASTE.)
Not pretty, I conceed, but it seems to work.
This answer is probably a bit late but for anybody else looking for an answer to this questions, the best way that I've found have total control of paste operations in a Rich edit control is to provide an implementation of IRichEditOleCallback::QueryAcceptData and then return S_FALSE to stop them all together or to filter out certain clip board formats by changing the lpcfFormat parameter.
The CRichEditView::QueryAcceptData function in MFC provides an excellent example of how this can be done. This will work for all kinds of paste operations including drag and drop so is the best way to get full control of what happens.
Even later :)
SendMessage(wndEdit, EM_SETEDITSTYLE, SES_EMULATESYSEDIT, SES_EMULATESYSEDIT)
seems to do the trick: paste pastes plain text, and the formatting hot keys are disabled.
SES_EMULATESYSEDIT: When this bit is on, rich edit attempts to emulate the system edit control (default: 0).
You still retain some of the "bonus" features of the richedit, such as scrollbars on demand.
Note: While this will prevent the pasting of richly formatted text into the RichEdit control, it will also prevent you from programatically formatting the text; all rich formatting is disabled.
A mere Windows textbox greatly surprised me today.
I have two unrelated text boxes inside an application. I can type in either text box and switch the focus by clicking on them. Then happens some event X, which I can't describe here for reasons given below. After this event happens, the two text boxes become "entangled" in an almost quantum way.
Say, text box A was focused before X happened. When I click text box B to type in some text, the new text appears in text box A, whereas the blinking cursor happily moves along in text box B through the void, as if the text were there.
No amount of clicking on either text boxes can resolve this. The cursor will always remain in B, whereas the text will always go to A.
Message spying reveals that after the event X, the text boxes lose the ability to lose or gain focus. When I click on B, WM_LOSE_FOCUS does not come to A, and WM_SET_FOCUS does not come to B. (The rectangles and visibility of the boxes are OK.)
The same thing happens in Windows XP and Windows 7.
Now, event X: it's a big event in a third-party UI library which I cannot reverse-engineer in a timely manner. (Namely, docking a pane in wxAUI.)
I am sure that this behavior is the result of incorrect WinAPI calls to the text boxes (garbage in - garbage out). I would like to know what could possibly cause such "textbox trip" to know where to start looking for the bug.
Thanks!
I found the problem. It was me. There was a silly bug in focus management. It caused the focus to be rapidly (immediately) transferred to text box B and then back to text box A immediately after "event X". And though it only happened once, it was enough to wreak havoc in the textboxes till the end of their lives.
Why the special effects? It turns out that Windows hates two rapid consecutive manipulations with UI elements. I once had a similarly weird bug when I tried to move a control by setting its origin and its size in two different steps. The control would behave very randomly after this. Only when I moved it properly - in one step - the weirdness stopped.
Thanks for your attention and sorry for bothering.
That's a pretty strange one, and without being able to look at some code the best I can do is an educated guess.
It sounds to me like the UI library is handling notifications (key down, focus, etc.) for text box B and acting on them as though they were meant for text box A. Like there's a variable like activeTextBox that holds the handle of text box A, even when it should be pointing to text box B.
Whereas I can imagine a UI library bug causing this kind of behavior, I would think it's much more likely that client code would cause it. Have you ruled out your code as the culprit?
Do the text boxes have unique identifiers?
did you tie their messages and message handlers up correctly?
In particular, it sounds like the control that has event X might have sub-control identifiers which clash with your control identifiers.
if the problem is reproducible, then I would make a small test example and send it to the control's vendor.
I have a bit of a challenge.
In an earlier version of our product, we had an error message window (last resort, unhandled exception) that showed the exception message, type, stack trace + various bits and pieces of information.
This window was printscreen-friendly, in that if the user simply did a printscreen-capture, and emailed us the screenshot, we had almost everything we needed to start diagnosing the problem.
However, the form was deemed too technical and "scary" for normal users, so it was toned down to a more friendly one, still showing the error message, but not the stack trace and some of the more gory details that I'd still like to get. In addition, the form was added the capabilities of emailing us a text file containing everything we had before + lots of other technical details as well, basically everything we need.
However, users still use PrintScreen to capture the contents of the form and email that back to us, which means I now have a less than optimal amount of information to go on.
So I was wondering. Would it be possible for me to pre-render a bitmap the same size as my form, with everything I need on it, detect that PrintScreen was hit and quickly swap out the form contents with my bitmap before capture, and then back again afterwards?
And before you say "just educate the users", yes, that's not going to work. These are not out users, they're users at our customers place, so we really cannot tell them to wisen up all that much.
Or, barring this, is there a way for me to detect PrintScreen, tell Windows to ignore it, and instead react to it, by dumping the aformentioned prerendered bitmap onto the clipboard ready for placing into an email?
The code is C# 3.0 in .NET 3.5, if it matters, but pointers for something to look at/for is good enough.
Our error-reporting window has these capabilities:
Show a screenshot that was taken when the error occured (contains all the open windows of the program at the time, before the error dialog was shown)
Show a text file containing every gory detail we can think of (but no sensitive stuff)
Save the above two files to disk, for latter attaching to an email or whatnot by the user
Sending the above two files to us by email, either by opening a new support case, or entering an existing support case number to add more information to it
Ignore the problem and hope it goes away (return to app)
Exit the application (last resort)
We still get screenshots from some users. Not all, mind you, so my question is basically how I can make the PrintScreen button help us a bit more for those users that still use it.
One option: Put the stack trace and other scary stuff into the error screen using small, low-contrast type -- e.g. dark gray on light gray -- so that the user doesn't really even see it, but the Print Screen captures it.
But if you want to detect the PrintScreen and do your own thing, this looks like an example of what you want.
Wouldn't it be possible to disable the Print Screen button altogether when the error popup is active? Have it display a message along the lines of "Please use the clearly visible button in the middle of your screen to report the error" I agree it breaks expected functionality, but if your users are really that stupid, what can you do...
Alternatively, have it report errors automatically (or store the data locally, to be fetched later, if you can't send without asking for some reason), without asking the user. If you want to be able to connect print screened screenshots with detailed error data, have it send a unique ID with the data that's also displayed in the corner of the popup.
What about offering them a "Print Screen" button that performs these actions as well as performing the print screen? If you're locked into this method of having your customers send error details, this may be an easier route to take.
Lifted from my comment below for easier reference (looks helpful, perhaps):
codeproject.com/KB/cs/PrintScreen.aspx
This is in theory...the best way to deal with it I would think
Intercept a WM_PRINT message or inject one into your process... see this article here
Install a system-wide keyboard hook and intercept the print-screen key and swap it around with your contents prior to the capture. Now, I can point you to several places for this, here on CodeProject, and here also, keyboard spy, and finally, global Mouse and keyboard hook on CodeProject.
Now, once you intercept the print screen, invoke the WM_PRINT message by capturing the contents that you want to capture.
I know this is brief and short, but I hope this should get you going.
The only solution i came up with was to offer big, large, easy to read toolbar buttons that give the user every opportunity to save the contents of the error dialog:
Save
Copy to clipboard
Send using e-mail
Print
And after all that, i use the Windows function SetWindowDisplayAffinity in order to show the user a black box where the form should be:
This function and GetWindowDisplayAffinity are designed to support the window content protection feature that is new to Windows 7. This feature enables applications to protect their own onscreen window content from being captured or copied through a specific set of public operating system features and APIs. However, it works only when the Desktop Window Manager(DWM) is composing the desktop.
It is important to note that unlike a security feature or an implementation of Digital Rights Management (DRM), there is no guarantee that using SetWindowDisplayAffinity and GetWindowDisplayAffinity, and other necessary functions such as DwmIsCompositionEnabled, will strictly protect windowed content, for example where someone takes a photograph of the screen.
If their screenshots show a big black box, hopefully they'll get the hint.
I did add a defeat, if they hold down shift while clicking "show error details", i don't add the protection during form construction:
//Code released into public domain. No attribution required.
if (!IsShiftKeyPressed())
SetWindowDisplayAffinity(this.Handle, WDA_MONITOR); //Please don't screenshot the form, please e-mail me the contents!
Answers.com has a taskbar application that when you ALT + mouse-click on a word in any program it will pop up a window with information pulled from their website.
My question is-- what are the actual programming mechanics and APIs used to do something like this? I don't have Windows application programming experience and am trying to figure out where to start. How do you access the current word pointed to by the mouse?
Anyone aware of any examples or open source software that does anything like this?
It's been a while and the last time I did something like this it was within my own wysiwyg editor so I had full access to all font characteristics needed to calculate which word was clicked by the mouse.
Maybe there's a n easy way to do this if all your apps are .NET or com or share some other framework which provides a way to retrieve this directly.
Via the API, I would look into hooking the keyboard and mouse messages so that your app can pre-process every mouse click on other applications - start with SetWindowsHookEx and read everything you can about hooking messages.
After getting your app to pre-process the messages, you then need to grab the text being clicked. Since text can be painted onto a device context in many different ways, you may be best off doing a screen scrape of the clicked area because the text may only exist as a bitmap. If this is the case, you have to perform some OCR to translate the scraped bitmap back into text. In other cases, the text may reside in the window as text - the WM_GETTEXT message may return this text from some types of windows (e.g. textboxes, buttons, etc.) but for normal windows, this message only return the title in the caption bar.
Sorry I don't have any definite answer, but this may get you started in the right direction.