Hi all!
I know one old truth - if I couldn't find any answer at any forum, search engine or discussion - this is the right place :8)
I have a rich edit control with word wrap set by SendMessageW, hEdit, EM_SETTARGETDEVICE, 0, 0
Without word wrap I can retrieve line's index by EM_EXLINEFROMCHAR. But this message seems not to pay attention to wrapping. It just returns index after index for each line, no matter it's wrapped or not. All I need is to find right line number for first visible line. I tried to calculate new line characters amount from the beginning of control - it works until there are a small amount of lines, but if there are 5000 - 10000 lines, it just "dies".
You are my only hope... :boohoo:
I assume you tried EM_GETFIRSTVISIBLELINE ?
Yes, of course.
It returns index for line as it appears in control, i.e. if I have one wrapped line and one not, then I'll get indexes 0, 1, 2, while the right indexes should be 0,1, because the first line is wrapped.
Andre,
I confess that in a word wrap editor I turn the ine numbering off.
Hi lamer,
I checked my own editor for this behaviour and surprise, surprise, it works as it should. However, my own way of setting word wrap differs considerably from yours:
mov ecx, MyStyle
.if ExtAsc
or ecx, ES_AUTOHSCROLL ; DO NOT WRAP for Assembler Source Code files
.endif
or ecx, WS_CLIPSIBLINGS ; Test
invoke CreateWindowEx, 0, eax, 0,
ecx, 0, cHeight, rc.right, rc.bottom,
hwndOwner, NULL, hinst, NULL
mov hRE, eax
I attach temporarily the whole package (but without my confused source, sorry). It contains two almost identical files: Manual.rtf and Manual.asc; drag them one by one over richmasm.exe and watch the line counter in the upper right corner. If this is the behaviour you want, I would consider ES_AUTOHSCROLL.
EDIT: Modified attachment. I added
btc NoWordWrap, 0
sm hRE, EM_SETTARGETDEVICE, 0, NoWordWrap
triggered by Control W. I must confess this is confusing: It seems ES_AUTOHSCROLL during creation sets the word wrap mode, but only EM_SETTARGETDEVICE can change it at runtime. MSDN (http://msdn.microsoft.com/en-us/library/bb774282(VS.85).aspx)does not document this behaviour.
EDIT (2): Attachment removed. See later posts.
JJ, the problem is that the wrapped portion of a line is numbered as an extra line, not as a part of the whole line. So a single long line wrapped into 3 sections becomes numbered as lines 1, 2, and 3 - whereas they should all be line 1, with the column value increasing along each.
Lamer, sorry I don't think there's any straightforward way to fix it. One way would be to parse the text to find the start each real line, but obviously that's nice and slow, and needs to be updated each time the text changes.
Notice that notepad simply hides the statusbar when wrapping, so there are no line numbers displayed.
The following allows line numbering to work correctly in my editor.
WordWrap proc
;---------------------------------------
.if WWrap==0 ; If wordwrap is off
invoke CheckMenuItem, hMenu, ID_MNU_WWRAP, MF_UNCHECKED ; Clear the check mark
push 1 ; Save new setting
.else
invoke CheckMenuItem, hMenu, ID_MNU_WWRAP, MF_CHECKED ; Set the check mark
push 0 ; Save new setting
.endif
pop WWrap ; Get WWrap setting
;
invoke SendMessage, hEditorBox, EM_SETTARGETDEVICE, 0, WWrap
ret
;---------------------------------------
WordWrap endp
-- Paul
Quote from: Tedd on July 17, 2008, 11:12:47 AM
JJ, the problem is that the wrapped portion of a line is numbered as an extra line, not as a part of the whole line. So a single long line wrapped into 3 sections becomes numbered as lines 1, 2, and 3 - whereas they should all be line 1, with the column value increasing along each.
OK. In my editor, I have disabled word wrap for asc (Assembler Source Code) files, simply because it's rarely needed and may even confuse the reader.
Quote
Lamer, sorry I don't think there's any straightforward way to fix it. One way would be to parse the text to find the start each real line, but obviously that's nice and slow, and needs to be updated each time the text changes.
Notice that notepad simply hides the statusbar when wrapping, so there are no line numbers displayed.
Here is a faster option (tested, it works, but I will not implement it in RichMasm):
.if NoWordWrap==0
btc NoWordWrap, 0
sm hRE, EM_SETTARGETDEVICE, 0, NoWordWrap
sm hRE, EM_EXLINEFROMCHAR, 0, -1 ; get current line
push eax
btc NoWordWrap, 0
sm hRE, EM_SETTARGETDEVICE, 0, NoWordWrap
pop eax
.else
sm hRE, EM_EXLINEFROMCHAR, 0, -1 ; get current line
.endif
Tedd;
I do not see how the following is necessary as if everything is done correctly, wordwrap followed by some sort of line number update procedure (I use something called ShowPosition) works correctly.
Quote
Lamer, sorry I don't think there's any straightforward way to fix it. One way would be to parse the text to find the start each real line, but obviously that's nice and slow, and needs to be updated each time the text changes.
Notice that notepad simply hides the statusbar when wrapping, so there are no line numbers displayed.
as far as the settings used to create the edit window, I used the following:
;--------------------------------------------;
; This function creates a rich text editbox. ;
;--------------------------------------------;
CreateRichEdit proc uses ebx ecx edx edi esi hWin:DWORD,Xsize:DWORD,Ysize:DWORD,Xpos:DWORD,Ypos:DWORD
;---------------------------------------
LOCAL hEdit:DWORD
.if hRich == 0
invoke LoadLibrary, addr RichEditDLL
mov hRich, eax
invoke GetProcessHeap
mov hMainHeap, eax
.endif
invoke CreateWindowEx, WS_EX_CLIENTEDGE, txt("RichEdit20A"), 0, WS_CHILD or \
WS_VISIBLE or ES_MULTILINE or WS_VSCROLL or WS_HSCROLL or ES_SAVESEL or \
ES_NOHIDESEL, Xpos, Ypos, Xsize, Ysize, hWin, 9400, hInstance, 0
mov hEdit, eax
invoke SendMessage, hEdit, EM_SETTYPOGRAPHYOPTIONS, TO_SIMPLELINEBREAK, TO_SIMPLELINEBREAK
invoke SendMessage, hEdit, EM_LIMITTEXT, -1, 0
invoke SendMessage, hEdit, EM_SETMODIFY, FALSE, 0
invoke SendMessage, hEdit, EM_SETEVENTMASK, 0, ENM_MOUSEEVENTS
invoke SendMessage, hEdit, EM_EMPTYUNDOBUFFER, 0, 0
invoke SendMessage, hEdit, EM_SETOPTIONS, ECOOP_XOR, ECO_SELECTIONBAR
;---------------------------
; Check the RichEdit version
;---------------------------
invoke SendMessage, hEdit, EM_SETTYPOGRAPHYOPTIONS, TO_SIMPLELINEBREAK, TO_SIMPLELINEBREAK
invoke SendMessage, hEdit, EM_GETTYPOGRAPHYOPTIONS, 1, 1
.if eax == 0 ; Means this message is not processed
mov RichEditVersion, 2
.else
mov RichEditVersion, 3
.endif
;------------------------------
; Subclass the RichEdit control
;------------------------------
invoke SetWindowLong, hEdit, GWL_WNDPROC, addr NewRichEditProc
mov lpOldRichProc, eax
mov eax, hEdit
ret
;---------------------------------------
CreateRichEdit endp
Let's just Write the code correctly instead of trying to find nonexisting problems.
-- Paul
May be I miss something :dazzled: but I still don't see how to find index of one , only one wretched line in word wrap case.
You have overloaded me with ways of rich edit creation :green, but where is line numbering procedures everybody is speaking about?
Oh, I forgot - I use TM_PLAINTEXT for control, i.e. no rich edit options.
P.S.
I have to say - I really love this forum. There is a kind of magnetic force here (may be this is an "assembly" men's feature? or just a staff quality?) :wink
Quote from: lamer on July 17, 2008, 06:15:41 PM
May be I miss something :dazzled: but I still don't see how to find index of one , only one wretched line in word wrap case.
Try my "faster option" above. It temporarily disables wrapping, so that you can get the "true" line count. You may consider suspending screen updating, or setting a flag in case WM_PAINT makes trouble, but otherwise it works smoothly.
I do the numbering on WM_PAINT. Switching between wrap and no wrap within WM_PAINT? Hmmm....
But it gives me the idea: what if I had one more, unvisible rich edit with the same text without wrapping? Then I could find needed line index in it. But from the other side loading two controls will take a lot of time for big files :eek
lamer,
It is worth a try.
-- Pal
Quote from: lamer on July 17, 2008, 09:01:29 PM
I do the numbering on WM_PAINT. Switching between wrap and no wrap within WM_PAINT? Hmmm....
Set a global flag, and quit WM_PAINT if it's set. Clear it when you are done... if all that is needed. As I wrote above, I tested it, and it worked, apparently even without flicker.
Quote
But it gives me the idea: what if I had one more, unvisible rich edit with the same text without wrapping? Then I could find needed line index in it. But from the other side loading two controls will take a lot of time for big files :eek
And you need to synchronise them. Sounds like a big overkill for such a simple problem.
Quote from: PBrennick on July 17, 2008, 04:55:46 PM
Let's just Write the code correctly instead of trying to find nonexisting problems.
I couldn't agree more :wink
Unfortunately, the problem still persist with your 'solution' - so I expect there may be a misunderstanding of what the problem actually is..
So, let say we have the following unwrapped text:
Quote
1: This is line one. Line 1. This is line one. Line 1. Line 1. Line 1.
2: Next comes line two. This is line 2. Line 2. Line 2. Line 2. Line 2.
3: After that is line three. Line 3. Line 3. Line 3. Line 3. Line 3. Line 3.
4: And finally, line four. Line 4. Line 4. Line 4. Line 4. Line 4. Line 4.
The line numbers are pretty obvious.
Now, if we wrap it, there are two possibilities for how to number the lines:
Version 1
Quote
1: This is line one. Line 1. This is line
2: one. Line 1. Line 1. Line 1.
3: Next comes line two. This is line 2.
4: Line 2. Line 2. Line 2. Line 2.
5: After that is line three. Line 3. Line
6: 3. Line 3. Line 3. Line 3. Line 3.
7: And finally, line four. Line 4. Line 4.
8: Line 4. Line 4. Line 4. Line 4.
Version 2
Quote
1: This is line one. Line 1. This is line
one. Line 1. Line 1. Line 1.
2: Next comes line two. This is line 2.
Line 2. Line 2. Line 2. Line 2.
3: After that is line three. Line 3. Line
3. Line 3. Line 3. Line 3. Line 3.
4: And finally, line four. Line 4. Line 4.
Line 4. Line 4. Line 4. Line 4.
Your solution results in version 1, and indeed this is how richedit words. But that is the problem.
The question is how to get version 2. Why? Well let's say your compiler/assembler reports there's a syntax error on line 4 - which line 4 would that be??
I attempted to try JJ's method, but it resulted in an exception as soon as the line number is updated :dazzled:
Quote from: Tedd on July 18, 2008, 11:45:44 AM
I attempted to try JJ's method, but it resulted in an exception as soon as the line number is updated :dazzled:
Me dazzled, too :dazzled:
I have now implemented this - extract all files to root of Masm drive, then drag LineTest.asc over RichMasm.exe and press Control W to toggle wrap. It works over here on XP SP2...
LOCAL CurLine:DWORD
...
.if NoWordWrap==0
sm hRE, EM_SETTARGETDEVICE, 0, 1
sm hRE, EM_EXLINEFROMCHAR, 0, -1 ; get current line
mov CurLine, eax
sm hRE, EM_SETTARGETDEVICE, 0, 0
mov eax, CurLine
.else
sm hRE, EM_EXLINEFROMCHAR, 0, -1 ; get current line
mov CurLine, eax
.endif
Temporarily disabling the line wrap works but an additional redraw block might be needed. Will keep you posted ;-)
EDIT:
MSDN: (http://msdn.microsoft.com/en-us/library/bb774369(VS.85).aspx) For Microsoft Rich Edit 2.0 and later, Rich Edit no longer supports EditWordBreakProcEx. Users can send EM_SETWORDBREAKPROC to set EditWordBreakProc, which is now enhanced to support the passing of Unicode text.
Cute and clear, isn't it? "EX" is the obsolete one. Anyway, just as an idea: One might cheat the control in the callback that handles the line breaks.
The brute force alternative is to act on EN_CHANGE: save the whole stuff as plain text to a buffer, and count the 0D0A until the character pos. I love the RichEdit control, it is so full of challenges, and working with it requires the use of the whole programming toolbox, for finding workarounds tackling with "unexpected behaviour". :boohoo:
LOCAL txrg:TEXTRANGE
LOCAL CurLine:DWORD
sm hRE, EM_EXGETSEL, 0, addr txrg ; get current sel
.if NoWordWrap==0 ; still a problem with scrolling
Refresh_OFF
sm hRE, EM_SETTARGETDEVICE, 0, 1
sm hRE, EM_EXLINEFROMCHAR, 0, -1 ; get current line
mov CurLine, eax
sm hRE, EM_SETTARGETDEVICE, 0, 0
sm hRE, EM_EXSETSEL, 0, addr txrg ; set current sel
mov eax, CurLine
Refresh_ON
.else
sm hRE, EM_EXLINEFROMCHAR, 0, -1 ; get current line
mov CurLine, eax
.endif
Refresh_ON EQU invoke UpdateRE, 1
Refresh_OFF EQU invoke UpdateRE, 0
UpdateRE proc flag:DWORD ; 1=ON
pushad
.if flag
.if OldMask ; set might happen twice in a row, so let's be cautious
sm hRE, EM_SETEVENTMASK, 0, OldMask
clrx OldMask
.endif
sm hRE, WM_SETREDRAW, 1, 0
invoke InvalidateRect, hRE, 0, 0 ; redraw the RichEdit window
.else
sm hRE, EM_SETEVENTMASK, 0, 0
.if eax
mov OldMask, eax
.endif
sm hRE, WM_SETREDRAW, 0, 0
.endif
popad
ret
UpdateRE endp
[attachment deleted by admin]
Tedd,
I see your point. I guess I never realized that anyone would wish to use wordwrap in a .ASM source file. My solution would not be of much use, I guess. Really, the only reason I added the wordwrap function into my editor is for the generation of text readme type files and the like. Correct me if I am wrong, but would not wrapping a source file inject linebreaks into the middle of a line and cause the assembler to hiccup?
Everybody has their own idea of how things are done and I 'do' respect that. I just never have seen a source line that needs to be wrapped (except for the comments, which are ignored by the assembler, anyhow. So, I am certain I am missing the point of all this.
-- Paul
Quote from: PBrennick on July 18, 2008, 03:35:19 PM
I see your point. I guess I never realized that anyone would wish to use wordwrap in a .ASM source file. My solution would not be of much use, I guess. Really, the only reason I added the wordwrap function into my editor is for the generation of text readme type files and the like.
The original question didn't specify any particular type of source file :wink I only used source code as an example, but yes, it's probably less useful for asm.
Quote
Correct me if I am wrong, but would not wrapping a source file inject linebreaks into the middle of a line and cause the assembler to hiccup?
Well when you save the file, you'd generally expect it to be saved without the 'soft' linebreaks that the edit control uses internally (to enforce wrapping) - it should be saved the same regardless of whether wrapping or not.
Quote
Everybody has their own idea of how things are done and I 'do' respect that. I just never have seen a source line that needs to be wrapped (except for the comments, which are ignored by the assembler, anyhow. So, I am certain I am missing the point of all this.
While it's not necessarily good style, it can/does happen in other languages. And as for comments, while they are largely ignored by the compiler, any references to proceeding lines would consequently be incorrect (as the wrapped lines would offset the count.)
The 'point' is simply that Lamer would like to do it this way :lol
I would seriously consider the brute force approach. Saving the whole file to a buffer via GETTEXTRANGE is pretty fast, and searching with a mov ax, [esi] is fast, too. You can search the whole \masm32\include\* in roughly 20 ms - too little to be noticed when typing a text.
EDIT: Sample code "brute force"
This could certainly be optimised; in particular, the EM_GETTEXTRANGE message is needed only after an EN_CHANGE notification. I did some timings on Windows.inc: If the cursor is in the last line, the algo takes about 25 ms, unnoticeable even with fast keyboard repeat settings.
sm EQU invoke SendMessage, ; makes typing easier ;-)
LOCAL txrg:TEXTRANGE
LOCAL CurLine:DWORD
call DispMenu
push edi
push ebx
sm hRE, EM_EXGETSEL, 0, addr txrg ; get current sel
.if NoWordWrap==0
.if LcBuffer$==0
mov LcBuffer$, alloc$(1000000) ; free$ on exit! Needs checks on size.
.endif
; invoke GetTickCount
; push eax
; xor edi, edi ; counter
; .While edi<10
; inc edi
push esi
mov esi, LcBuffer$
mov txrg.lpstrText, esi
mov ebx, txrg.chrg.cpMin
push txrg.chrg.cpMax
mov txrg.chrg.cpMax, ebx ; current start of selection
m2m txrg.chrg.cpMin, 0
sm hRE, EM_GETTEXTRANGE, 0, addr txrg
pop txrg.chrg.cpMax
mov txrg.chrg.cpMin, ebx
xor edx, edx
mov CurLine, edx
add edx, 13 ; 0D
add ebx, esi
@@: mov al, [esi] ; inner loop - try lodsb...
add esi, 1
cmp esi, ebx
ja @F
cmp al, dl
jne @B
inc CurLine
jmp @B
@@: mov eax, CurLine
pop esi
; .Endw
; invoke GetTickCount
; pop edx
; sub eax, edx
.else
sm hRE, EM_EXLINEFROMCHAR, 0, -1 ; get current line
mov CurLine, eax
.endif
inc eax ; Line n
invoke dwtoa, eax, pDwToA
I'm glad to state that I have been right - this forum is really the best. Not just one question has got multiple answers and solutions, it's grown into some kind of philosophical discussion.
In my opinion calculating new line characters is still the best solution - at least for not very large files.
So thank you all very much! :clap:
You are welcome, lamer. You raised a good question, and got qualified answers :bg
Re the code posted above, I use it now in my own rich editor. At the bottom of Windows.inc, response is a bit sluggish - maybe I should take away that .While ebx<100 loop ;-)
Jokes apart: Searching 800k of Windows.inc for CR takes about 1.8 milliseconds. The EM_GETTEXTRANGE is the bottleneck, but even if I use that message for each and every cursor movement, response is still ok in a 1 MB file. If you trigger that message only for EN_CHANGE, or with a WM_TIMER if there is more then x ms without EN_CHANGE, then response times will be ok even for 100 MB files.
:bg
Andre,
Quote
I'm glad to state that I have been right - this forum is really the best. Not just one question has got multiple answers and solutions, it's grown into some kind of philosophical discussion.
We have a secret in how this works, we only allow human beings as members (and a few martians). :green2