I'm working with 3d party application. Changing a text in Edit control using
SendMessageW(m_edit_handle,WM_SETTEXT,0,str_address);
And it works fine.. It changes visually in the window. But once I click a button (also programmatically) it works as there is a default value but not the one I set with SendMessageW.
Just wondering if after changing the text in Edit window I have to call some other method to force Windows to update the actual value in the field?
Depending on how the target app is coded, you may need to issue an EN_CHANGE notification to the Edit's parent window. Sending WM_SETTEXT will not send that notification, as it is meant to be sent when the user makes changes to the Edit's content, not when code does.
SendMessageW(m_edit_handle, WM_SETTEXT, 0, str_address);
SendMessageW(GetParent(m_edit_handle), WM_COMMAND, MAKEWPARAM(GetDlgCtrlID(m_edit_handle), EN_CHANGE), LPARAM(m_edit_handle));
Is there any way to programmatically scroll a single-line edit control in Windows?
For example, if the text in an edit control is too large to display at once, then the default behavior when the edit control gets the focus is to select all text and show the end of the text. I'd like to instead show the beginning of the text (while still leaving all text selected).
Although there's (apparently) no API for scrolling to the beginning and selecting all text, it seems to work to simulate the keystrokes that would do the same:
#ifndef CTRL
#define CTRL(x) (x&037)
#endif
SendMessage(edit_handle, WM_KEYDOWN, VK_HOME, 0);
SendMessage(edit_handle, WM_CHAR, CTRL('A'), 0);
You can either call SetScrollPos or send the WM_VSCROLL/WM_HSCROLL message directly to the window. You can find the full list of scroll functions here.
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.
I have a Listbox where all cells are editable.
While the user is typing text in the ActiveCell (Textfield) she may decide to paste text.
I would like to examine the paste-text and perform different paste operations depending on whether it is multiline or not.
Is there any way to create an EditPaste MenuHandler specifically for ListBox1.ActiveCell?
You should be able to use the keyboard async command and intercept the paste command in the Listbox.CellKeyDown event. Then take a look at the clipboard object to see what text it has in it.
Kind of a kludge, but I can't think of any other way to do it since the ActiveCell handles cut/copy/paste on its own without intervention.
i need to implement the functionality of EM_SETCUEBANNER, where a text hint appears inside an Edit control:
The catch is that i cannot use version 6 of the Common Controls, which is what is required to get the Microsoft supplied implementation of a cue banner.
i've looked into simply changing the text of the edit control, and the font format to
Dark Gray Italic Text
but it will throw Change events (component wrapper provided by higher component library) that i can't find a way to avoid.
So i was instead going to custom draw the text, drawing the Cue Banner text when the control is unfocused and empty, and rely on default painting otherwise.
The Edit control doesn't nicely expose a custom drawing mechanism, like ListView, TreeView and others provide.
Other people have looked into it, but it seems to be an nearly impossible task:
From the way things are looking, I'll
have to handle the following
messages:
WM_ERASEBKGND, WM_PAINT (for obvious reasons)
WM_SETFOCUS, WM_KILLFOCUS (to prevent
the white bar from displaying --
described above)
WM_CHAR (to process and update the
text in the control)
And I also need to find a way to
display the caret in the control,
since I haven't found a way to allow
Windows to do that for me without also
painting the white bar I mentioned.
This is going to be fun. :rolleyes:
Given that the Windows Edit control was never meant to be custom drawn: does anyone know how to custom draw a Windows Edit control?
Note: i will also accept answers that solve my problem, rather than answering my question. But anyone else wanting to custom draw an Edit control, coming across this question, would probably like an answer.
Custom drawing an Edit control is essentially impossible. There are a few specialized cases were you are doing so little that can get away with it, but you risk breaking badly in the next revision of windows (or when someone runs your app on an older version, or via terminal services, etc).
Just taking over WM_PAINT and WM_ERASEBKGROUND aren't good enough, because the control will sometimes paint on other messages as well.
You are better off just writing your own edit control. I know that's a huge amount of work, but in the long run it will be less work than trying to hack your way into taking over all of the Edit controls' drawing code.
I remember back in the good old days when everyone use to subclass the button control to add color and graphics, etc. The thing is, one day I sat down and just wrote my own button window class. and it was LESS CODE than what we had in our source tree to subclass and custom draw the Windows button.
Create a window class of your own that looks like and empty edit control, that draws the cue text and shows a caret and has focus. Create the edit control also, but position it behind your window. (or leave it hidden)
Then when you get the first WM_CHAR message (or WM_KEYDOWN?). You put your window behind the edit conrol, give focus to the edit, and pass the WM_CHAR message on. From then on the edit control will take over.
You can listen to EN_CHANGE notifications from the edit control if you need to go back to showing your cue text when the edit gets empty. But I'd think that it would be fine to go back to the cue text only when the edit looses focus AND is empty.
Subclassing the EDIT control worked well for me - needed to display some formatting information to the user when editing object attributes (and some attributes could be multiple lines). The important thing, like Adrian said in his answer too, is to call the EDIT control's procedure before your own drawing. Calling it afterward or issuing your own BeginPaint/EndPaint (with return 0 or DefWindowProc) caused issues for me from the text not displaying at all, to it displaying only when resizing but not after editing, to leaving screen litter of the leftover caret. With that, I haven't had any issues regardless of the EDIT control's other repaint times.
Some setup:
SetWindowSubclass(attributeValuesEdit, &AttributeValueEditProcedure, 0, reinterpret_cast<DWORD_PTR>(this));
// Not only do multiline edit controls fail to display the cue banner text,
// but they also ignore the Edit_SetCueBannerText call, meaning we can't
// just call GetCueBannerText in the subclassed function. So store it as
// a window property instead.
SetProp(attributeValuesEdit, L"CueBannerText", L"<attribute value>");
The callback:
LRESULT CALLBACK AttributeValueEditProcedure(
HWND hwnd,
UINT message,
WPARAM wParam,
LPARAM lParam,
UINT_PTR subclassId,
DWORD_PTR data
)
{
...
case WM_PRINTCLIENT:
case WM_PAINT:
{
auto textLength = GetWindowTextLength(hwnd);
if (textLength == 0 && GetFocus() != hwnd)
{
// Get the needed DC with DCX_INTERSECTUPDATE before the EDIT
// control's WM_PAINT handler calls BeginPaint/EndPaint, which
// validates the update rect and would otherwise lead to drawing
// nothing later because the region is empty. Also, grab it from
// the cache so we don't mess with the EDIT's DC.
HDC hdc = (message == WM_PRINTCLIENT)
? reinterpret_cast<HDC>(wParam)
: GetDCEx(hwnd, nullptr, DCX_INTERSECTUPDATE|DCX_CACHE|DCX_CLIPCHILDREN | DCX_CLIPSIBLINGS);
// Call the EDIT control so that the caret is properly handled,
// no caret litter left on the screen after tabbing away.
auto result = DefSubclassProc(hwnd, message, wParam, lParam);
// Get the font and margin so the cue banner text has a
// consistent appearance and placement with existing text.
HFONT font = GetWindowFont(hwnd);
RECT editRect;
Edit_GetRect(hwnd, OUT &editRect);
// Ideally we would call Edit_GetCueBannerText, but since that message
// returns nothing when ES_MULTILINE, use a window property instead.
auto* cueBannerText = reinterpret_cast<wchar_t*>(GetProp(hwnd, L"CueBannerText"));
HFONT previousFont = SelectFont(hdc, font);
SetTextColor(hdc, GetSysColor(COLOR_GRAYTEXT));
SetBkMode(hdc, TRANSPARENT);
DrawText(hdc, cueBannerText, int(wcslen(cueBannerText)), &editRect, DT_TOP|DT_LEFT|DT_NOPREFIX|DT_NOCLIP);
SelectFont(hdc, previousFont);
ReleaseDC(hwnd, hdc);
// Return the EDIT's result (could probably safely just return zero here,
// but seems safer to relay whatever value came from the edit).
return result;
}
}
break;
Writing your own EDIT control (which I've actually done more than once, to partial degrees of completeness compared to the built-in one) is not much work if you do the bare minimum (maybe English only with basic caret support), but it's a LOT of work to get correct if you want caret navigation over complex scripts with variable sized clusters, selection over ranges, IME support, context menus with copy and paste, high contrast modes, and accessibility features such as text to speech. So unlike so many other answers, I recommend not implementing your own EDIT control merely for cue banner text.
Subclass the edit control. Handle WM_PAINT by first calling the original window procedure and then, if it's empty and not in focus, draw the cue text. Pass every other message to the original window procedure.
I've done this--it works. The problem the CodeGuru person had doesn't seem to apply to your situation. I believe he's trying to do more to the appearance. For performance, it looks like the edit control is doing some updates outside of WM_PAINT processing (probably for performance). That's going to make it nearly impossible to take complete control of the appearance. But you CAN draw the cue prompt.
And I also need to find a way to display the caret in the control,
since I haven't found a way to allow Windows to do that for me without
also painting the white bar I mentioned.
If you want to handle WM_PAINT by yourself without forwarding the message to the original windowproc of your superclass, you should not forget to call DefWindowProc. So that the caret will be drawn.
To avoid the white bar you should remove class brush with SetClassLongPtr.
And somehow keep your DC's clipping region to clip Edit controt's ExtTextOut outputs.
The white bar may be the result of OPAQUE option passed to ExtTextOut by Edit control.
Conclusion: Write your own control. No pain, no gain.