I've searched everywhere and it seems I can't find a solution to this problem..
My problem isn't limiting the amount of characters that can be entered into an edit control, my problem is I am limited by the size of the edit control. I want to be able to type past the size of the edit control.
I've tried extending the character limit to a high number with SendMessage and sending EM_LIMITTEXT, but that only seems to work if I want to limit it even more.
Here's an image example of my problem:
I use CreateWindowEx to create the edit control, but there doesn't seem to be an extended window style OR an edit control style that achieves what I want.
The style you're looking for is ES_AUTOHSCROLL. Without this style, input cannot go past the length of the edit control. With this style, text is automatically scrolled to the right by 10 characters when the input reaches the end of the control.
You may also be interested in ES_MULTILINE, which does exactly what it says. The default (without this style) is a single-line edit control.
All of the available styles are documented here. These are just regular window styles, not extended ones.
Also, I am pretty sure that you cannot change these styles at runtime, after the control has been created. Therefore, make sure that they are specified when you call CreateWindowEx, or in your resource file if the control lives on a dialog.
Related
I'm able to set the font used to draw the drop-down part of a CMFCToolBarComboBoxButton combo box which is embedded in a CMFCToolBar toolbar. However, I'm not able to set/change the font used for the edit field control which is part of the combo box. I.e., when the combo box is collapsed the currently selected item is always drawn with the standard/default font no matter what font is used for the entries when expanding the box.
I successfully change the font of the drop down box part by using a pointer to the underlying CComboBox object retrieved via CMFCToolBarComboBoxButton::GetComboBox() (and then via CComboBox::SetFont(...)). But when using the method CMFCToolBarComboBoxButton::GetEditCtrl() to obtain a pointer to the edit control part (in order to change its font, too) this method always returns a nulltpr. Does anybody know why or more importantly: What is the correct way to set the font used for the edit control part of the box?
I've searched the web now quite a lot but cannot find a solution to the problem. Thanks for any advice!
Additional note: I need to change the used font(s) at run time in my MFC application.
OK, I finally came to the conclusion that it's better to leave these fonts up to the OS settings anyway and not explicitly set them by the application code.
This is not a technically correct answer to the (my own) question, certainly, but may be a good advide for others chasing the same problem.
I have a mfc wizard in which I implemented code for re-sizability. There's a horizontal divider line at the bottom of the wizard dialog, as shown by the red arrow in the picture, which I need to get rid of.
Since I don't know the ID of that line, I haven't included it in my resize code. Because of that, when I resize the wizard, the line keeps messing up the dialog.
It would be a great help if the ID of the divider or a method to remove it can be found.
Thanks.
On my machine (Win8.1) the ID is 3026, as shown with Spy++; have a look if it's the same on yours and/or other machines. Otherwise you could still enumerate all windows and look for the one with the STATIC window class. Then just DestroyWindow() that.
That said, I don't think the line is the issue here; the issue is that your dialog isn't redrawing itself properly. And I speculate that this is caused by it assuming a fixed size. Wizards aren't meant to be resized (see http://msdn.microsoft.com/en-us/library/windows/desktop/bb774544%28v=vs.85%29.aspx and http://msdn.microsoft.com/en-us/library/windows/desktop/bb246463%28v=vs.85%29.aspx). Even if you destroy the line, other content you will put there is going to be invalidated incorrectly as well, I think.
Maybe you can work around it by manually invalidating or playing with various clip related windows styles. However the real answer is 'don't do that'.
I've scanned through all pages in MSDN, but still not found asnwers of following.
Minimum Character Length of edit control.
Specifying range for input values in edit control.
Permitting only alphabets in edit control.
Setting tooltip for button control.
Please tell me how to do this in Win32.
This is hard to do properly. A naive approach would handle WM_KEYDOWN messages to intercept the backspace and delete keys (VK_BACK and VK_DELETE). However, you also need to handle a user selecting some of the existing text and then deleting it (via backspace or delete), cutting it, or replacing it (by typing a key or by pasting some other text). I don't think it's worthwhile, and even if you could do this well, it is likely to be confusing when you break all of those normal behaviors. (It also can be incredibly annoying. Imagine that you have some text "bar" in the control but you want to change it to "baz". If the control enforces a minimum length of 3, then attempting to backspace over the last character won't work. You would have to change it to "barz" first and before being able to delete the "r" character. Ugh.)
If your control needs a minimum length, you're better off enforcing it during a separate validation step (such as when the user clicks an OK button or moves focus to another control) and showing an appropriate error message.
I'm not sure whether you mean allowing only certain characters to be entered into an edit control or whether you want to restrict it to a range of numeric values. For the former, see 3.
If you want to restrict values to a certain numeric range, I again recommend doing it during a separate validation step instead. Otherwise you again might prevent the user from inserting and deleting characters in a normal way. If you can, avoid using using an Edit control and use a Trackbar (slider) control.
You would have to subclass the Edit control, handle WM_CHAR messages, and reject characters that you don't want. You additionally would need to handle WM_PASTE messages and perform similar validation.
This doesn't have anything to do with Edit controls and probably should be a separate question. What have you tried? Have you read http://msdn.microsoft.com/en-us/library/bb760250.aspx ?
My app uses standard single-line Edit Box controls. Is there any way to accept a multi-line "paste", discarding carriage return / linefeeds?
Notes
I don't want to use multi-line controls
My app is VS2010 C++ with WTL (not MFC or ATL)
The reason I want this is because actual input is normally quite short, but could in rare circumstances be hundreds or even thousands of characters. In which case users might well want to build the string using NotePad or whatever, then just cut & paste it in.
This is not possible as the user is pasting himself/herself. An alternative is to use a multi-line Edit Box and displaying all the data into one line by managing the pasted data into OnChange function for your control (basically disregading new lines).
I find this situation comes up from time to time, and I never seem to have a really robust generic solution to it.
I have a control - in this example an EDIT control on a dialog. I want to take certain actions in response to the user - and only the user - modifying the contents of the edit control.
The edit control can be set programmatically - e.g. when the dialog is being setup, there may be an initial value placed into the edit field. Or when the user selects an item from a listview, that selection's text may well be what's placed into the edit field.
But when the user modifies the contents of the edit field, I need to know that, and respond (in this scenario, I want to clear the selection from the corresponding listview).
I am currently looking at what control has focus, and only considering EN_CHANGE's to be "from the user" if the edit control has focus.
This works beautifully under Windows 7. This fails under XP (I haven't tested Vista yet).
In XP, if the edit field has the focus, but the user clicks on the list view, and the list view tells the edit control to set its contents, then I get a notification from the edit control which claims to still have focus (::GetFocus() == HWND of edit control). But this incorrect state doesn't occur in Win7.
This is a layered interface, so I cannot modify the list-view notification handler. It gets a selection change, and updates the edit field without my involvement or ability to really intervene other than to get notifications from both of them.
Any thoughts on how to generically, permanently solve the "Is this control notification really from the user" conundrum?
You can always track LVM_ITEMCHANGING, LVM_ITEMCHANGED, and EN_MSGFILTER messages. If the edit box is modified between LVM_ITEMCHANGING and LVM_ITEMCHANGED without an EN_MSGFILTER in between then you can probably assume the user did not modify the item. Or just check to see if there are any items selected when EN_CHANGE fires and if not or the text doesn't match the selected item, assume it is a user edit.
Or use ES_MULTILINE (from EN_CHANGE documentation):
The EN_CHANGE notification is not sent
when the ES_MULTILINE style is used
and the text is sent through
WM_SETTEXT.
I'd suggest using the right message. EN_CHANGE is too generic, you want to know if the user typed or pasted text. So why not subclass the control and watch for WM_KEYPRESS messages?
Alternatively, you can set a flag in your other code that sets the edit control content. You might be able to assume that anything that makes your wndproc re-entrant represents a programmatic change.
You aren't looking for something actually secure, are you? If you just want to exclude set content calls that's fairly straightforward. If you want to differentiate between user action and programmatic simulation of user keypresses, that's a much harder problem.