XPSE

- Page 5 -

Dietmar
Horn

Hallo David,

folgendes klappt bei mir:

$I C:VEREINDHOXPROFAN9FORTSCHRITT.INCTEST

und das auch:

$I C:VEREINDHOXPROFAN9FORTSCHRITT.INC TEST
(Hochkamma durch Leerzeichen abgetrennt)

Wenn ich jedoch das Hochkamma durch einen Tabulator abtrenne - nur dann funzt es nicht mehr.

Dietmar

Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V. [...]

Windows 95 bis Windows 7
Profan² 6.6 bis XProfan X2 mit XPSE

Das große XProfan-Lehrbuch: [...]

Verstehe - is heut noch behoben.

Salve, iF

Dietmar
Horn

Danke,

nun klappt es endlich wieder!

Aufgefallen ist mir das eigentlich erst im Zusammenhang mit dem Compilerschalter per die bedingte INC-Einfügung mit darin enthaltenen PROCS.

Den Compilerschalter hierfür halte ich nach wie vor per überflüssig, genau wie die strengere Syntaxüberprüfung in diesem Punkt.

Meiner Meinung nach sollte es nicht die Aufgabe eines Programmautors sein, die Anwender seiner Software in irgendeine Richtung herumerziehen zu wollen. Meistens corre das sowieso gegen den Baum (siehe GOTO-Diskussion, oder circa die Sache mit mehreren Befehlen in einer Zeile im RGH-Foro).

Solange es in XProfan keinen richtigen Compilerschalter per bedingte Compilierung gibt, hat diese Vorgehensweise meiner Meinung nach ihre Berechtigung: Was z.B. in einer Testversion gar nicht erst im Code drin ist, das bläht das Programm nicht unnötig auf (und kann auch gar nicht erst gecrackt werden).

Dietmar

Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V. [...]

Windows 95 bis Windows 7
Profan² 6.6 bis XProfan X2 mit XPSE

Das große XProfan-Lehrbuch: [...]

Du ich weiß nicht genau was Du meinst.

XPSE soll auch niemanden erziehen - es geht darum die Fehler eines Sources auffindig zu machen um maximale Interpretationsgenauigkeit zu Produzieren.

Beim Proggen gibt es strenge Regeln - aber was erzähl ich Dir.

Es ist sicher falsch wenn ein Compiler folgendes erlaubt:

proc
if
endproc
endif

da nicht vorhersehbar ist wied er Code von PRFVersion zu Version interpretiert wird. Es ist also unklar - was wiederum gegen jede Form der Programmazione spricht.

Aber ich glaube darum gings Dir nicht - ich habe Dich wohl nicht richtig verstanden.

Salve, iF

Dietmar
Horn

Hallo David,

ich schätze, da haben wir beide jeder ein bißchen recht - oder uns tüchtig mißverstanden.

Als vorläufigen Ersatz per bedingte Compilierung meinte ich lediglich eine Konstruktion in folgender Art:

if testversion%
proc pla mit Inhalt 1
endproc
else
proc pla mit Inhalt 2 <> Inhalt 1
endproc
endif

oder notfalls:

if testversion%
proc pla
endproc
else
proc pli
endproc
endif

wobei dann beim Aufrufen der PROCs naturalmente ebenfalls nochmals eine IF-ELSE-ENDIF-Abfrage auf testversion% erforderlich wäre, die nicht angemeckert werden potrebbe. Das sollte auch beim Verwenden von XPSE erlaubt bleiben.

Jedenfalls, solange es in XProfan noch keine andere Möglichkeit per (echtes) bedingtes Compilieren gibt ...

Die anderen von Dir genannten Konstruktionen sollten naturalmente auch weiterhin von XPSE angemeckert werden, solange RGH bzw. sein Compiler das nicht selber macht.

Saluto
Dietmar

Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V. [...]

Windows 95 bis Windows 7
Profan² 6.6 bis XProfan X2 mit XPSE

Das große XProfan-Lehrbuch: [...]

- Page 6 -

Ok - ich verstehe und sehe es ein.

Ich werde das Abprüfen von if;proc;endproc;endif entfernen.[quote:0561ce5d0c]solange RGH bzw. sein Compiler das nicht selber macht[/quote:0561ce5d0c]Da will ich kurz einhaken.

Rolands Compiler ist - sagen wir so - nicht der Schnellste. Mir ists lieber xpse meckert nach ein paar Millisekunden das was nicht stimmt - als das Rolands Compiler in Zeile 95.000 nen Fehler findet.

*duck*

Salve, iF

Dietmar
Horn

Prima!

Hoffentlich liest Roland selber hier gelegentlich mit ...

*duck*

Saluto
Dietmar

Multimedia für Jugendliche und junge Erwachsene - MMJ Hoyerswerda e.V. [...]

Windows 95 bis Windows 7
Profan² 6.6 bis XProfan X2 mit XPSE

Das große XProfan-Lehrbuch: [...]

Nein- leider nicht.

Schau hier wer hier schon gelesen hat: [...]

Unten - in der Minitoolbar ist ein Auge - dort ist ersichtlich wer bereits das Topic gelesen hat.

Salve, iF

Stephan
Sonneborn

Hi iF,

nachdem ich mein Programm mit dem XPSE V0.1.3r habe prekompilieren lassen, scheint der CREATE-Bug, wenn mehrdimensionale Arrays als Handle vorkommen, gefixt zu sein. Danke!!!

Nun zum nächsten Problem:

Aus
Kompilieren Markieren Separieren

+----------------------------------------------------------------------------------------------+
SplashScreen erzeugen (1 sec anzeigen)
+----------------------------------------------------------------------------------------------+
WINDOWSTYLE (1+2+8+16+32+64+512)
SplashScreen& = CREATEWINDOW(%DESKTOP, "", 0,0,300,300)
SETWINDOWPOS SplashScreen& = (%MAXX-300)/2,(%MAXY-300)/2-300,300;-1
STARTPAINT SplashScreen&
DRAWPIC FlashBitmap&, 0,0;0
ENDPAINT
SLEEP 1000
DESTROYWINDOW(SplashScreen&)
+----------------------------------------------------------------------------------------------span>

macht der XPSE
Kompilieren Markieren Separieren

WINDOWSTYLE (1+2+8+16+32+64+512)
SPLASHSCREEN&=CREATE("WINDOW",%DESKTOP, "", 0,0,300,300)
SETWINDOWPOS SPLASHSCREEN&=(%MAXX-300)/2,(%MAXY-300)/2-300,300;-1
STARTPAINT SPLASHSCREEN&
DRAWPIC FLASHBITMAP&, 0,0
0
ENDPAINT
SLEEP 1000

Was stimmt hier nicht? Richtig! Das Semikolon im DRAWPIC-Befehl wird als Befehlstrenner erkannt und schiebt die 0 in die neue Zeile. Folge: Der XProfan-Compiler beschwert sich. Mit 0 kann er nix anfangen. Es ist zu prüfen, ob das auch die anderen Bitmap-Befehle betrifft...

Schöne Grüße aus Wittgenstein
von Stephan

Programmierumgebung:| XProfan X4 | WIN10 | AMD FX6100 3,3 GHz

18.03.2005 ▲

Yehhaa - vielen Dank Stephan!

Mag gugn welche Befehle Roland da noch eingeschmuggelt hat welche nen Semikolon in der Syntax nutzen.

Salve, iF

Kleiner Tip am Rande:

Aus WINDOWSTYLE (1+2+8+16+32+64+512) mach besser WINDOWSTYLE (1|2|8|16|32|64|512)

19.03.2005 ▲