If an edit control is disabled, the caret disappears. that case, if the edit is displaying a long text, then it is not possible to see the rest of the words.With the caret i, we can do that.
I think you must use an enabled readonly edit control instead of a disabled one.
Check 'readonly' in the edit box property window or use ES_READONLY when calling Create.
Also, don't forget to check Auto HScroll (ES_AUTOHSCROLL) ( and AutoVScroll if multiline).
CEdit* pEdit = new CEdit;
pEdit->Create(ES_MULTILINE | WS_CHILD | WS_VISIBLE | WS_TABSTOP | WS_BORDER
| ES_AUTOHSCROLL | ES_READONLY, (10, 10, 100, 100), this, 1);
Related
I'm dynamically (in runtime) creating a CRichEditCtrl control and when I set the text to it, the font is different from the other controls (e.g. CStatic - see the pictures) in the dialog (I didn't use any formatting for the rich edit control). The difference is best seen with the characters from alphabets like Chinese or Japanese. I tried using SetDefaultCharFormat method but it was not having the effect I wanted. Then I found out, that I first need to set the text to the rich edit control, and only then use the formatting function.
// 1. dynamically created rich edit ctrl
CRichEditCtrl* dynamic_rich = new CRichEditCtrl();
dynamic_rich->Create(WS_CHILD | WS_TABSTOP | ES_LEFT | ES_MULTILINE | WS_VSCROLL |
WS_HSCROLL | ES_WANTRETURN | WS_VISIBLE | WS_BORDER | ES_AUTOHSCROLL | ES_AUTOVSCROLL,
CRect(10, 0, 184, 23), this, 1234);
dynamic_rich->ModifyStyleEx(WS_EX_CLIENTEDGE, 0, SWP_DRAWFRAME);
dynamic_rich->SetWindowTextW(L"アラビア語"); // calling it here results in the 3rd picture
// which is the closest to the desired result, though it's still not the same as in CStatic
CHARFORMAT cf = { 0 };
dynamic_rich->GetDefaultCharFormat(cf);
_tcscpy_s(cf.szFaceName, L"MS Shell Dlg 2");
cf.dwMask = CFM_FACE;
dynamic_rich->SetDefaultCharFormat(cf);
// 2. statically created rich edit ctrl - defined in .rc file
CRichEditCtrl* static_rich = (CRichEditCtrl*)this->GetDlgItem(IDC_RICHEDIT);
static_rich->SetWindowTextW(L"アラビア語");
// 3. statically created cstatic - for the font comparison
CStatic* label = (CStatic*)this->GetDlgItem(IDC_STATIC);
label->SetWindowTextW(L"アラビア語");
When I leave the default font (without calling SetDefaultCharFormat) - seems blurry
When I call SetDefaultCharFormat, then set the text - the same result
When I set the text, then call SetDefaultCharFormat - not quite the same, but close
The font in the rich edit control still doesn't look the same as in CStatic (seems a bit different and also bigger), but that I can live with. Calling SetDefaultCharFormat every time I change a text is a problem though because I need to be constantly changing the text in the runtime and it could potentially cause an overhead. Does anybody have a better solution? Thanks.
I've been scratching my head over this for a week now. I'm using the Windows API and I made a textbox with
editBox = CreateWindowEx(WS_EX_PALETTEWINDOW, TEXT("Edit"), NULL, WS_CHILD | WS_VISIBLE | WS_VSCROLL | WS_BORDER | ES_MULTILINE | ES_LEFT | ES_AUTOVSCROLL, 175, 110, 140, 150, hwnd, (HMENU) ID_TEXT, NULL, NULL);
and a button
button = CreateWindowEx(WS_EX_PALETTEWINDOW, "BUTTON", "Ok", WS_TABSTOP | WS_VISIBLE | WS_CHILD | BS_DEFPUSHBUTTON, 175, 260, 140, 20, hwnd, (HMENU) ID_BUTTON, NULL, NULL);
and I want to be able to click the button and it store what was typed into editBox in a primitive string. Examples are preffered but links and documentation are also very much appreciated! :)
You can use the GetWindowText API function to get the text of an edit control.
For a window with title this function retrieves the title. For an edit control it retrieves the edit control's text. Just ignore any documentation saying that you're limited to 64K or so, if you encounter it (it was once that way).
To detect the button click, process the WM_COMMAND window message in your window procedure; it's sent to the parent window of the button. There is a more sophisticated approach based on reflecting the message back to button, which can then process it itself, and that approach is used in most higher level frameworks. But at the API level, just check WM_COMMAND in the parent window's window procedure.
I get really strange behavior when I use more than one RichEdit control:
LoadLibrary("Msftedit.dll");
RichEdit = CreateWindow("RICHEDIT50W", "", ES_READONLY | ES_MULTILINE | WS_HSCROLL | WS_VSCROLL | WS_VISIBLE | WS_CHILD | WS_BORDER | WS_TABSTOP, 5, 370, 600, 300, hwnd, NULL, NULL, NULL);
RichEdit2 = CreateWindow("RICHEDIT50W", "", /*0x550081C4*/ 0x50810804, 610, 65, 600, 300, hwnd, NULL, NULL, NULL);
The first EditControl works as it should, however the second one has some strange border around it.
First I tried to use the same styles as for the first richedit, then I found out the style using Spy++.
Even if I have the same styles, I get different results, probably the same as if I used WS_EX_CLIENTEDGE extended style for the second richedit.
I even tried to free the library and load it again, but with the same result.
Thank You all in advance!
So I figured it out. I have no Idea why, but the second RichEdit is somehow getting the WS_EX_CLIENTEDGE style after is created, so I simply remove the style like so:
LONG lExStyle = GetWindowLong(RichEdit2, GWL_EXSTYLE);
lExStyle &= ~WS_EX_CLIENTEDGE;
SetWindowLong(RichEdit2, GWL_EXSTYLE, lExStyle);
Now the RichEdit looks the same as the first one. But I have really no idea, where the style comes from.
I used the following code and it worked fine, allowed the user to only enter in numbers. I wanted to increase the functionality by using RichEdit so I added that.
I went from using:
wchar_t sampletext[] = L"foobar";
HWND inputText = CreateWindowEx(WS_EX_CLIENTEDGE, L"EDIT", sampletext,
ES_NUMBER | WS_CHILD | WS_VISIBLE | WS_TABSTOP | ES_MULTILINE,
10, 10, 500, 75, hWnd, NULL, *hInst, NULL);
to:
LoadLibrary(L"riched32.dll");
wchar_t sampletext[] = L"foobar";
HWND inputText = CreateWindowEx(WS_EX_CLIENTEDGE, L"RichEdit", sampletext,
ES_NUMBER | WS_CHILD | WS_VISIBLE | WS_TABSTOP | ES_MULTILINE,
10, 10, 500, 75, hWnd, NULL, *hInst, NULL);
Changing it allowed me to use CTRL+Z and CTRL+A and all but now for some reason I could enter characters that weren't numbers.
How do I fix this so Rich Edit only accepts number in this text field?
or
Alternatively, how would I create my own custom filter that would only accept numbers into the text field?
EDIT:
Here's an image of me typing
The "RichEdit" control class has its own set of styles.
But ES_NUMBER is one of them, according to MSDN. However, note the comment by ElmueSoft.
To filter input to only digits without help from the control, you can subclass it. You'd need to handle quite a few messages though. WM_CHAR is the most obvious, but WM_PASTE and WM_SETTEXT can have non-numeric text passed in.
Good information on subclassing:
http://blogs.msdn.com/b/oldnewthing/archive/2009/05/07/9592397.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2003/11/11/55653.aspx
Below is part of a working normal win32 application created from scratch, not dialog based. it will show the text on the buttom, not top:
hButtonApply = CreateWindow(
"BUTTON",
"Reset",
WS_CHILD | WS_VISIBLE | BS_PUSHBUTTON | BS_BOTTOM,
95, 130, 120, 40,
hWnd, (HMENU)IDC_BUTTON_RESET, hInstance, NULL);
SendMessage(hButtonApply, BM_SETSTYLE, BS_TOP, TRUE);
this however makes it a radio button:
SendMessage(hButtonApply, BM_SETSTYLE, BS_RADIOBUTTON, TRUE);
same for a resource-defined dialog button control.
Subclassing is acceptable. Owner-Drawn Buttons are not acceptable. Thanks, Haotian Yang
Some window styles can only be set during CreateWindow, I guess this might be one of them.
Did you try SetWindowLong ?
Edit:
This seems to work:
LONG style = GetWindowLong(hBtn,GWL_STYLE);
style = (style & ~BS_BOTTOM) | BS_TOP;
SetWindowLong(hBtn,GWL_STYLE,style);