| |
|
|
Ragnar Rehbein | die XPSE-eigenen Create-Befehle (inkl. Syntaxprüfung) kollidieren mit der standard inc von VWP2. g1.inc
bring eine satte fehlermeldung + abbruch.
das kanns doch nicht sein ??? bug oder feature ???
wenn du den XPSE noch stärker vom syntax her erweiterst fallen mir bzw. anderen langsam keine namen mehr für eigene proceduren ein.
außerdem habe ich ein problem mit den zeilennummern die bei warnungen (fehlern) angegeben werden. wie finde ich die entsprechende stelle in quelltext? der name der include + zeilennummer in der include wären nützlicher
r.r. |
|
|
| |
|
|
|
| Hehe lol stimmt.
Nunja also die einzigen XPSEs sind doch eigendlich die CreateBefehle.
Und XPSE unterstützt nunmal createspinedit lol.
Wäre ja wie als ob Du createtext redifinieren möchtest.
Einfach diese Def löschen?
Salve. |
|
|
| |
|
|
|
Dietmar Horn | Ich finde die iFsche XPSE-Logik und Verfahrensweise (was die XPSE-Weiterentwicklung betrifft) jedenfalls prima. Eine einzige Def im eigenen Source umzurubeln, das ist doch viel weniger aufwändig, als für jeden noch so winzigen Pups evtl. schon wieder einen neuen XPSE-Schalter einzuführen.
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: [...] | 19.04.2005 ▲ |
|
|
|
|
Ragnar Rehbein | solange ich in VWP2 kein spinedit erzeuge ok, aber wenn ich eins brauche, was dann ? der syntax des quelltextes wird ja komplett von VWP2 erzeugt, da kann ich nicht einfach umdefinieren.
hattest du auch meine frage bzgl. der zeilennummern gesehen ? hatte ich später editiert.
r.r |
|
|
| |
|
|
|
| Die Zeilennummern stimmen ca. mit den Zeilennummern in der *.enh überein.
Die Zeilennummern innerhalb von Includes kann XPSE derzeit nicht ausgeben - da es für xpse keine Includes gibt.
XPSE wird einfach schauen - wenn mit DEF eine solche Funktion definiert wird - das keine XPSE-Funktion dabei ist - andernfalls diese DEF simpel löschen.
Ist das ok so? |
|
|
| |
|
|
|
Ragnar Rehbein | evtl. ist es ja der späte abend oder der lange tag
was passiert denn nun, wenn meine DEF den namen einer XPSE-funktion hat, bzw. was stellst du dir vor ?
r.r. |
|
|
| |
|
|
|
| |
|
| |
|
|
|
CB | Ich wäre froh, wenn der Interpreter mit XPSE 0.14h wieder gehen würde. Mittlerweile nach tausenden geänderten Variablen keinerlei Fehlermeldung, keine Warnung mehr, aber der Interpreter will nimmer. Wenigstens kann ich noch normal compilieren und linken, bloß ist das bei der Fehlerbereinigung nervig. Mit 0.13 gibts beim selben Prog keine Probleme. Kann das eine Systemvariable sein, die die neue Version net mag? lparam,wparam vielleicht oder sowas ähnliches?
Christian |
|
|
| |
|
|
|
| Würde mich auch freuen - aber Du bist der einzige....
Ich würde wirklich gerne wissen was XProfan da veranlaßt - im Interpretermodus abzubrechen.
Vielleicht kannst mal bisl Debuggen? Scheint ja wichtig zu sein...
Salve. |
|
|
| |
|
|
|
Ragnar Rehbein | ich will ja nicht unbedingt extrawünsche ... aber ein schalter $noenhsyntax oder ähnlich wäre evtl besser.
ich persöhnlich meide alle sysntaxerweiterungen, da ich gerne kompatibel zum XProfan-Compiler bleiben möchte. ist bei fehlern (die gibt es sicherlich auch im XPSE bzw. wird es immer mal geben) aus meiner sicht sinnvoller.
trotzdem lob für die aktuelle version. alle wichtigen projekte mit meheren tausend programmzeilen sind sauber durchgelaufen. falls mir noch was auffallen sollte melde ich mich ...
r.r. |
|
|
| |
|
|
|
Dietmar Horn | Mag sein, daß meine Vorgehensweise (was die XPSE-Nutzung betrifft) manch einer als altmodisch hinstellt - mir aber egal.
Wegen meiner Kurse muß ich / möchte ich mit allen PRF-Versionen von 5.0 bis aktuell arbeiten können. Und auch mit sämtlichen aktuellen Editoren, Entwicklungsumgebungen, usw. (VWP zählt u.a. ebenfalls dazu).
Meine eigentlichen (privateren) Projekte (außerhalb des Schreibens von Kurs-Demos) sollen aber ebenfalls noch funktionieren, ohne daß ich immer -zig Klick-Orgien zum Umschalten veranstalten muß. Andererseits möchte ich aber auf XPSE nicht mehr verzichten wollen.
Ich machs so:
Ich erstelle mein(e) Projekt(e) einfach mit dem jeweiligen Editor (passende PRF-Version immer zugeordnet). Zwischendurch (und natürlich nach Fertigstellung) rufe ich XPSE per Kommandozeile vom Total-Commander aus auf, lasse XPSE prüfen, interpretieren, compilieren, linken, usw.
Damit komme ich bis jetzt recht gut klar, denn mit Alt+Tab schnell mal zur Kommandozeile umschalten, und dort per Strg+E den letzten XPSE-Aufruf zu wiederholen, das ist doch annehmbar, oder?
Die meisten Probleme mit den Zeilennummern (die eh selten ganz genau stimmen) dürfte mit dieser Vorgehensweise ebenfalls (fast) erschlagen sein, oder? Und wenn Du sowieso ständig mit z.B. den Standard-Incs von VWP arbeitest, dann wäre es doch kein Problem, die paar Def-Zeilen in der *.INC so umzuschreiben, daß sie sich mit XPSE vertragen, oder? Ich glaube nicht mehr daran, daß es in absehbarer Zukunft überhaupt noch einmal ein VWP-UpDate geben wird. Und falls wirklich, dann bestimmt nicht in solchen Stunden-Abständen, wie XPSE-Updates.
Von solchen Sachen, wie Umbenennen in COMPILER.EXE u.ä. halte ich sowieso nix, weil ich schnell mal zwischendurch immer auch mal wieder auf den PRF-Standard zurückgreifen können muß und möchte.
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: [...] | 19.04.2005 ▲ |
|
|
|
|
| Ragnar ich bin ganz ehrlich zu Dir - eine Noenhsyntaxxpseversion werde ich wohl nur schwerlich anbieten können.
Hierzu musst Du wissen - das XPSE den gesamten Source im Speicher zunächst in ein eigenes Format konvertiert (komprimierter) (ähnlich wie PRC) und danach wieder ausspuckt.
Bei diesem mehr oder weniger grausamen Procedere wird also der Source eh reformatiert. Die Creategeschichte ist da ein Abfallprodukt.
Ich bin mir aber sicher das wir das ultrakompatibel und megaelegant über die Bühne kriegen.
Die Gegenvariante zum Löschen der Def wäre ja - das XPSE ge-defte gleichnamige Funktionen in Ruhe lässt. Das ist schon denkbar - passt mir aber leider garnicht ins Konzept - da Roland vielleicht demnächst mitspielt...
Es wäre ja auch nicht empfehlenswert - wenn Du z.B. eine def create baust - oder eine def addstring - oder eine def trim.
Weist wie ich meine?
Salve. |
|
|
| |
|
|