XPSE

« Dieser Beitrag wurde als Lösung gekennzeichnet. »

p.specht

Tja, das war richtig Arbeit:
Jeweilige .exe anklicken, Rechte Maustaste - Eigenschaften >>> Zulassen (wegen ansonstiger Sperre wg. Übernahme von Fremdcomputer) durch Anhaken des kleinen Feldes unten mit anschließendem "Übernehmen", Administratorberechtigung bestätigen. 10 sek Prüfzeit per Defender abwarten.

Weiters im Eigenschaften-Fenster auf Tab "Sicherheit", dort aktuellen Stand per Gruppe "Benutzer" aufschreiben per allfälliges Zurücksetzen), checken ob per Gruppe "Benutzer" die Rechte auf "Lesen, Ausführen" gesetzt sind. Bei PoLink auf "Schreiben" erweitern, falls das Verzeichnis in das geschrieben werden soll, nicht selbst Schreiben erlaubt.

Situation jeweils mit {$cl} in der ersten Zeile und NProc-Aufruf (ggf mit Assemblerbefehlen) in der Source testen. Beim Testen hat sich der Desktop als Ziel bewährt, weil man dann sieht, in welchem Stadium der Vorgang steckenbleibt und man den Müll leicht löschen kann.

Angaben ohne Gewähr - bei mir hats (zufällig?) geklappt. Beide Andreasse (Miethe+ und Hoetker) gehen uns deutlich ab.
Gruss

Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'...

E.T.

Gibts von XPSE (schwarzes Commandfenster) eine Fehlermeldung bzw. wo bleibts denn stehen ??

Vlt. ggf. mal 'nen Screenshot

XProfan X3
Grüße aus Sachsen... Mario
WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte...

19.09.2020 ▲

p.specht

Hallo, E.T.!
xpse bleibt nach Schreiben der *.enh - File stecken. Das Cmd-Fenster bleibt schwarz, kein prompt, kein Text.
Welcher Schritt soll das fertige .enh-File weiterbearbeiten - da ist ja noch alles Klartext: Diesem Schritt muss man offenbar mehr Rechte geben. Aber ich will nicht gleich alles auf einmal mit Generalrechten versehen müssen - Also was genau braucht in Win-10 welche Rechte - weiß das jemand, bitt´schön?

Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'...

19.09.2020 ▲

p.specht

Habe mich nun von der "alles freigeben"-Seite (Da ging auf eimal alles) her immer enger rangetastet: Polink hatte zuwenig Schreibrechte! Dieses Problem können wir also ad acta legen.

Dafür tauchte nun ein neues auf: Die Zeile
print " Eingeben: ";:input x$
landet in der .enh-File als
print " Eingeben: ";input x$
ohne den trennenden Doppelpunkt, was zu einem Fehler "Variable inputx$ nicht deklariert" führt. Abhilfe nur durch scrivere su un neue Zeile, weder mehrfache Doppelpunkte noch Leerzeichen helfen da.

Auf Win-7 lief das ganz normal. Mein Gehirn käst bereits.
Win-10-2004 ist einfach das Letzte (Betriebssystem).

XProfan 11
Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'...

21.09.2020 ▲

Kompilieren Markieren Separieren

E.T.

Also ohne XPSE funzt es:

Declare X$
CLS
print " Eingeben: "; :input x$
end

Würde mal {$PUSHKEYWORD :input} versuchen (siehe XPSE-Kompilerschalter)

Grüße aus Sachsen... Mario
WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte...

21.09.2020 ▲

Stephan
Sonneborn

p.specht (21.09.2020)

Habe mich nun von der "alles freigeben"-Seite (Da ging auf eimal alles) her immer enger rangetastet: Polink hatte zuwenig Schreibrechte! Dieses Problem können wir also ad acta legen.

Kann das mit dem schwarzen Bildschirm bestätigen. Wo und wie hast Du das mit dem alles-freigeben gemacht? Hast Du der xpse.exe die Rechte gegeben?

Gibt es eine andere Lösung als mit dem xpse ein Programmicon vorzugeben?
Habs mit dem Resource Hacker und ResourceBuilder probiert. Beide Male ist danach die Exe unbrauchbar.

