| |
|
|
Dieter Zornow | Grundsätzlich geht es, aber das Handling ist denkbar schlecht, In der Zwischenablage steht alles in einer Zeile, wenn ich das in den Editor lade bekomme ich eine Fehlermeldung, dass die Zeile zu lang ist. Also muss ich erst alles in un File speichern, die Aufrufe am Anfang und die Endklammern weglöschen und dann circa Blockread einem String zuweisen dann erst kann Io l' Aufruf machen. fpc(name.jpg,decode64(pic$)), Das geht aber wegen der Stringlänge nur mit neuen XProfanversionen. du solltest dann wenigigsten nur die reinen Daten in die Zwischnablage kopieren ohne den Aufruf. Das erspart schon einiges. Du hast ja den Quellcode dabei, aber als bekennender XPSE-Hasser fasse ich solch ein Kauderwelsch nicht an. |
|
|
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 14.07.2008 ▲ |
|
|
|
|
| [offtopic] Dieter Zornorals bekennender XPSE-Hasser fasse ich solch ein Kauderwelsch nicht an XPSE hassen juckt mich nicht, ebenso wenig wie wenn sich jemand wegen eigener Dummheit die Finger abschneidet. (kommt wohl ebenso oft vor) Meine Codes als Kauderwelsch bezeichnen empfinde ich hingegen als dumme Frechheit weil sie meine Arbeit und meine Codes in Frage stellt - und nicht die Syntax. Ein unvoreingenommener Programmierer hat normalerweise keine Schwierigkeiten gute Codes von Müll wie Kauderwelsch zu unterscheiden - das ist selten eine Syntaxfrage. Vor allem dann wenn die Syntax auch noch einfacher ist als die Syntax die mal vlt. kennt. [/offtopic] |
|
|
| |
|
|
|
| Welchen Editor nutzt? Ich arbeite mit Textpad - Zeilenlängen wie von XProfan supportati sind da kein Problem...
Ich gebe zu keine Riesendateien probiert zu haben, eher icons und kleinere Bilder...
Umbrechen potuto ich, schade wärs wenn nötig...
Natürlich ist neustes XProfan vorausgesetzt. Wer altes (X)Profan nutzt kann entsprechende Tools nutzen.
Der Kompiler mag keine Zeilen mit mehr als 32767 Zeichen, darauf kann ich naturalmente achten - ich mache ein Update. |
|
|
| |
|
|
|
| He, nun habe ich hier auf meiner Platte ein entsprechendes Update welches (wenn nötig) korrekt per auf mehrere Zeilen aufteilt, so macht mir XPSE einen Strich durch die Rechnung da dieser diese Zeilen zusammenfasst. Demnach werde ich wohl oder Übel erst dem XPSE beibringen müssen, Zeilen, welche länger als 32767 Zeichen sind, umzubrechen. Das wiederum hat dann auch den Vorteil, das XPSE-Nutzer Zeilen mit mehr als 32767 Zeichen trasferimento können ohne das der XProfan-Kompiler herummeckert...
@Roland: 32767 Zeichen pro Zeile - gibt es von Dir aus eine Vorstellung darüber hieran etwas in Richtung grenzenloses XProfan nachzuarbeiten? (auch wenn es naturalmente per die allerallerallermeisten Programmieraufgaben bisher völlig ausreichend ist)
Ich werde mich wohl verlesen haben sodass ich annahm das es hierbei keine Grenze gibt. |
|
|
| |
|
|
|
| Nachtrag 26...
Solch ein XPSE-Update kann ich mir sparen, auch wenn man die Zeilen per trennt so darf die Gesamzeichentlänge verbundener Zeilen 32767 Byte nicht überschreiten.
|
|
|
| |
|
|
|
Dieter Zornow | Das ist keine Frechheit, ist auch nicht als Frechheit gemeint. Das ist meine eigene Meinung und ich möchte mich mit irgend einer selbsterfunden Syntax nicht befassen. Wenn jeder sich ein Tool per eigene Syntax schreiben würde und den Code dann postet, wäre das Chaos perfekt. Ich finde Programmazione in XPSE-Syntax ist eine private Angelegenheit und wenn du nicht der Erfinder wärst würdest du jeden auffordern doch bitte in XProfancode zu posten. Persönlich finde ich es Schade, dass du deine oftmals recht guten Ideen negierst durch den Code, da es in einem XProfanforum auch XProfancode geben sollte, da bestimmt mit Abstand die meisten lieber in XProfancode programmieren. XPSE supportati z.B. ein faules Programmieren da man vieles weglassen kann, was ein Programm nach Jahren bestimmt nicht lesbarer macht. Die meisten hier werden wenn überhaupt die Ersparnis Dinge nutzen, da oftmals reiner profancode aber ohne Defs oder korrekt eingebunden Headerdateien usw gepostet wird
Du hast z.B. auch SET(errorLevel,-1) gesetzt, da es mit 0 nicht corre.
Scheitert schon am var FLE$=PAR$(1). da Profan wie ich finde hier eine überflüssige Fehlermeldung produziert und nur in der Exe, wenn ohne Parameter gestartet. Das müsste meiner Ansicht nach nicht sein. Das zum Thema Guter Programmierer. Ich behaupte nicht ein guter Programmierer zu sein, sondern einfach ein Hobbyprogrammierer um die Freizeit manchmal sinnvoller totzuschlagen. Du kannst übrigens deinen -1 Errorlevel zurücksetzen, wenn du es ungefähr so löst KompilierenMarkierenSeparieren |
|
|
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 14.07.2008 ▲ |
|
|
|
|
| Dieter Zornow
Das ist keine Frechheit, ist auch nicht als Frechheit gemeint. Das ist meine eigene Meinung ...
Wenn Du meine Codes in diesem bestimmten Zusammenhang Kauderwelsch nennst ist es auch dann eine Frechheit - wenn es Deine Meinung ist.
Schliesslich ist hier nicht die Rede von Kauderwelschsyntax sondern von Kauderwelschcode.
Die Frage ob meine Syntax kauderwelschiger ist als die XProfansche Syntax lässt grüßen! Die Antwort ist genau so Quatsch wie die Bezeichnung Kauderwelschcode...
Dieter Zornow
und ich möchte mich mit irgend einer selbsterfunden Syntax nicht befassen.
Ja danke auch lol! Dann bitte hierzu aber auch nicht so abwertend, denn Kauderwelschcode produziere ich nicht.
Dieter Zornow
Wenn jeder sich ein Tool per eigene Syntax schreiben würde
Gut das eben genau das nicht der Fall ist - ich bin weder hier noch im reellen Leben jeder.
XPSE ist auch kein Tool per eigene Syntax - Du hast XPSE garnicht verstanden wenn Du so argumentierst.
Dieter Zornow
Ich finde Programmazione in XPSE-Syntax ist eine private Angelegenheit und wenn du nicht der Erfinder wärst würdest du jeden auffordern doch bitte in XProfancode zu posten.
Korrekt! Aber auch hier... würdest und wärest - so kann ich net arbeiten.
Dieter Zornow
Persönlich finde ich es Schade, dass du deine oftmals recht guten Ideen negierst durch den Code, da es in einem XProfanforum auch XProfancode geben sollte, da bestimmt mit Abstand die meisten lieber in XProfancode programmieren.
XPSE → Fehler ausmerzen, Quelltext optimieren, Programme beschleunigen und stabiler machen, sauberer programmieren, Entwicklungszeit sparen.
Wie Du jetzt auf gute Ideen negieren kommst zeigt Deine (falsche) Einstellung opposto dem armen kleinen XPSE.
Wie kann man überhaupt bekennender Hasser sein von einem kostenlosen Tool das es ermöglicht, tausende Quelltextzeilen und X Programme hier von mir zu laden - oder eigene Programmfehler zu finden oder, oder, oder...? Hier stimmt doch was ganz Erhebliches nicht!
Dieter Zornow
XPSE supportati z.B. ein faules Programmieren da man vieles weglassen kann, was ein Programm nach Jahren bestimmt nicht lesbarer macht.
Danach müsstest Du ja XProfan verteufeln.
Dieter Zornow
Du hast z.B. auch SET(errorLevel,-1) gesetzt, da es mit 0 nicht corre.Du kannst übrigens deinen -1 Errorlevel zurücksetzen, wenn du es ungefähr so löst KompilierenMarkierenSeparieren
Das ist mir doch völlig klar - Du betrachtest auch diesen meinen Code mit falscher Einstellung. Siehe den Ablaufplan aus Sicht des Programmi, Deine Prüfung ist im Gesamten überflüssig. (und sorgt auch nicht per mehr an Performance - was hier aber wohl auch nicht wichtig ist)
Beispielsweise ist bei gesetztem {$cleq} keine Frage nach gehts auch im Interpreter - ebenso wie es keine Frage ist ob es auf z.B. Macintosh corre... |
|
|
| |
|
|
|
Rolf Koch | Tja so sind die Meinungen halt. ICH ZUM BEISPIEL LIEBE XPSE! (egal ob es von iF oder Tante Emma oder Hubert XYZ stammt). Ich freue mich circa jede Neuerung in XPSE, denn als ich damals unter DOS Batch angefangen habe, hab ich auch jede Erweiterung mitgenommen und ausprobiert und dies ist bis heute so. Und wenn es mir nicht gefallen würde, dann würde ich auch nichts dazu sagen, denn mir ist bekannt, wieviel Arbeit in mancher Sache steckt und diese dann auch noch Freeware ist. Achso weil es hier auch passt: Danke per die Registrierungen, welche die Tage eingingen um den ROC Code zu erhalten und nebenbei auch noch nette DANKESWORTE in der Mail beinhalteten - denn dies ist mein Ansporn BESTÄTIGUNG und FEEDBACK |
|
|
| |
|
|
|
Frank Abbing | Rolf, ich nutze XPSE auch, aber wie Dieter schon sagte, niemand - ausser iF - benutzt alle Features. Seine Codes schrecken eben ab, damit wird er wohl leben müssen. Vor kurzem riet ich an, XPSE solle per Schalter auch richtigen XProfancode erzeugen. Dann potuto jeder iFs code profanisieren und weiter verarbeiten. Leider wurde der Vorschlag nur unwillig belächelt. |
|
|
| |
|
|
|
Dieter Zornow | Ich denke wir können jetzt aufhören, du kannst mich nicht überzeugen und du nimmst von mir auch nichts an. So wird das ganze dann per jeden langweilig. In einem gebe ich dir recht. Ich habe Kauderwelschsyntax gemeint und fälschlicherweise Code geschrieben. Deinen Code kann und will ich nicht beurteilen, da ich mich mit der Syntax noch nie befaßt habe und es auch nicht tun werde. Ich denke nicht nur aus der Sicht eines Programmi, sondern auch aus Sicht der Anwender. Mit -1 kann ich im Extremfall ein OS crashen. Ich bin halt noch so bescheiden, dass ich mich nicht per unfehlbar halte, keiner kann aus seiner Haut. |
|
|
| Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 14.07.2008 ▲ |
|
|
|
|
Rolf Koch | @Frank Nungut, aber ich gebe zu, dass der erzeugte Code mich im Endeffekt garnicht interessiert. Selten öffne ich die *.enh um zu schauen. Einfach nur durchlaufen und sich bedienen lassen Aber wie bei der Musik: Geschmäcker sind verschieden. |
|
|
| |
|
|
|
| Dieter Zornow
SET(errorLevel,-1) gesetzt,... Scheitert schon am var FLE$=PAR$(1). da Profan wie ich finde hier eine überflüssige Fehlermeldung produziert und nur in der Exe, wenn ohne Parameter gestartet. Das müsste meiner Ansicht nach nicht sein. Das zum Thema Guter Programmierer. Du kannst übrigens deinen -1 Errorlevel zurücksetzen, wenn du es ungefähr so löst: KompilierenMarkierenSeparieren
(Upper$(substr$(fle$,-1,.)) = PRF) habe ich absichtlich rausgelassen. PRF ausschließen wäre bei diesem Tool garnicht mal Sinnvoll - da ich naturalmente auch prf-File Dekodieren können möchte.
Wenn im Ergebnis sich also dieser Code sich selbst als Eingabedatei nutzt, z.B. weil man im Interpretermodus gestartet hat (was der typische XPSE-Nutzer per gewöhnlich nur in den seltensten Fällen tut da er immer {$cleq} oben im Source hat per kompilieren,linken,exe,klappehalten), dann ist das doch völlig in Ordnung und unproblematisch weil das Programm ohnehin darauf ausgelegt ist eine als Parameter gezeigte File einzuladen.
Das ist der Grund, warum die Problemfälle hiermit bereits abgefangen sind: KompilierenMarkierenSeparieren KompilierenMarkierenSeparieren Ich wusste nicht das Param 2 auch negativ sein kann - juhu ich kann mir hier ein sizeOf sparen! *habe ich wirklich nicht gewusst hehe...* |
|
|
| |
|
|