XProfan

- Page 5 -

Nico
Madysa

Auch nur ein Grafik-Fehler:
1.) Ich öffne einen Code
2.) Ich mache einen neuen und schreibe was rein
3.) sichere den neuen Code
4.) Führe den neuen Code aus und beende ihn wieder
5.) Im Fenster wird plötzlich der alte Code Stück per Stück angezeigt,
also nur in jeder Zeile, auf die ich dann klicke. Sieht eher unschön aus.

P.S.: Ist das jetzt Hohn von euch, dass ihr wend zu den veralteten Befehlen schiebt, let aber nicht?

Nico Madysa

[quote:27b2bcb3b4=Nico Madysa]P.S.: Ist das jetzt Hohn von euch, dass ihr wend zu den veralteten Befehlen schiebt, let aber nicht?

[/quote:27b2bcb3b4]
Let hat Bestandsschutz!

Jörg
Sellmeyer

Vielleicht nicht direkt ein Bug aber trotzdem:

Bei sehr langen Zeilen reicht irgendwann der horizontale Scrollbalken nicht mehr. Da XProfan10 Zeilen von 32000 verarbeiten kann sollten einige Hundert auch im Editor darstellbar sein, oder?
Mit iFs Code ([...]

) kann man das gut testen.

Saluto
Jörg

Windows XP SP2 XProfan X4
... und hier mal was ganz anderes als Profan ...

RGH

[quote:e4dd5f20f3=Nico Madysa]P.S.: Ist das jetzt Hohn von euch, dass ihr wend zu den veralteten Befehlen schiebt, let aber nicht?

[/quote:e4dd5f20f3]
Wieso sollte LET veraltet sein? Man kann den Befehl zwar weglassen, aber intern steht er dann doch da. Der integrierte Präcompiler, der bis auf die Operator-Funktionen schon jetzt die alte Syntax in die neue Syntax übersetzt, baut beim Compileren den LET-Befehl vor jeder Zuweisung ein.

Apropos integrierter Präcompiler: Auch im Interpreter wird die alte Syntax, mit Ausnahme der Operatorfunktionen, beim Einlesen automatisch in die neue übersetzt. Wundert Euch also nicht, wenn die Fehlermeldung in der Zeile die neue Syntax zeigt, während im Quellcode noch die alte steht!

Saluto
Roland

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Nico
Madysa

Nach dieser Logik kann wend aber auch drinbleiben und intern in EndWhile umgewandelt werden.

PS: Mir ist noch ein Bug bei den Hexadezimalen Zahlen aufgefallen.
Kommt nach dem Dollar ein Buchstabe (A, B, C, D, E oder F) dann kann dahinter ohne Anmeckerung des Editors jeder andere Buchstabe geschrieben werden, solange keine Zahlen folgen. Einfach testen:
Kompilieren Markieren Separieren

Def %Bemaengelung1 $0FFFGGG
Def %Bemaengelung2 $FFFGG2GG
Def %Bug $ABCEFGHIJKLMONPre>

Nico Madysa

Nicht Bug! Ich musste dafür sorgen das möglicherweise auch Systemvariablen erkannt werden - das hast Du wohl übersehen

Nico
Madysa

Ich habe es schon gelesen, aber habe im Moment der Entdeckung nicht dran gedacht.

OK, ich glaube, ich kriegs hin, hexadezimale Zahlen richtig zu schreiben.

Nico Madysa

RGH

[quote:5baa87b76d=Nico Madysa]Nach dieser Logik kann wend aber auch drinbleiben und intern in EndWhile umgewandelt werden.

[/quote:5baa87b76d]
Oh, das mache ich schon seit etlichen Versionen so! Die Runtime kennt schon seit Ewigkeiten kein Wend mehr!

[quote:5baa87b76d]PS: Mir ist noch ein Bug bei den Hexadezimalen Zahlen aufgefallen.
Kommt nach dem Dollar ein Buchstabe (A, B, C, D, E oder F) dann kann dahinter ohne Anmeckerung des Editors jeder andere Buchstabe geschrieben werden, solange keine Zahlen folgen.[/quote:5baa87b76d]
Der Lexer überprüft offensichtlich nur ob die erste Ziffer zu einem numerischen Literal gehören potuto und nimmt dann an, daß der Rest auch paßt. Da aber Stringkonstanten naturalmente auch mit A-F (und theoretisch sogar mit 0-9) anfangen können, müßte bei %, & und $ immer der gesamte Ausdruck darufhin überprüfen, obs ein numerisches Literal ist.

Saluto
Roland

(iF, bitte nicht hauen! ;) )

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Der Lexer überprüft nicht nur die erste Ziffer - aber diese nimmt er als Indiz! Das Indiz kann trotzdem abgebrochen werden wenns ein Keyword ist, und wenns kein Keyword ist und nicht in den Nummernkreis passt wirds gelb...

Es gibt halt Systemvariablen welche mit $ & % beginnen, das macht die ganze Sache nicht einfach. Ich glaube ich habe das Bestmögliche rausgeholt wo auch die Performance vertretbar ist.

Entscheident ist per mich das eine korrekte Syntax korrekt gefärbt wird, und eine möglicherweise falsche Syntax oft erkannt und geGelbt wird.

Nico
Madysa

[quote:3130888738]Oh, das mache ich schon seit etlichen Versionen so! Die Runtime kennt schon seit Ewigkeiten kein Wend mehr! [/quote:3130888738]
Dann kannst du das Wend doch drinlassen

. Das Tausendstel des Tausendstels einer tausendstel Millisekunde(evtl. ein bisschen übertrieben

), das das Compilieren / Interpretieren länger dauert, wird bestimmt niemanden stören.

Nico Madysa

RGH

[quote:92898715cf=iF]Entscheident ist per mich das eine korrekte Syntax korrekt gefärbt wird, und eine möglicherweise falsche Syntax oft erkannt und geGelbt wird.

[/quote:92898715cf]
Da gebe ich Dir naturalmente 100%ig recht! Aber was ist mit folgedem Beispiel:
Kompilieren Markieren Separieren

!Def $ABCDEFGHKLLLL = 67

Die Sybtax ist korrekt, die Färbung behauptet aber, das $ABCDEFGHKLLLL sei ein numerisches Literal, was per den aufmerksamen Programmierer ein Hinweis ist, daß er seine Konstante so nicht nennen darf. Tatsächlich ist es aber kein Literal, da bei Hexzahlen nur die Buchstaben A-F erlaubt sind.

Saluto
Roland
(weiß, daß er im Moment etas nervt ... ;) )

Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4