IDE doesn't handle 'CompilerError' correctly

Working on new editor enhancements?
AND51
Addict
Addict
Posts: 1040
Joined: Sun Oct 15, 2006 8:56 pm
Location: Germany
Contact:

IDE doesn't handle 'CompilerError' correctly

Post by AND51 »

Hello!

If there is a CompilerError to be executed, the IDE correctly gives the error message. It also jumps to the specified line.

But it doesn't color the CompilerError-line. Insted, it even keeps the older error colored! So the color handling is broken.
Moreover, the IDE jumps to the CompilerError-Line, but why the hell to you scroll the mistaken line at the very top of the editor area?
Normal errors will be scrolled so that you can see the code lines above the error line before you confirm the requester. Please, make CompilerError behave the same way.

Do you understand, what I mean?
Finally have a look at the screenshot:

Image
Did you understand what I meant?
PB 4.30

Code: Select all

onErrorGoto(?Fred)
freak
PureBasic Team
PureBasic Team
Posts: 5941
Joined: Fri Apr 25, 2003 5:21 pm
Location: Germany

Re: IDE doesn't handle 'CompilerError' correctly

Post by freak »

> But it doesn't color the CompilerError-line. Insted, it even keeps the
> older error colored! So the color handling is broken.

CompilerError creates a compile-time error, similar to a syntax error in the code.
The line coloring is a feature of the debugger. It is done for run-time errors. (like division by zero)

The compilation stops on the first compile-time error, so it is enough to just
select the line and show it. Runtime-errors can happen more than once if
you continue the execution after the error (only possible for non-critical errors)
Thats why run-time errors get a mark.

Btw, if you want the marks to be cleaned on new compilations, this can be set
in the debugger preferences somewhere.

> Moreover, the IDE jumps to the CompilerError-Line, but why the
> hell to you scroll the mistaken line at the very top of the editor area?
> Normal errors will be scrolled so that you can see the code lines above
> the error line before you confirm the requester. Please, make
> CompilerError behave the same way.

I don't understand really. The scrolling behavior is the same as for any other
error that is received from the compiler. "CompilerError" is not treated differently.

btw, about your screenshot:
You cannot use CompilerError in this way. The error will fire whenever the
given line is compiled, not executed. So the If around it does not prevent
the CompilerError from taking effect. Only statements like CompilerIf can prevent that.

You cannot do runtime-checks with this command.
quidquid Latine dictum sit altum videtur
AND51
Addict
Addict
Posts: 1040
Joined: Sun Oct 15, 2006 8:56 pm
Location: Germany
Contact:

Post by AND51 »

Thank you for the explanation.
I didn't know that the red marks are 'reserved' for run-time errors only. Yes, I knew that you can turn off the red marks in the preferences.

> I don't understand really.
Then I try it in german again:
Ich habe das Scrollverhalten nach einem (Compiler-/Laufzeit-) gerade nocheinmal getestet. Dabei fiel mir folgendes auf: Liegt die fehlerhafte Zeile über dem sichtbaren Bereich des Editorgadgets, scrollt der Editor nur so viel hoch, dass die erste sichtbare Zeile die fehlerhafte ist.
Genau das gleiche umgekehrt: Liegt die fehlerhafte Zeile unter dem Sichtbaren Codebereich, scrollt der Editor nur so weit runter, dass die fehlerafte Zeile gerade sichtbar ist.

Es wäre besser, wenn so gescrollt werden würde, dass die fehlerhafte genau in der Mitte des Editorgadgets ist, damit man auf einem Blick den vorigen wie auch den nachfolgenden Code sehen kann. Man muss immer selebr scrollen.
PB 4.30

Code: Select all

onErrorGoto(?Fred)
#NULL
Addict
Addict
Posts: 1499
Joined: Thu Aug 30, 2007 11:54 pm
Location: right here

Post by #NULL »

Es wäre besser, wenn so gescrollt werden würde, dass die fehlerhafte genau in der Mitte des Editorgadgets ist, damit man auf einem Blick den vorigen wie auch den nachfolgenden Code sehen kann.
yes, i would like that too (scrolling the line to the middle of the editor-gadget, for errors as well as for things like the 'find'/search function). i would find that more intuitive.
Post Reply