Hutch,
I found a small bug in QEditor today. It's in the code for the 'Check Menus' button in the 'Change Settings' window.

Apparently it was written for an older syntax which only allowed lines that defined menu entries, as it now keeps reporting errors for each line that doesn't contain a 'comma' character. I didn't count, but I had to click 'OK' a large number of times before that error popup would go away for good, as the current settings contain lots of proper lines without commas. (Such as comment lines and menu separators I mean.)

It's not harmful in any way, which is why I call it a small bug, but it still needs to be fixed to make the 'Check Menus' button useful.

PS: I just realized that the bug isn't in the main QEditor program but in SetIni.exe which handles that window. If you use similar stuff for other projects than QEditor, then you may need to check this for those projects as well
DS.
Posted on 2002-05-26 18:20:29 by RAdlanor
RAdlanor,

I have left this checker with the "nuerotic" settings so that it tests the existence of files. In situations where there is no file to find or one that depends on a file being loaded in the editor first, it will report no file found which should not be a problem as there is no file there.

Regards & Thanks,

hutch@movsd.com
Posted on 2002-05-27 02:20:12 by hutch--
Hutch,
I have no problem with that at all, but real newbies might.

I myself am a newbie with MASM32 and in fact with any asm on modern x86 CPUs, but not with macro assembly as such, or other programming. I've worked with both since the late 70's, so I find it no real problem to adapt to new environments.

However, there seems to be a misunderstanding about which error message I reported on, so let me clarify that.

I never saw the one you mention, as it won't appear for lines that don't contain the comma sign that should precede the pathname for each menu command defined. My lines for those menu commands were edited to correct full pathnames, so those lines didn't generate any errors.

The lines that generated my error messages were the ones not intended to define any menu commands. such as comment lines and menu separator lines. I thought it would be very easy to eliminate those incorrect error messages, as you only need to check the first character of each line to see what it is for.
';' => Comment (no further test)
'-' => Menu separator (no further test)
cr => Empty line (no further test)
Anything else => menu command (with file test)

Whatever... Since I don't consider the 'Check Menus' feature necessary it doesn't matter to me. The ones who really need it are those who feel unsure of how your menu system works.
Posted on 2002-05-27 03:44:53 by RAdlanor
Ronald,

I certainly appreciate you effort in reporting these problems but I cannot duplicate this one on win95b that I wrote it on. When I run the option to test the menus, the only things I get are the entries that do not have complete paths and the ones that depend on the file name in the editor.

In particular, the menu seperators and comment lines do not show up. I leave the capacity there to test stuff like files that may have been deleted or moved so that there is a way of testing dead entries in the INI file.

I wonder if it is just different windows version and particularly different language versions of windows ?

Rergards,

hutch@movsd.com
Posted on 2002-05-27 20:07:09 by hutch--
Hutch,
I don't see why the Windows version would affect the tests that SetIni.Exe makes to test the syntax of those lines. After all, such simple string testing shouldn't involve any calls to Windows functions. Or do they ?

If such calls are made, then that is a likely source of the problems as I am using WinXP Pro, with all 'Windows Update" fixes. A lot has happened since Win95 and even a small incompatibility in a single function can cause the tests to fail.

However, if that is the case then it's easy to fix by testing the strings with direct asm code instead. Like I said in my previous post, the tests needed are very simple. Doing them without any system calls is probably more efficient anyway.

Hmmm, I just thought of something that needs to be tested...

--- Some tests later ---
I have now isolated a real cause of the errors. The QEDITOR.INI file in the distribution package MASM32v7 contains a large number of empty lines. Some of these seem intended to make the file more readable, but a large number of meaningless ones are tacked on after the end of the section.

Removing the lines at the end reduced the spurious error messages significantly, but not completely. Removing the empty lines used to separate text, both at each section border and inside a few sections, finally eliminated ALL errors. Strangely enough this included the error report that 'makeit.bat' is missing, which is NOT a spurious report but a correct one since there is no such file in the directory I had open. But perhaps you have 'special-cased' that file to avoid misleading results ?

