QE Version l Update

[hutch--]

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.

[felipe]

Thanks hutch, but why this version doesn't have all the menu options (tabs) as the other ones? 

[hutch--]

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.

[felipe]

Your right, nice! thanks. 

[sinsi]

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.

[hutch--]

It happened with Win10, not before and I have never found a way around it.

[jj2007]

Right now I have no Win10, but I will check if RichMasm has that problem. Workaround is catching the message to change the selection.

[TimoVJL]

richedit just don't have that additional Windows 10 feature ?

[hutch--]

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.

[TimoVJL]

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 ?

[hutch--]

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.

[sinsi]

I thought the double click was built in to the richedit (ECO_AUTOWORDSELECTION).

[jj2007]

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.

[hutch--]

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.

[hutch--]

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 ?