A few more editor bugs

Since the forum has been quiet for 3 weeks, let me post a few nit-picks concerning the Version 6 editor.

1) Highlighting--sometimes doesn't go away when one moves the cursor and clicks.

2) Cursor sometimes goes bye-bye for a while--then seems to reappear. Probably just goes off screen but comes back somewhere I'm not looking.

3) Printing--when printing a highlighted section the dialog box that goes with the printing utility does not necessarily stay on top until closed. If the editor screen covers it, it will seem that the editor is 'hung'. Ran into this one today--ended up closing the editor to find the print dialog box waiting for an 'exit'.

4) Our old friend *.free can still pop up and not just when the editor starts with no default file to open. It does come up if you have closed all your working files before exiting the editor, but I also find that during a long editing session with many 'runs', the working file can still get renamed *.free. One can do a save-as on the current file and give it back the correct name, but if you don't, work can be lost.

5) There is still an occasional crash with internally generated errors (previously documented) which I think occur if both mouse buttons are pushed at the same time.

6) The editor seems to often leave processes running even after one has closed the editor session that can prevent Windows from shutting down. An example seems to be FIND which exists as a separate window, but does not necessarily close when you close the editor.

More generally PRINTING from within a program seems to still be a hit/miss problem. The same program will sometimes print just fine and at other times will crash when printing is accessed. I know this is imbedded in the language code, not the editor, but is still very frustrating.

Overall (other than the above printing bug), I find the editor itself is working pretty well, but I think it might be worthwhile if others would list any other anomalies still found.




Hi Dave,

Thanks for your comments about various bugs.

At various points in the editor code there are traps to check whether any filenames are called *free, so we ought not to get this any more. Obviously it is not working prperly but nobody including me can nail down when this happens.

The cursor disappearing and coming back is a new one to me. The editor cursor is a graphic creation - not part of Windows or TB. Maybe it needs to be refreshed more often. Likewise, highlighting is a graphic creation and is not native to Windows or TB. It both cases the cursor and highlighting are created from scratch and tend to be slower that native versions, because each has to calculate where it is supposed to be on the screen.

I will look into the problem of dialog box windows being left open at shut down. It should be easy enough to close them all.

Personally I have never had printing problems - probably because I use an Epson printer. If you are using an HP printer then you won't be the first to recognize that it is a hit and miss affair. For this reason the Editor now uses a third party printing program (PRfile32.exe). If you have written a program that attempts to print anything, then your best bet is to chain to this freeware program and let it do the job.

In the case of ColorText, I assume you are using one of the two built-in color schemes. Literal Quotes are supposed to be colored cyan (and string variables are the same color). Punctuation marks (including quotes) are supposed to be black. For the moment I can't see why the text between quote marks is not visible (or has been redefined as white which would make it invisible).

Thanks again for all your observations


Colour text

Can also add that with colour text on when you type anything inside quotes it becomes invisible after the first quote and then visible again after the string is closed by the second quote.



Hi Dave,

I have nailed the problem with invisible text between quote marks.
The way ColorText works is to take a line of code and split it into 3 parts: a line number (if any), the body text and a comment (if any).

The body text is then split into an array of field$(n)defined by spaces or punctuation marks. The field$ are then subjected to scrutiny to determine what function they perform and what color they should be.

In the case of literal strings inside quotes, the Colortext routine picked up the first quote mark but it wasn't until it encountered the second quote mark that it worked out what went in between - hence the invisible text until the second quote appeared.

I have now corrected this (for version 6.008) so that all the text following the first quotemark gets printed properly.

You also mentioned the problem of residual windows such as FIND and REPLACE were being left behind when you closed a window. This too has now been corrected, so you should no longer have invisible windows running in the background when you shut down.

I am still working on the other issues, including reducing CPU usage. There is a problem here. The TextEdit control in the True Ctrl library has a number of issues, so I had to re-create the TextEdit control from scratch, which included created a cursor and creating a similated outlining method for selected text. I also had to invent a method of hovering over toolbar icons to reveal the name of the icon. In all these case a "delay" after a mouse click is required -usually about 0.3 secs. This puts a limitation on what I can do with any delays included in TC_event. I'll keep you posted on my progress.