I am writing in C WinAPI a 'Go To Line' dialog of the notepad. I created a number only edit control. But I can still paste words into the edit control! The dialog in the windows notepad does stop this kind of pasting. So how can I do the same thing as it in the notepad?
Subclass the edit control, and when WM_PASTE is received:
OpenClipboard
GetClipboardData
GlobalLock
Now use the returned pointer from GlobalLock to check for non numeric characters. If a non number is found, inform user then:
GlobalUnlock
CloseClipboard
and return 0 from the callback to prevent pasting the data into the edit control.
If it is all numbers, then GlobalUnlock and CLoseClipboard and pass message on with CallWindowProc to allow paste.
The documentation for ES_NUMBER (which is what I presume you're using) says:
Allows only digits to be entered into the edit control. Note that, even with this set, it is still possible to paste non-digits into the edit control.
To prevent pasting non-digits, you'll need to scan through the data in the clipboard and prevent pasting if it contains a non-digit.
Related
I am using C# WPF with Avalon Edit Text Box.
I am trying to make all of the text in the text box uppercase and I get an error with additional message 'No undo group should be open at this point'.
I am using the following code:
a.Text = a.Text.ToUpper();
where "a" is the AvalonEdit.TextEditor
Thank you.
Setting the TextEditor.Text property has the side-effect of clearing the undo stack (just as with the normal WPF TextBox). Clearing the undo stack is only allowed when there's no open undo group.
If you did not intend to clear the undo stack, use the methods on textEditor.Document instead to modify the document. You'll want to avoid replacing the whole text, because that would also reset the selection and caret position (after all, AvalonEdit can't know how your new text is related to the old text).
If you do want to clear the undo stack (e.g. you're switching the view to a different document), you'll have to figure out why an undo group is open. Most likely, your code is running from the event handler of an event that is called while the undo group is still open (e.g. document.TextChanged) -- you might want to switch to a different event instead (e.g. document.UpdateFinished is called after the undo group was closed).
If all you want to do is to upper-case text as it is being input, it's better to modify the text before it is added to the document: handle the TextArea.TextEntering event to cancel any lower-case input (set e.Handled = true;), and instead call TextArea.PerformTextInput() to repeat the text input process with the corresponding upper-case text instead.
For copy-paste, you could handle the attached DataObject.PastingEvent and modify the data to be pasted.
I wonder how can I get selected text. (usually done by mouse dragging or shift + arrow on text)
From notepad, word, Internet explorer addressbar, etc.
sending WM_GETTEXT just copy caption, and unable to copy selected text while I rename file name on file explorer.
So, I am considering simulating Ctrl+C. but simulating key strokes seems not a good idea. because it will make side effects.(in case Ctrl+C assigned to other functionality)
I tried following code, wishing copy currently selected text into clipboard
OpenClipboard(0);
EmptyClipboard();
SetClipboardData(CF_TEXT,0);
CloseClipboard();
but no luck, it just emptyclipboard.
how can I copy currently selected text?
(simulating Ctrl+c with no unpredictable effect)
thanks!
(my environments are Windows 7, C programming language, winapi)
I'm not sure if there is a general answer because the various applications you mentioned use different window classes.
For Notepad in particular: The display area seems to be a simple EDIT control. You can use the EM_GETSEL message to retrieve the begin and end of selected text, then use WM_GETTEXT to get the complete text. Do not use GetWindowText because it does not work with windows of another process.
In general, you can try using the WM_COPY message. This should place the text in the clipboard. However, the result depends on how that message handler is implemented in the other application.
You are setting the clipboard using SetClipboardData(CF_TEXT, 0) -- MSDN Doc says that if the second parameter is NULL, the window must process the WM_RENDERFORMAT and WM_RENDERALLFORMATS messages; the same article has a comment on how to allocate Global memory, fill it with the required text and pass it on to SetClipboardData().
Our software uses the DataGrid throughout its user interface for displaying editable lists. While editing some metadata, I wanted to remove the text in a particular column for many rows. This is pretty quick if you get into the rhythm of F2-Backspace-Enter, F2-Backspace-Enter, F2-Backspace-Enter….
Things don’t go quite so well if you miss the F2 part of the pattern and just press Backspace-Enter on a cell. The WPF DataGrid will actually replace the contents of the cell with the backspace character. Depending on how you look at your string, this might show up as 0×08, , \u0008, or \b.
What on earth?
This CodePlex post confirms a bug in the DataGrid and includes some workarounds. On our end, the current fix is simply to ignore strings that have a backspace character in them. This way they don’t end up in the XML, which is good because in XML 1.0 the backspace is an illegal character.
See also this Microsoft Connect issue.
I'm making my own commentbox control that inherits from a winforms textbox. One of the things it does is prevent users from entering any characters if the limit has been hit. So on the keypress event I just grab the incoming key (excepting delete and backspace) and add it on to what's in the textbox already, then check and see what the length is. If it is over, then I just set the e.Handled = true and the keypress is halted. This scheme fails me though on an incoming ctrl-v paste event. It registers as a single keychar coming in. So the paste won't come through if I'm right at the limit, but it will go over if there is one character of room left and the paste has two or more characters for instance.
I just need a way to detect that this paste is coming in, and when its coming in I need to know what the length of the string is so I can either stop it from happening or paste as much of it as possible in there.
Thanks!
This is such an idle question. You can just set the MaxLength property of the textbox and it prevents all of this. Duh.
I am looking for an embeddable interactive console. I want the user to be able to type in some custom commands, and the application to write command responses in it. Would be awesome if it would understand powershell or python, ans supports command completion.
I already built my own bash-like terminal, but I do not want to totally reinvent the wheel, so I'm looking for a third-party stable component before going any further with it.
If someone is interested, I found PoshConsole, a powershell console:
http://poshconsole.codeplex.com/
Thanks
PS: you can find a screen of what I am trying to achieve here:
http://www.hiboox.fr/go/images-100/codein,0a2809b63e05c3d0cac678962e0e3d5a.jpg.html
Nothing found since I asked the question, and to stick with the "do it yourself" way of thinking:
I wrote a terminal-like control in .NET.
http://wpfterminal.codeplex.com/
You can see an example in this screenshot (terminal is integrated in a bigger project) :
http://images4.hiboox.com/images/4210/0a2809b63e05c3d0cac678962e0e3d5a.jpg
Basic mechanisms
Actually what I did was to define a lastPromptIndex integer, and everytime a user presses the ENTER key and a new prompt appears, this value is updated.
After that, it's simple, you just need to process any text input before the textbox validates the input. If the textbox caret was located before your lastPromptIndex, you need to raise an error (usually a beep sound) and you must invalidate the text input, so nothing is written in the textbox. I also automatically set the caret position to the end of the textbox, so the user can immediatly input some text.
Extensions
You can enable command completion by looking for an "UP key" input if the caret is before the prompt index, etc. What you need is just to process input events before they are sent to the textbox internal mechanisms. I don't know if SWT controls allow it, but I'm pretty sure they do, like any serious UI system.