I've come up against a gnarly problem in developing my (yet another) ASM editor (in other thread here). It has to do with memory management.
Specifically, how to handle getting selected text. I wanted to try out copying a selection the user had made in the edit window into one of my "cubbyholes". Seems simple enough, right? Well, not so much.
Since there's no such edit control message as
EM_GET_SELECTED_TEXT, what a guy would have to do is this:
- First see if there's any selection at all using EM_GETSEL
- If there's a selection, get the entire edit control's text into a buffer, say with GetWindowText()
- Use the selection positions to extract the selected text
So what if we have tens of K of text? or hundreds of K? This means we have to have a buffer allocated that's big enough for that text. (Windows is helpful here by giving us the
WM_GETTEXTLENGTH message and the
GetWindowTextLength() function to tell us how much text (in characters) is in the control.)
Here's where we have to make some design decisions. The easy way to do this would be to allocate a buffer (I'd use
HeapAlloc(), as that's what I'm familiar with) every time we want to do this operation, then de-allocate it. Easy, but wouldn't this be expensive? as well as potentially causing memory problems with all that allocating and deallocating?
Or we could initially allocate a buffer that we
think might be big enough for most cases, then compare its size to the amount of text in the control. If it's not big enough, then enlarge it using
HeapReAlloc(). My bet would be on this method, which forces us to do some bookkeeping, i.e. memory management. (Ugh.)
Of course this problem isn't limited to us assembly-language programmers: even in a very high-level language like C++, the programmer's going to be faced with some tough decisions in the memory department.
So what would y'all do here? The same problem applies to any operations on the edit control, like searching for text or loading and saving files, where we have to deal with the entire mass of text.
I think you need code something like this (excerpt from other code)
invoke SendMessage, hRich, EM_EXGETSEL, 0, ADDR Cr ; <---- to get selection size
mov eax, Cr.cpMin ; Cr is CHARRANGE structure
mov edx, Cr.cpMax
sub edx, eax
jz done ; if zero no text selected
mov selsize, edx ; <---- selection size
mov tmpsize, edx
invoke GlobalAlloc, GPTR, selsize ; allocate memory AL LEAST THAT SIZE
mov tmpbuf, eax
invoke GlobalAlloc, GPTR, tmpsize
mov tmpbuf2, eax
invoke SendMessage, hRich, EM_GETSELTEXT, 0, tmpbuf ; <------- get selected text into memory buffer
Oh, this code is for richedit controls. Not sure if it works with plain Edit controls but you CAN try. They are Edit Messages after all. (EM_??????). but I've only ever used with Richedit controls.
EM_GETSELTEXT doesn't work with edit controls, but this works:
push esi
mov esi, rv(SendMessage, hMyEdit, EM_GETHANDLE, 0, 0)
push rv(LocalLock, esi)
... extract the selected text here ...
invoke MessageBox, 0, eax, chr$("The full text:"), MB_OK
call LocalUnlock
pop esi
Ok cool. I wasn't so sure about using for edit controls.
Ah, EM_GETHANDLE. Never knew. Kewl! (Misleading name; when I saw it I assumed it returned a handle to the control itself.)
Test case attached (pure Masm32 SDK code).
QuoteEM_GETHANDLE:
The return value is a memory handle identifying the buffer that holds the content of the edit control. If an error occurs, such as sending the message to a single-line edit control, the return value is zero
Ah, who knew? I did'nt. :tongue: I thought it returned the control handle too.
JJ: I just want to thank you again for giving me the perfect solution to the problem at hand. EM_GETHANDLE and LocalLock() did the trick. No need for any memory management on my part!
Moral of the story: it pays to ask. (At least if you're in the right place.)
The saga continues.
I ran across another gotcha that I haven't seen documented anywhere, but figured out all by myself. My little editor can now load (and save) files. So I loaded a file, which happened to be the editor's source file. Fine and dandy. Looked great. Until I tried to edit it: I could move around in it, select text, but I couldn't type any text into it. WTF???
OK, to make a long story short, there's this thing called a "text limit", an upper limit to the amount of text an edit control can hold. The default seems to be 30,000; at least that's what I'm getting here on Win 7-64. But wait a minute: the file I loaded was even bigger than that, 53 Kb or so. So I was able to load a file over the limit, but unable to type any additional text into it. Weird.
The solution is to increase the text limit with EM_SETLIMITTEXT. Now I'm wondering what the convention is here: do you set the text limit to some extremely high number, like a bajillion characters? Or set it to the size of the file you're loading plus X for additional text? Is there a penalty for making the limit huge? (After all, the control has to allocate memory to store all that text.) What do people do here?
I've never seen Notepad not be able to load a huge file, so it must have some feedback going on as it works; maybe it can detect that it's hit the end of its buffer and just silently reallocates it. I don't see how to do this with a regular edit control; I guess you could look for EN_CHANGE notifications, which happen whenever the user types a character, and constantly check the amount of text in the control against the text limit and adjust it as needed ahead of time.
I just went ahead and set the limit to 100,000 for the meantime.
Quote from: NoCforMe on September 04, 2022, 04:48:03 PM
JJ: I just want to thank you again for giving me the perfect solution to the problem at hand. EM_GETHANDLE and LocalLock() did the trick. No need for any memory management on my part!
Moral of the story: it pays to ask. (At least if you're in the right place.)
You are definitely in the right place :tongue:
I wonder if there is still a difference between LocalLock/Unlock and GlobalLock/Unlock. This is old stuff.
Api Get file size + extra buffer= max typed chars in a day by fast secretary before load file choose by user?
Biggest file size change copy/paste big source file, api get clipboard size and reallocate + clip size?
Quote from: daydreamer on September 04, 2022, 10:11:21 PM
Api Get file size + extra buffer= max typed chars in a day by fast secretary before load file choose by user?
Biggest file size change copy/paste big source file, api get clipboard size and reallocate + clip size?
Please translate to English :tongue:
David,
You can play with the old format of GlobalAlloc() - GlobalLock() if you need the practice with old Win 3.0 junk but if you use GlobalAlloc() with the GMEM_FIXED flag, its return value casts directly to a pointer and you free it after use with GlobalFree(). You only use the old system with the clipboard.
Hutch,
The point here is that EM_GETHANDLE does the alloc for you, so no setting of GMEM_FIXED allowed.
Re GlobalLock==LocalLock: The EM_GETHANDLE example works fine with both GlobalLock and LocalLock (M$ docs is unclear as usual (https://docs.microsoft.com/en-us/windows/win32/memory/global-and-local-functions), but they recommend LocalLock (https://docs.microsoft.com/en-us/windows/win32/controls/em-gethandle)). Under the hood:
CPU Disasm GlobalLock
Address Hex dump Command Comments
75B5D0C7 $ /6A 10 push 10 ; VOIDPTR kernel32.GlobalLock(hMem)
75B5D0C9 . |68 50D1B575 push 75B5D150
75B5D0CE . |E8 ED44FEFF call 75B415C0--->
75B5D0D3 . |8B5D 08 mov ebx, [ebp+8]
75B5D0D6 . |F6C3 04 test bl, 04
75B5D0D9 . |0F84 7DEA0000 jz 75B6BB5C
75B5D0DF . |FF35 6000C175 push dword ptr [75C10060] ; /Arg1 = 260000
75B5D0E5 . |FF15 8003B475 call near [<&ntdll.RtlLockHeap>] ; \ntdll.RtlLockHeap
75B5D0EB . |8365 FC 00 and dword ptr [ebp-4], 00000000
75B5D0EF . |C745 FC 01000 mov dword ptr [ebp-4], 1
75B5D0F6 . |8D73 FC lea esi, [ebx-4]
75B5D0F9 . |56 push esi ; /Arg2
75B5D0FA . |FF35 5C00C175 push dword ptr [75C1005C] ; |Arg1 = KERNELBASE.76A416C0
75B5D100 . |FF15 8403B475 call near [<&ntdll.RtlIsValidHandle>] ; \ntdll.RtlIsValidHandle
--->
75B415C0 $ 68 CB49BE75 push 75BE49CB
75B415C5 . 64:FF35 00000 push dword ptr fs:[0]
75B415CC . 8B4424 10 mov eax, [esp+10]
75B415D0 . 896C24 10 mov [esp+10], ebp
75B415D4 . 8D6C24 10 lea ebp, [esp+10]
75B415D8 . 2BE0 sub esp, eax
75B415DA . 53 push ebx
75B415DB . 56 push esi
75B415DC . 57 push edi
75B415DD . A1 AC03C175 mov eax, [75C103AC]
75B415E2 . 3145 FC xor [ebp-4], eax
75B415E5 . 33C5 xor eax, ebp
75B415E7 . 50 push eax
75B415E8 . 8965 E8 mov [ebp-18], esp
75B415EB . FF75 F8 push dword ptr [ebp-8]
75B415EE . 8B45 FC mov eax, [ebp-4]
75B415F1 . C745 FC FEFFF mov dword ptr [ebp-4], -2
75B415F8 . 8945 F8 mov [ebp-8], eax
75B415FB . 8D45 F0 lea eax, [ebp-10]
75B415FE . 64:A3 0000000 mov fs:[0], eax
75B41604 . C3 retn
CPU Disasm LocalLock
Address Hex dump Command Comments
76A15493 . 6A 10 push 10 ; KERNELBASE.LocalLock(guessed Arg1)
76A15495 . 68 488FA376 push 76A38F48
76A1549A . E8 491F0200 call 76A373E8 --->
76A1549F . 33FF xor edi, edi
76A154A1 . 897D E4 mov [ebp-1C], edi
76A154A4 . 8B5D 08 mov ebx, [ebp+8]
76A154A7 . F6C3 04 test bl, 04
76A154AA . 0F84 AC000000 jz 76A1555C
76A154B0 . FF35 E016A476 push dword ptr [76A416E0] ; /Arg1 = 5C0000
76A154B6 . FF15 9013A076 call near [<&ntdll.RtlLockHeap>] ; \ntdll.RtlLockHeap
76A154BC . 897D FC mov [ebp-4], edi
76A154BF . C745 FC 01000 mov dword ptr [ebp-4], 1
76A154C6 . 8D73 FC lea esi, [ebx-4]
76A154C9 . 56 push esi ; /Arg2
76A154CA . 68 C016A476 push offset 76A416C0 ; |Arg1 = KERNELBASE.76A416C0
76A154CF . FF15 8C13A076 call near [<&ntdll.RtlIsValidHandle>] ; \ntdll.RtlIsValidHandle
--->
76A373E8 $ 68 5074A376 push 76A37450
76A373ED . 64:FF35 00000 push dword ptr fs:[0]
76A373F4 . 8B4424 10 mov eax, [esp+10]
76A373F8 . 896C24 10 mov [esp+10], ebp
76A373FC . 8D6C24 10 lea ebp, [esp+10]
76A37400 . 2BE0 sub esp, eax
76A37402 . 53 push ebx
76A37403 . 56 push esi
76A37404 . 57 push edi
76A37405 . A1 4012A476 mov eax, [76A41240]
76A3740A . 3145 FC xor [ebp-4], eax
76A3740D . 33C5 xor eax, ebp
76A3740F . 50 push eax
76A37410 . 8965 E8 mov [ebp-18], esp
76A37413 . FF75 F8 push dword ptr [ebp-8]
76A37416 . 8B45 FC mov eax, [ebp-4]
76A37419 . C745 FC FEFFF mov dword ptr [ebp-4], -2
76A37420 . 8945 F8 mov [ebp-8], eax
76A37423 . 8D45 F0 lea eax, [ebp-10]
76A37426 . 64:A3 0000000 mov fs:[0], eax
76A3742C . C3 retn
Note this brilliant example of compiler creativity:
75B5D0E5 . |FF15 8003B475 call near [<&ntdll.RtlLockHeap>] ; \ntdll.RtlLockHeap
75B5D0EB . |8365 FC 00 and dword ptr [ebp-4], 00000000
75B5D0EF . |C745 FC 01000 mov dword ptr [ebp-4], 1
I addressed memory allocation, not an edit control and the comment about using GMEM_FIXED is correct, return value casts directly to a pointer.
Quote from: NoCforMe on September 04, 2022, 08:56:42 PM
I've never seen Notepad not be able to load a huge file, so it must have some feedback going on as it works; maybe it can detect that it's hit the end of its buffer and just silently reallocates it. I don't see how to do this with a regular edit control; I guess you could look for EN_CHANGE notifications, which happen whenever the user types a character, and constantly check the amount of text in the control against the text limit and adjust it as needed ahead of time.
I've haven't looked under the hood of notepad for a long time. All this time I thought notepad used a rich edit control, when I read this I went and looked if it loads richedit. Sure enough a plain vanilla EDIT control.
Quote from: jj2007 on September 04, 2022, 10:18:18 PMPlease translate to English :tongue:
Don't you just love Magnus' late night rambling posts, after he's been hitting the sauce? :greensml: Not that I know that that is true though. Sorry Magnus if it is not, but the rambling makes it appear so. :tongue:
@ NoCforMe - Consider using two buffers? A very large file sized buffer and a smaller edit window sized buffer? When scrolling could read from larger file buffer to smaller edit window buffer (depending on how many lines were scrolled and how many lines of text are visible)? Involves tokenizing the lines of text that much I do remember. Also involves incrementing index to the tokenized lines of text.
I've used a similar technique in the past, looking for that code now. iirc the code for doing that is a little messy and somewhat cumbersome but iirc makes scrolling a huge file faster.edited to add:Later:
I'm going to do some tests using a method as just described later today when I've got some spare time...Later yet::
Okay, in the examples folder of the Masm32 SDK is an example "qikpad" which uses an EDIT control.
It can open & save 100 MB file without issue (after removing the 32kb limit warning) -
modifed version of qikpad is attached. Used 100 x "winextra.inc" = 100 MB for testing purposes. So much for the alleged 32kb limit. They must have changed the internals of EDIT controls since the Windows 98 days??
So, in light of that will not be trying the method I suggested earlier.
from MSDN
Quote
Remarks
The EM_SETLIMITTEXT message limits only the text the user can enter.
It does not affect any text already in the edit control when the message is sent, nor does it affect the length of the text copied to the edit control by the WM_SETTEXT message.
If an application uses the WM_SETTEXT message to place more text into an edit control than is specified in the EM_SETLIMITTEXT message, the user can edit the entire contents of the edit control.
Before EM_SETLIMITTEXT is called, the default limit for the amount of text a user can enter in an edit control is 32,767 characters.
Ah, ok. The limit is for
ENTERING TEXT, not setting window text via WM_SETTEXT or SetWindowText. :rolleyes:
I just tried adding text to that 100 MB file. no luck :sad: will not allow more chars to be added there. :sad: So, nevermind. :tongue:
GuiParas equ "Hello World", x300, w700, h999, b LiteBlueGreen ; width+height, margins, background colour
include \masm32\MasmBasic\Res\MbGui.asm
NanoTimer()
ClearLastError
GuiControl MyEdit, "Edit", bcol LiteYellow, fcol Black, font -14 ; colours & fonts have no effect with rtf files
invoke SendMessage, hMyEdit, EM_SETLIMITTEXT, 5000000, 0
SetWin$ hMyEdit=FileRead$(CL$())
GuiControl MyStatus, "statusbar", wRec$(NanoTimer$())
GuiEnd
So far, so simple: drag a file over the exe and see it load. What's interesting is that a 4.4MB "bible.txt" takes about 19 seconds to load. Notepad is a bit faster, at 4-5 seconds - how can it be 4 times as fast? Secret switches?
What's even more interesting is that, if you change "Edit" to "RichEdit", the same file loads in ... taraa! ... 105ms. That's a factor 176 faster. I like it.
Executables are attached.
Quote from: swordfish on September 05, 2022, 02:33:46 AM
from MSDN
Quote
Remarks
The EM_SETLIMITTEXT message limits only the text the user can enter.
It does not affect any text already in the edit control when the message is sent, nor does it affect the length of the text copied to the edit control by the WM_SETTEXT message.
If an application uses the WM_SETTEXT message to place more text into an edit control than is specified in the EM_SETLIMITTEXT message, the user can edit the entire contents of the edit control.
Before EM_SETLIMITTEXT is called, the default limit for the amount of text a user can enter in an edit control is 32,767 characters.
Ah, ok. The limit is for ENTERING TEXT, not setting window text via WM_SETTEXT or SetWindowText. :rolleyes:
I just tried adding text to that 100 MB file. no luck :sad: will not allow more chars to be added there. :sad: So, nevermind. :tongue:
But this works:
EditML proc szMsg:DWORD, tx:DWORD, ty:DWORD, wd:DWORD, ht:DWORD,
hParent:DWORD, ID:DWORD, Wrap:DWORD
LOCAL hCtl :DWORD
LOCAL hFnt :DWORD
LOCAL eStyle :DWORD
szText CtlStyle, "EDIT"
mov eStyle, WS_VISIBLE or WS_CHILDWINDOW or \
WS_VSCROLL or ES_NOHIDESEL or \
ES_AUTOVSCROLL or ES_MULTILINE
.if Wrap == 0
or eStyle, WS_HSCROLL or ES_AUTOHSCROLL
.endif
invoke CreateWindowEx, WS_EX_CLIENTEDGE, ADDR CtlStyle, szMsg,
eStyle, tx, ty, wd, ht, hParent, ID, hInstance, NULL
mov hCtl, eax
invoke SendMessage, hCtl, EM_SETLIMITTEXT, 0, 1024000000 ; <---- 1GB you won't need more I hope :P
invoke GetStockObject, SYSTEM_FIXED_FONT
mov hFnt, eax
invoke SendMessage, hCtl, WM_SETFONT, hFnt, TRUE
mov eax, hCtl
ret
EditML endp
Now can add text to very large file. Edited source attached
Apparently internally some form of memory management is already done - to allow more text to be written to the control. Only time that you need worry about memory size is when copying the text to a buffer for writing to file, which is a simple task.
Why on earth in these days of ample memory are the EDIT controls limited at all? I understand in the early days of x86 memory was limited by hardware constraints, and other factors. In any case I mostly use richedit controls with all of their idiosyncrasies, as they are more versatile - BUT still use EDIT in dialog boxes for their simplicity of usage there. edit = clarification.
Quote from: jj2007 on September 04, 2022, 10:18:18 PM
Quote from: daydreamer on September 04, 2022, 10:11:21 PM
Api Get file size + extra buffer= max typed chars in a day by fast secretary before load file choose by user?
Biggest file size change copy/paste big source file, api get clipboard size and reallocate + clip size?
Please translate to English :tongue:
I get the gist of what he's suggesting; somehow estimate the amount of text likely to be added to a file after being loaded, including extra text pasted to it. I have no idea how to get such an estimate. The technical staff here at NoCforMe Laboratories, GmbH, isn't able to derive such an estimate.
I'll just ballpark it, I guess.
Z,
qikpad was about the last time I wrote a text editor using the standard edit control. With a rich edit 2-3 control in 32 bit, 100 meg is no problem, in 64 bit over 700 meg can be done. If you set the limit to "-1" you can load very large text.
RTF is a different animal, it is much more complex and does much more work so the speed drops off a lot faster. I generally use a normal edit control for dialogs or where relatively small amounts of text are used and use the rich edit controls for large text and drag and drop, both of which works well.
Quote from: NoCforMe on September 05, 2022, 05:34:41 AM
I'll just ballpark it, I guess.
use WM_GETTEXTLENGTH or a call to GetWindowTextLength??? to determine buffer size needed...
Quote from: hutch-- on September 05, 2022, 05:39:24 AM
Z,...
qikpad was about the last time I wrote a text editor using the standard edit control.
Understood of course, written back in the stone age. :tongue:
I was just using it as an example since NoCforMe is also using an EDIT control for this project.
Quote from: swordfish on September 05, 2022, 05:45:26 AMuse WM_GETTEXTLENGTH??? to determine buffer size needed...
When you load a file, you know its size.
Quote from: jj2007 on September 05, 2022, 05:49:24 AM
When you load a file, you know its size.
For the modified, i.e., 'added to' size :rolleyes:
After adding text, the loaded filesize is meaningless unless you are just opening a file to turn right around and close it.
@ NoCforMe...
If you want to pre-allocate (as suggested in original post) you will of course risk a buffer overrun, which I assume is undesirable.
Quote from: swordfish on September 05, 2022, 05:50:55 AM
Quote from: jj2007 on September 05, 2022, 05:49:24 AM
When you load a file, you know its size.
For the modified, i.e., 'added to' size :rolleyes:
After adding text, the loaded filesize is meaningless unless you are just opening a file to turn right around and close it.
Right, so you haven't answered the question at all, which is "how much extra should I add to the buffer size
after opening the file?". Of course I know the size of the file and therefore the
minimum buffer size needed to hold it, but that value needs to be increased or the poor user won't be able to add any new text!
Quote@ NoCforMe...
If you want to pre-allocate (as suggested in original post) you will of course risk a buffer overrun, which I assume is undesirable.
No, that's not an issue here; the edit control code takes care of that. The buffer won't be overrun; the control simply won't let you add anything extra to it, which is what happened to me when the text limit was less than the size of the file I loaded. It didn't overrun the buffer, just refused any input.
Quote from: NoCforMe on September 05, 2022, 05:34:41 AM
Quote from: jj2007 on September 04, 2022, 10:18:18 PM
Quote from: daydreamer on September 04, 2022, 10:11:21 PM
Api Get file size + extra buffer= max typed chars in a day by fast secretary before load file choose by user?
Biggest file size change copy/paste big source file, api get clipboard size and reallocate + clip size?
Please translate to English :tongue:
I get the gist of what he's suggesting; somehow estimate the amount of text likely to be added to a file after being loaded, including extra text pasted to it. I have no idea how to get such an estimate. The technical staff here at NoCforMe Laboratories, GmbH, isn't able to derive such an estimate.
I'll just ballpark it, I guess.
Something like that
Many years ago I tried find solution to use rich edit control as alternative to achieve similar as console loc column, row macro combined with print for simple output tictactoe x's and o's or other simple ascii or unicode based output, I couldn't figure out characters / line,so i could make a loc column,row function or macro for rich edit :sad:
Just change text buffer and SendMessage to rich edit
Anyone made a function to go certain line number before?
:biggrin:
Don't make DOS assumptions, add a megabyte and see if that extends your limit, then try 10 megabytes etc ....
Quote from: NoCforMe on September 05, 2022, 06:01:31 AM
but that value needs to be increased or the poor user won't be able to add any new text!
Not really, internally it is handled. You only need to then retrieve text length AFTER text has been added. You don't need to use the same buffer after writing more text into the edit window. You already know this stuff, so whats the dilemma?
Thats all I have to say here. :cool:
Quote from: NoCforMe on September 05, 2022, 06:01:31 AMRight, so you haven't answered the question at all, which is "how much extra should I add to the buffer size after opening the file?"
That answer has been given at least twice: invoke SendMessage, hEdit, EM_SETLIMITTEXT,
-1, 0
Quote from: NoCforMe on September 05, 2022, 06:01:31 AM
The buffer won't be overrun; the control simply won't let you add anything extra to it,
use EM_SETLIMITTEXT
invoke SendMessage, hCtl, EM_SETLIMITTEXT, 0, 1024000000 ; <---- 1GB you won't need more I hope :PThats why I attached qikpad_largelimit.zip in a previos post as an example that it works
OK, so two definitive suggestions here, from JJ and Hutch. Regarding JJs, that's setting the text limit to the max. Hutch recommends some smaller values. Are there any bad consequences to setting the text limit to such high values? Will the edit control eat up all available memory?
Swordfish, I don't think you quite grasp the situation. You wrote "You only need to then retrieve text length AFTER text has been added.". But that would require a time machine; without increasing the text limit in the situation I described, you can't add any more text to the control. See how that works?
Again, ballparking seems to be the answer here. The question is about the size of the ballpark; Little League or Shea Stadium?
see post above, and see the attachment mentioned. run it with a large file, while watching Taskmgr Thats why I attached that file, so you can experiment with these issues there without crapping up your source code.
Just set the text limit very large. Most computers these days have tons of memory, I seriously doubt anyone will use all of it for a text file.
Look, Swordfish, I know you're trying to be helpful here, but I really need answers from someone who knows what the actual consequences of setting high limits on edit control text are, if any such people are hanging around here.
Setting the text limit has no ill effects by itself. qeditor has a very high text limit for example. sure its rich edit, but same rules apply. And after years of using and abusing by everyone, no issues in that regard.
Thats all I have to say. :sad:
Ackshooly, it occurs to me:
OR IcouldTry, aRichEditControl
(code would actually work if "aRichEditControl" were a constant ...)
Quote from: NoCforMe on September 05, 2022, 06:14:45 AMI really need answers from someone who knows what the actual consequences of setting high limits on edit control text are, if any such people are hanging around here.
Why don't you test it? That's what I have been doing, and I can assure you that setting the text limit to -1, i.e. 4,294,967,295 bytes does not crash my machine.
Btw speedwise it's a
huge difference if ES_AUTOHSCROLL is set or not.
Quote from: jj2007 on September 05, 2022, 06:31:58 AM
Btw speedwise it's a huge difference if ES_AUTOHSCROLL is set or not.
Actually a necessity to
not set it, otherwise you don't get line wrap; as Swordfish once wrote, the characters just fall off the right side of your monitor onto the floor.
The speed difference must come from having to invoke the line-wrapping code each time a line of text hits the right edge of the window.
Quote from: NoCforMe on September 05, 2022, 06:33:48 AM
Quote from: jj2007 on September 05, 2022, 06:31:58 AM
Btw speedwise it's a huge difference if ES_AUTOHSCROLL is set or not.
Actually a necessity to not set it, otherwise you don't get line wrap; as Swordfish once wrote, the characters just fall off the right side of your monitor onto the floor.
The speed difference must come from having to invoke the line-wrapping code each time a line of text hits the right edge of the window.
Well, they don't fall off, but if column 1024 is reached, the text gets merciless wrapped, right in the middle of a word. But it's definitely much faster with ES_AUTOHSCROLL (about a factor 10), see Qikpad.exe
However, most of the time we don't see this problem, simply because our sources don't have such line lengths. Use bible.zip (https://jj2007.eu/Bible.zip) to do real tests.
I should have said "a necessity if you want line wrap", which I do want. Speed not so much an issue, though it would be nice.
https://stackoverflow.com/questions/56781359/how-do-i-toggle-word-wrap-in-a-editbox
Interesting: the suggestion (apparently the only way to do this, to change between word-wrapping and not) is to destroy the control, then re-create a new one with different styles and transferring over the old buffer contents.
I was thinking of implementing this as a user option, but this method seems so ugly I think I'll just stick with one way or the other.
Yep, that is the sad truth. In my editor, I just hit Ctrl W to toggle word wrap... but then, it's a richedit control.
The pooredit control was not designed for large texts and bells and whistles.
But I thought that RichEdit had the same limitation on not being able to change word wrap once the control was created, at least from everything I read online about it. Do you have some secret recipe that lets you change that without destroying and re-creating the control?
Quote from: NoCforMe on September 05, 2022, 05:54:06 PMsecret recipe
invoke SendMessage, hEdit, EM_SETTARGETDEVICE, 0, 1 ; 0=wrap, 1=no wrap
:biggrin:
David,
One of the things you learn about rich edit controls is there are plenty of recipes to get them to work. I personally stick to riched 2 or 3, the earlier one is past it and the later 4 does things that I don't need or want.
JJ--are you sure about that? I was just looking at that message in MSDN (https://docs.microsoft.com/en-us/windows/win32/controls/em-settargetdevice), and they give the parameters as
Parameters
wParam
HDC for the target device.
lParam
Line width to use for formatting.
??????
Perhaps it is an undocumented special feature, but wine had it.
richedit: Added support for EM_SETTARGETDEVICE with a NULL DC (https://www.winehq.org/pipermail/wine-cvs/2008-March/041370.html)
Quote from: NoCforMe on September 05, 2022, 08:25:55 PM
JJ--are you sure about that? I was just looking at that message in MSDN (https://docs.microsoft.com/en-us/windows/win32/controls/em-settargetdevice), and they give the parameters as
Parameters
wParam
HDC for the target device.
lParam
Line width to use for formatting.
??????
Try Ctrl W in RichMasm.
OK, so we're relying on an Undocumented Feature here. Hopefully won't get broken in the next version of Windoze. (Hello, Raymond Chen!)
Quote from: TimoVJL on September 05, 2022, 09:10:24 PM
Perhaps it is an undocumented special feature, but wine had it.
richedit: Added support for EM_SETTARGETDEVICE with a NULL DC (https://www.winehq.org/pipermail/wine-cvs/2008-March/041370.html)
REACTOS (https://doxygen.reactos.org/da/d30/dll_2win32_2riched20_2editor_8c_source.html):
Quote"EM_SETTARGETDEVICE doesn't use non-NULL target devices\n"
It is not documented, but everybody uses the null DC - for the screen, not for printers.
[caution: possible thread drift ahead]
I'm confused here. Isn't the (stated) purpose of this message to render RichEdit text on a device (presumably a printer) in a WYSIWYG manner?
If so, then how could it possibly only work on a NULL DC? Is the MSDN documentation totally off here?
Here's (https://devblogs.microsoft.com/oldnewthing/20070112-02/?p=28423) one of Raymond Chen's blog entries in which he explains how to print RichEdit text. His code uses this message for its stated purpose. (Of course, this was written in 2007; maybe things have changed since then?) So maybe there's the intended behavior and the undocumented functionality.
Also, I looked at that ReactOS page and I'm really curious: what exactly is that project? They seem to be examining stuff in the OS to see if it works or not, or maybe I'm missing something here. (Hmm; maybe it has something to do with Doxygen (https://doxygen.nl/index.html). But then, what is that? something about "Generat[ing] documentation from source code".)
Anyhow, if EM_SETTARGETDEVICE works for you to toggle word-wrapping in a RichEdit control, then I'm game to try it.
Quote from: NoCforMe on September 06, 2022, 06:55:03 AMI'm confused here. Isn't the (stated) purpose of this message to render RichEdit text on a device (presumably a printer) in a WYSIWYG manner?
Sure. A line length of 1 means "don't even try to wrap that" :cool:
QuoteIf so, then how could it possibly only work on a NULL DC? Is the MSDN documentation totally off here?
MSDN doesn't mention that option. I vaguely remember to have seen that Windows replaces a NULL DC with the screen DC but can't find it.
RichEdit is a wonderful control, but it has its quirks (http://masm32.com/board/index.php?topic=6563.0).
Quote from: murrays on April 19, 2017, 09:17:33 AM
Please don't use Windows' riched20.dll. It's only there for compatibility with ancient code. Upgrade to msftedit.dll. It's modern, fast, but doesn't yet support math. Hopefully soon. It did for a while in the Windows 8 beta, but then somebody disabled it :( The Office riched20.dll is the best version at the moment. RichEdit runs on iOS, Mac, Android, Windows and WinRT. It supports math and now supports LaTeX math input/output as well. My Math in Office blog (https://devblogs.microsoft.com/math-in-office/author/murrays/) will have a post on it soon.
It really depends on what you want out of a rich edit control. Version 1 is past it but worked OK at the time, version 2 - 3 has been around for a long time and while it is not without its quirks, I find it useful, mainly for plain text for code editors but it also handles RTF well enough in terms of colour and fonts and formatting, the reason why I have used it in my latest help file format.
I have no real interest in emulating a word processor or a spread sheet so much of the extra things the latest version does are no use to me.
What some may find is that there are a number of people here who have been writing text editors for a very long time, in my own case, I wrote my own editors back in 16 bit Windows in Microsoft C and later in GFA basic. In 32 bit Windows I wrote them in PowerBASIC and later in 32 bit MASM. In 64 bit, 64 bit MASM is the latest.
I am pleased to see other people also writing rich edit based editors but they need to realise that others have done it as well and for a very long time. No-one is taking the piss out of you when they comment on how to improve certain types of code or know another way that works better, its one of the things that a forum of this type is good at, passing on know how rather than hiding it.
Quote from: hutch-- on September 06, 2022, 08:41:23 AMI wrote my own editors back in 16 bit Windows in Microsoft C and later in GFA basic.
I wrote my first word processor in GfaBasic on the Atari ST, around 1986. It had advanced search facilities, and I could embed graphics. Once I wrote a scientific book with it, and it got accepted "as is" by a renowned publishing house, graphics included. I wrote the screen and printer drivers in 68000 Assembly. It still works fine on this machine, using the Steem emulator.
Quote from: hutch-- on September 06, 2022, 08:41:23 AMNo-one is taking the piss out of you when they comment on how to improve certain types of code or know another way that works better, its one of the things that a forum of this type is good at, passing on know how rather than hiding it.
:thumbsup:
my interest in learn foreign languages I tested unicode rich edit with japanese and arabic,I read that there are rich edit version on asian windows to support the vertical japanese writing
arabic vs western there is need to reverse string when convert from text written in western alphabet to arabic unicode,could be as much as a whole book is reversed
I have choosed to concentrate on learn japanese as third language
richedit from 2.0 is internally UNICODE ?
how to check it ?
Japanese is reasonably straight forward in UNICODE, Win10 has the fonts and rich edit 2 - 3 will display it correctly. Arabic and Hebrew are a lot more complicated as right to left notation, you may need an Arabic or Hebrew version of Windows to be able to enter characters. May also be the case if you want to use the keyboard for Japanese. Its in the reference material.
Win7 can display Arabic, Chinese etc., see RichMasm menu Autocode/strings
Back in win98se, if you downloaded the asian fonts you could do most languages. Win2000 was better and XP was better again. Its been that long since I seriously ran in7 64 bit that I forget what it would do. (I installed Win7 64 on a recent computer a year os so ago but immediately overinstalled Win 10 64. It was just to use the Win7 64 serial number as it was a retail black edition.
With UNICODE layer things was working, like after installing IE.