I have put the fixed version in a separate post and left this topic so that posting made by members are still available. I have removed the test versions to avoid confusion about which version to use.
Thanks hutch, but why this version doesn't have all the menu options (tabs) as the other ones? :icon_idea:
Hi felipe,
It is supposed to replace the earlier one where all of the accessories are present. If you run it in a directory by itself, the accessories are not present.
Your right, nice! thanks. :thup:
A small annoyance that I never found before, selecting a word by double-clicking it works, but
if the word is at the start of a line it also selects two characters from the line(s) above, including cr/lf.
It happened with Win10, not before and I have never found a way around it.
Right now I have no Win10, but I will check if RichMasm has that problem. Workaround is catching the message to change the selection.
richedit just don't have that additional Windows 10 feature ?
What I did was start from the caret position and scan backwards to find the start of the word, then scan forward to find the end of the word. The design was done on XP, it worked correctly on Win7 64 but Win 10 has changed a number of things in RichEd 3 that slightly messed it up. What I do at the moment is to start code at least one space in.
In the 64 bit editor that I may finish one day, its does not happen as I designed it from scratch. With QE the problems follow from having to do all sorts of bug fixes in riched3 that have never been fixed in the DLL.
OK.
so richedit in RTF mode don't have that feature, and as jj use that mode, and also don't use that OS riched20.dll by default.
or i missed something ?
To make things even more complicated, riched 3 has multiple modes for both plain text and RTF and depending on which mode you use, each has its own problems.
The character scan I do is from a 256 character table and with the original design it would only scan in either direction within the character range in the table. Specifically the ASCII 13 used in riched as the line feed delimiter is in the unacceptable character range as is the unused ASCII 10 but it still back scans to the last ASCII 13 and this is an override that started in Win10.
I thought the double click was built in to the richedit (ECO_AUTOWORDSELECTION).
Just tested it with Win10, and found this:
- Qeditor sometimes extends the selection until the CrLf above
- in the attached examples, tproc.txt had this bug sometimes, intro.txt too (both attached)
- RichMasm is not affected (it uses the default mechanism)
- Win7 is not affected
- in addition, and only in Win10, if you select a word in qEditor and hit cursor left immediately after, instead of deselecting the word, qEditor inserts a new line.
I think what is happening is when you double click on the word, it performs an action BEFORE the code I have to control it runs. QE was written under XP where it worked exactly as it was designed, Win7 64 was OK but Win 10 64 has some overrides with the double click that I have yet to work out how to cancel. My own work around is to set text at least one character space from the left edge.
This morning's piece of genius was to add a 100 ms delay so that the Microsoft over-ride was overwritten by the original code. So far it is solving the problem of the Microsoft over-ride selecting the CR as well as the word that is directly on the left margin.
Could I impose on you to test this for me to see if it works OK ?
Almost, now it only picks up the preceding crlf.
Actually, it's worse now. With the tproc.txt attached earlier, it selects now CrLf plus two chars in the line above. But it works correctly with intro.txt (both on Win10). And sometimes everything works, sometimes not. Weird :sad:
I think that you should be able to set that by sending an EM_SETOPTIONS message with ECO_AUTOWORDSELECTION, as mentioned above. If you are already doing that, I apologize. :eusa_hand:
This should work from Windows 95 onwards, although online help says it requires Windows Vista and above :skrewy:.
Thanks for that, I will give it a blast.
Just added the code,
; **********************************************************************
invoke SendMessage,hEdit,EM_SETOPTIONS,ECOOP_OR,ECO_AUTOWORDSELECTION
; **********************************************************************
On the files that showed the incorrect select with a word at the left margin, it seems to work correctly. I removed the 100 ms lag as it did not do the job consistently.
I tried the ECOOP_XOR option but it made it worse.
Mutter, this is a flop as well. Weird effect, I can copy the contents of a file that shows the defect to another editor instance and it does not do it.
Quote from: hutch-- on July 28, 2019, 02:07:51 AM
Mutter, this is a flop as well. Weird effect, I can copy the contents of a file that shows the defect to another editor instance and it does not do it.
I made a quick test in C and it appears that you don't need to do anything at all because the default behavior is exactly to select a word when you double-click inside it. I forced plain text by sending EM_SETTEXTMODE with TM_PLAINTEXT to make sure there are no different behaviors between rich text and plain text.
Incidentally a very old QEDIT from 2000 I have here from an ancient distribution, which uses riched32.dll, works fine.
I am getting very unusual results, just opening file after file, some show the selection error, others do not. I have EM_SETTEXTMODE and TM_PLAINTEXT set. I need a different method than the default as I use a table that specifies what characters are allowed, mainly ".", "_" and "$" which I lose with the default. It has only happened in win 10 64 bit and selection is different and slower.
Shrug, I will see if I can find a work around, the internal code works directly off the 256 characters table and I know the problem is not there as the ASCII 13 that riched uses as a line feed is set to zero in the table.
I understand what you are looking for. a problem similar to this:
https://stackoverflow.com/questions/51438312/rules-for-selecting-a-word-in-a-windows-richedit20w-control
Looking at Qedit with a Windows Message viewer it does not appear, or it escaped me, that you are using EM_SETWORDBREAKPROC (and then EditWordBreakProc) as mentioned in the notes by Alessandro Jacopson, may be you want to try that route.
After exhausting anything like reference material, this is the most successful so far.
; ........
sub ecx, 1
sub mn, ecx
mov eax, mn
mov cr.cpMin, eax
mov cr.cpMax, eax
add cr.cpMax, edx
; |||||||||||||||||||||||||||||||||||||||||||
; zero the selection to the end cpMax value
; |||||||||||||||||||||||||||||||||||||||||||
add eax, edx
mov cn.cpMin, eax
mov cn.cpMax, eax
invoke SendMessage,edit,EM_EXSETSEL,0,ADDR cn
; |||||||||||||||||||||||||||||||||||||||||||
invoke SendMessage,edit,EM_HIDESELECTION,0,0
invoke SendMessage,edit,EM_EXSETSEL,0,ADDR cr ; set to correct selection
; ........
I think I have this problem knackered, I just need a few days of using it to test if it beats the Microsoft over-ride.
Quote from: AW on July 28, 2019, 05:11:55 AM
I understand what you are looking for. a problem similar to this:
https://stackoverflow.com/questions/51438312/rules-for-selecting-a-word-in-a-windows-richedit20w-control
Looking at Qedit with a Windows Message viewer it does not appear, or it escaped me, that you are using EM_SETWORDBREAKPROC (and then EditWordBreakProc) as mentioned in the notes by Alessandro Jacopson, may be you want to try that route.
Thanks for that link (https://github.com/petterh/textedit/blob/v2.5.1003.0/CharClasses.h).
a simplified C version for testing:
int CharClasses[256] = {
0, 0, 0, 0, 0, 0, 0, 0, 0,19,20,20,20,20, 0, 0, // 0- 15
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 16- 31
50, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,65, 1, 1, // 32- 47
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, // 48- 63
1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 64- 79
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, // 80- 95
1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 96-111
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0, // 112-127
0, 0, 1, 0, 1, 1, 1, 1, 0, 1, 0, 1, 0, 0, 0, 0, // 128-143
0, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0, // 144-159
18, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, // 160-175
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, // 176-191
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 192-207
0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, // 208-223
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, // 224-239
0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0 // 240-255
};
int MoveWordLeft(LPWSTR lpch, int ichCurrent, int cch)
{
while (ichCurrent > 0 && !CharClasses[*(lpch + ichCurrent - 1)])
ichCurrent--;
return ichCurrent;
}
int MoveWordRight(LPWSTR lpch, int ichCurrent, int cch)
{
while (ichCurrent < cch && !CharClasses[*(lpch + ichCurrent)])
ichCurrent++;
return ichCurrent;
}
int EditWordBreakProc(LPWSTR lpch, int ichCurrent, int cch, int code)
{
switch ( code ) {
case WB_LEFT:
case WB_MOVEWORDLEFT:
case WB_LEFTBREAK:
return MoveWordLeft(lpch, ichCurrent, cch);
case WB_RIGHT:
case WB_MOVEWORDRIGHT:
case WB_RIGHTBREAK:
return MoveWordRight(lpch, ichCurrent, cch);
}
return 0;
}floats still needs a special handling :undecided:
EDIT: a simple version:
int EditWordBreakProc(LPWSTR lpch, int ichCurrent, int cch, int code)
{
switch ( code ) {
case WB_LEFT:
case WB_MOVEWORDLEFT:
case WB_LEFTBREAK:
for (;ichCurrent > 0 && !CharClasses[*(lpch + ichCurrent - 1)]; ichCurrent--);
return ichCurrent;
case WB_RIGHT:
case WB_MOVEWORDRIGHT:
case WB_RIGHTBREAK:
for (;ichCurrent < cch && !CharClasses[*(lpch + ichCurrent)]; ichCurrent++);
return ichCurrent;
}
return 0;
}
for asm
CharClasses dw 0, 0, 0, 0, 0, 0, 0, 0, 0,19,20,20,20,20, 0, 0 ; 0- 15
dw 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ; 16- 31
dw 50, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,65, 1, 1 ; 32- 47
dw 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1 ; 48- 63
dw 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ; 64- 79
dw 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0 ; 80- 95
dw 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ; 96-111
dw 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 0 ; 112-127
dw 0, 0, 1, 0, 1, 1, 1, 1, 0, 1, 0, 1, 0, 0, 0, 0 ; 128-143
dw 0, 1, 1, 1, 1, 1, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0 ; 144-159
dw 18, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 ; 160-175
dw 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 ; 176-191
dw 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ; 192-207
dw 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0 ; 208-223
dw 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ; 224-239
dw 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0 ; 240-255