Anyway, it is now clear that the empty lines are responsible, though I still don't see why results differ for your system and mine. One possibility is if you're using a Windows function to filter out 'whitespace' characters. Win95 may (incorrectly) regard CRLFs as whitespace, while WinXP (correctly) might not.
('Correctly' because CRLF is a terminator, unlike spaces or tab.)

Whatever, two simple options exist for fixing it.
1: Make all string testing and filtering with local code
2: Forbid empty lines in the INI (drastic, but certain)

Either way, it's important to fix this for the release package. New users who see that the editor has a selftest function will not gain confidence in it when it gives hordes of spurious error messages.

This may be one reason why others in this Forum have expressed surprise that I'm using QEditor... To me it seems like an excellent tool, however, even if a few bugs seem to remain (and perhaps that's only in WinXP).

PS: If you do use Windows functions to filter/search/edit strings then that may also explain the different results we get with the autoindent removal of QEditor, discussed in another thread.
DS.

PPS: I almost forgot to add that I'm using a US version of WinXP, mainly because translations are usually both weird and inconsistent in their terminology. In fact I have the swedish release of the same WinXP Pro version too, but I chose to install the US original instead. The only things that differ from a standard US installation are that I use a Swedish keyboard and that the date/time notation selected is the Swedish standard.
DS.
Posted on 2002-05-28 11:55:30 by RAdlanor
Hutch,
I said that I didn't get an expected error message, for makeit.bat, after I had eliminated the spurious messages. I must have been mistaken about which directory was 'current' at the time, for when I tried it again just now I do get that message. Please disregard that part (only) of the previous post.
Posted on 2002-05-28 17:28:23 by RAdlanor
RAdlanor,

What I do is retrieve the line using EM_GETLINE from index 0 onwards,

remove any trailing CRLF (13,10) from it,
test for matching square brackets, set error if unmatched,
test for leading ";", jump over evaluation if so,
test for single "-", jump over evaluation if so,
test for missing comma ",", set error if missing,

Continue looping until EM_GETLINE returns zero indicating that the last
line has been passed, displaying the error message if the error flag
is set on any iteration of the loop.

This problem may occur with XP being non standard in the way the rich
edit control behaves but it is done according to the documentation for
win95 upwards for a richedit 1 control.

I don't and won't use XP because of many other problems so I don't have
a solution to the problems you have reported. Its not the first time
Microsoft have changed the rules so I am not surprised.

Regards,

hutch@movsd.com
Posted on 2002-05-29 03:06:29 by hutch--
I'm not sure if it's a bug but I realised that under certain circumstances (I'm not quite sure about the details). The Cursor in QEdit jumps to the end of the file every time I press "h".

This is very annoying. Does anyone else knows this "feature"?
Posted on 2002-05-29 11:45:51 by Compuholic
A couple more weird things...

Sometimes the editing part of the editor starts shifting left and right as I type. The text in the whole editor portion just shifts left-right-left-right, really weird, I dunno why but it seems to have something (a little) to do with a low-memory condition... Win98

Sometimes portions written within <> disappear including the angle brackets. Seems as if strip HTML is getting called without something telling it to.
Posted on 2002-05-29 21:16:22 by AmkG
hmmmm,

I though I had removed that problem, it seems to happen if the hotkey gets out of synch and pressing "h" by itself used to run the function to strip HTML and the tags.

Just check if you have version 2.8 of QE. I forget which version was the first I fixed.

RAdlanor,

I may have found the problem that you have reported with XP and it is to do with the message EM_GETLINE. In the old documentation, it makes reference to the forst WORD having a number in it when the function returns. This never worked on win95/98/NT so I always read directly from the beginning of the buffer. What may have happened is that the message in XP DOES in fact write to the first WORD before the text is retrieved. This would account for the problem you reported where the line is not being read correctly.

It would be easy to fix but it then would not run on any of the older versions so when I get time, I will recode that portion to read the lines in a different way so that this message is not used any longer.

Thanks for finding this problem.

hutc@movsd.com
Posted on 2002-05-30 02:28:15 by hutch--
Oh, that could be the reason. I'm using QEdit 2.4

I'll download the newer one, thanks.

@AmkG: I also realized this behavior.
<Joke>A misunderstanding of shl and shr</Joke> :-)
Posted on 2002-05-30 04:14:16 by Compuholic