XProfan X4
Schöne Grüße aus Wittgenstein
von Stephan

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

22.09.2020 ▲

Stephan Sonneborn (22.09.2020)

E.T.

Gibt es eine andere Lösung als mit dem xpse ein Programmicon vorzugeben?
Habs mit dem Resource Hacker und ResourceBuilder probiert. Beide Male ist danach die Exe unbrauchbar.

Ich nutze den XPrfWriter, da kann man ein Icon per die Exe angeben.

Ansonsten vor dem Linken eine Kopie von Profrun32.Exe erstellen.
In dieser kann man alles mögliche, auch die Icons, ändern.
Dann diese "modifizierte" Profrun32 verwenden.
siehe {$RUNTIME param} bei XPSE-Kompilerschalter

XProfan 11
Grüße aus Sachsen... Mario
WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte...

22.09.2020 ▲

Stephan
Sonneborn

An Andreas' super Editor hatte ich nicht gedacht.

Habs heute ausprobiert und corre! Danke per den Tipp!!!

Andreas hatte immer soooo tolle Sachen im Angebot. Er fehlt auch sehr

...

XProfan X4
Schöne Grüße aus Wittgenstein
von Stephan

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

p.specht

Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'...

Kompilieren Markieren Separieren

p.specht

E.T. (21.09.2020)

Würde mal {$PUSHKEYWORD :input} versuchen (siehe XPSE-Kompilerschalter)

Leider kein Erfolg. Werde wohl alle XPSE-Sourcen mit :input auf Einzelzeilen umstricken müssen ...

EDIT: Das Phänomen tritt offenbar nur in der Kombination ";:" auf! Ersetzt man ";" durch "," (wird also zu ",:"), corre alles glatt! Werde mir ein Progi schreiben, das mir das umschreibt.

Zum Nachvollziehen mein Testprogramm am Desktop:

 $IFDEF xpse
 {$cl}
 $ENDIF
cls
Declare x$
Print "Eingabe:",:Input x$
Print x$
WaitInput 5000
End

Achtung, $IFDEF xpse ist eine Dummyzeile, da xpse sich per dort nicht definiert. Aber Interpreter und Profancompiler ignorieren dann die {$cleq} & Co-Zeilen.

Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'...

Alle Sprachen
WinXP, SP3, Core(TM) i7-3770 @ 3.40GHz

p.specht (19.09.2020)

{$cleq}-Schalter in der 1. Programmzeile den XPSE, der eine .enh-File schreibt - und dann mit einem schwarzen Commandfenster steckenbleibt. Frage: Welcher nächste Schritt folgt da und macht Probleme?

Hier friert wohl ein Programmstart ein (die nächsten Schritte wären Programmstarts der weiteren Kompilierer) ggf. wegen fehlender [Vererbung der] File-Ausführungsrechte.

Es hängt auch von den (Windows-) Benutzerkonto- Einstellungen ab, wie ein Programm mit Admin und/ oder Start- Rechten wiederum ein ggf. Unberechtigtes startet.

Vergibt man an die Kompilierer/ IDE- etc. Admin- und File- Ausführungsrechte, dann potrebbe das Problem nicht entstehen.

p.specht (19.09.2020)

Dafür tauchte nun ein neues auf: Die Zeile
print " Eingeben: ";:input x$

Schöner Fehler.

Habs mit auf die Todo genommen!

;: werden als 2 aufeinanderfolgende Zeilentrenner verstanden wobei letzterer falsch als redundant erkannt wegrationalisiert wird. Dies kollidiert naturalmente mit der Sonderklausel "Print mit Semikolon am Ende".

24.09.2020 ▲

p.specht

ty4rem, und falls du wirklich iF bist

: Welcome back!

Hinweis: Ab X4alpha kann :: das Ende eines Inline-Labels sein! Für X3 gabs ja jprc zum Herstellen der For-Schleifen. Vielleicht fällt per X4 ja dazu auch ein Workaround an.

Computer: Gerät, daß es in Mikrosekunden erlaubt, 50.000 Fehler zu machen, zB 'daß' statt 'das'...

24.09.2020 ▲