The MASM Forum

Projects => MASM32 => Topic started by: hutch-- on July 12, 2019, 12:57:18 PM

Title: QE Version l Update
Post by: hutch-- on July 12, 2019, 12:57:18 PM
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.
Title: Re: QE Version l Update
Post by: felipe on July 13, 2019, 05:04:58 AM
Thanks hutch, but why this version doesn't have all the menu options (tabs) as the other ones?  :icon_idea:
Title: Re: QE Version l Update
Post by: hutch-- on July 13, 2019, 05:18:56 AM
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.
Title: Re: QE Version l Update
Post by: felipe on July 15, 2019, 03:00:43 AM
Your right, nice! thanks.  :thup:
Title: Re: QE Version l Update
Post by: sinsi on July 26, 2019, 09:30:37 PM
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.
Title: Re: QE Version l Update
Post by: hutch-- on July 26, 2019, 09:43:39 PM
It happened with Win10, not before and I have never found a way around it.
Title: Re: QE Version l Update
Post by: jj2007 on July 26, 2019, 11:18:51 PM
Right now I have no Win10, but I will check if RichMasm has that problem. Workaround is catching the message to change the selection.
Title: Re: QE Version l Update
Post by: TimoVJL on July 27, 2019, 12:03:39 AM
richedit just don't have that additional Windows 10 feature ?
Title: Re: QE Version l Update
Post by: hutch-- on July 27, 2019, 12:12:24 AM
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.
Title: Re: QE Version l Update
Post by: TimoVJL on July 27, 2019, 12:29:52 AM
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 ?


Title: Re: QE Version l Update
Post by: hutch-- on July 27, 2019, 01:00:59 AM
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.
Title: Re: QE Version l Update
Post by: sinsi on July 27, 2019, 01:48:53 AM
I thought the double click was built in to the richedit (ECO_AUTOWORDSELECTION).
Title: Re: QE Version l Update
Post by: jj2007 on July 27, 2019, 03:51:50 AM
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.

Title: Re: QE Version l Update
Post by: hutch-- on July 27, 2019, 04:39:47 AM
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.
Title: Re: QE Version l Update
Post by: hutch-- on July 27, 2019, 11:46:05 AM
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 ?
Title: Re: QE Version l Update
Post by: sinsi on July 27, 2019, 03:12:03 PM
Almost, now it only picks up the preceding crlf.
Title: Re: QE Version l Update
Post by: jj2007 on July 27, 2019, 06:32:31 PM
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:
Title: Re: QE Version l Update
Post by: aw27 on July 27, 2019, 08:58:57 PM
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:.
Title: Re: QE Version l Update
Post by: hutch-- on July 28, 2019, 12:53:03 AM
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.
Title: Re: QE Version l Update
Post by: 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.
Title: Re: QE Version l Update
Post by: aw27 on July 28, 2019, 02:27:15 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.
Title: Re: QE Version l Update
Post by: hutch-- on July 28, 2019, 03:04:59 AM
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.
Title: Re: QE Version l Update
Post by: aw27 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.
Title: Re: QE Version l Update
Post by: hutch-- on July 28, 2019, 07:49:42 AM
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

  ; ........
Title: Re: QE Version l Update
Post by: hutch-- on July 28, 2019, 03:42:41 PM
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.
Title: Re: QE Version l Update
Post by: TimoVJL on July 28, 2019, 07:54:10 PM
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:
Code: [Select]
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:
Code: [Select]
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
Code: [Select]
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