I have noticed several differences between the QEditor in MASM32v8 and the ones in previous versions of MASM32. Most of them I like.

One of them is giving me fits though.

If I'm workink on a large source file and I press <ENTER> twice in a row, everything works normally until I reach line #1287. Starting with line #1288, I get a normal line feed with the first one but the second one puts the line feed at the very end of the text and the cursor is positionned there (at the very end of the text).

That behavior continues like described until I get to line # 2795 or so. At that point, I also get a normal line feed with the first one but the second one puts the line feed somewhere in the upper portion of the text, often in the middle of a line and even erasing some of the existing text!!!! I then have to undo that last one and find where I was originally. If I try to include another <ENTER> where I was trying to put the second one, it puts it again somewhere else as before.

Any explanation??? or remedy (apart from avoiding 2 consecutive <ENTER> or keeping my source files less than 1300 lines)???

Posted on 2003-02-25 14:17:03 by Raymond
Analyzing the problem in more detail, it is not related to line number but to byte location within the file.

The problem doesn't occur within the first 8000h bytes of the file. Between 8000h and 10000h, the second consecutive <ENTER> goes to the end of the file (along with the cursor). Past address 10000h, the second consecutive <ENTER> is applied at the begining of the file at the address of the LOW WORD portion of the actual address (with some loss of data).

I have not checked if turning off the auto-indent has any effect.

Posted on 2003-02-28 12:03:18 by Raymond
i dont like the "fetures" ind Version 8 too.
I think, thats steps backwards.
The paste-fetaure for example, wich only work, if you first hit shift and than ENF.
Or, if you hit enter, at the end of a codeline, and be ahead the ASCII(13) the whole codeline will deletet.
Posted on 2003-02-28 14:27:32 by Forginforcer
Hi Hutch&everybody

Script capabilities are great, right click too,... :alright:

I experiment sthg that puzzles me, under Win95B : if you hit a '\' then Qeditor interprets it a a block instruction.
Does anyone have the same trouble, or should I update a Win DLL ?! Masm32v7 does not do it. If anybody could make an "include c:\myfile" to test it, please...

The new behavior of cut/copy/paste is not optimal. It eats EOL (CR or LF or both), which is annoying.

Thanks, bye
Posted on 2003-03-13 05:52:01 by valy
I have just checked the effect of turning OFF the auto-indent and the reported problem went away. :)

While still with the same document, I turned the auto-indent back ON and the problem came back.:mad:

Posted on 2003-03-15 23:15:52 by Raymond

That gives me something to work on, what version of Windows are you running, I have access at win95b, win98se and win2k sp2 and I would like to try and duplicate the effect if I can.


Posted on 2003-03-16 02:54:23 by hutch--
I'm presently working with Win98se.

Posted on 2003-03-16 09:35:23 by Raymond
Just ran a few more tests on a larger file (with the auto-indent ON). In all cases, the second <ENTER> is inserted as if only the sign-extended LOW WORD of the dword address is used by the "indent" procedure.

Tests on the same file with the QEDITORs of previous versions gave the same results. However, I don't know if those versions (located in directories other than the main masm32 one) refer to routines in the latest version.

Posted on 2003-03-16 11:50:19 by Raymond

for the life of me I cannot duplicate the problem, I just opened windows.inc which is a bit over 27 thousand lines and it behaves normally at any line from the starting point you mentioned to the last line. Double ENTER produced only the normal 2 CRLFs that it is supposed to do.

I tested it on both the win98se that I develop on and win2k that I keep on the same box for testing.

I recoded QE from scratch for this current version to get around the problem of a message I used having been slightly changed which effected the autoindent and a few other functions and I made sure I used rich edit specific 32 bit functions to make sure that there were no old 16 bit functions that could produce the problem that showed up before.

The version of riched32.dll in my win98se is 188416 bytes long and dated 4/23/99. Win2k uses a 3.8k stub for riched32.dll and calls riched20.dll to emulate the functionality.

The autoindent in QE reads the content of the current line BEFORE it processes the CRLF to get the indent info, then it sets the new line with the indent from the last line so that the next text typed starts at the indent of the last line.

If you press enter the second time and the line before it is empty, it strips the leading blanks from the line before it adds the next CRLF pair.

I don't know what to do with the problem as I just cannot reproduce it.


Posted on 2003-03-17 07:19:58 by hutch--
Thanks to Hutch for all his excellent support, the problem has now been identified and resolved.:alright:

For others who may have experienced the reported problem on their system with files larger than 32K, the next incremental version of QEditor will have been corrected for it.

Posted on 2003-03-23 12:05:56 by Raymond
Raymond, please post what your solution was... updating the Win98SE Rich Ed. dll's?

(just to make this thread complete... thanks!) ;)
Posted on 2003-03-23 21:29:03 by BluesRenegade

The solution was simply a modification of a single line of the QEditor source code by Hutch. As I mentioned, the next incremental version of QEditor will have that correction included.

It still remains a mystery why Hutch could not reproduce the problem on his system; we seem to be using the same version of the riched32.dll.

Have YOU (or anyone else) encountered the described problem on files larger than 32 Kb? Or am I the only one silly enough to have such large source files?:rolleyes:

Posted on 2003-03-23 21:52:50 by Raymond
I would like to thank Ray for all of the work he has done in tracking down a problem that I could not reproduce on any of my 3 machines on different windows versions. Ray has tested the last version where a function call through Sendmessage() was changed to a later version that was fully 32 bit and on rays machine it is now working correctly.

I am still waiting for conformation from another member about the problem that Will reported where the intrinsic key combinations for clipbnoard in the rich edit control were laggy and slow. What I have done is rewrite the key processing to throw away the default processing and I have trapped them directly on the WM_KEYDOWN message in the message loop.

It is working fine on my 3 different boxes with 3 different OS versions but I don't know yet if it tests OK on other machines.

I have attached the current binary for QE but it still may need to be modified if it is not working correctly on all versions.


Posted on 2003-03-24 01:06:47 by hutch--
I would like to know where to find plugins for QEditor?
Posted on 2003-03-27 07:40:33 by chik