| |
|
|
- Page 1 - |
|
Frank Abbing | XPSE mechert hier: Unbekannte Escape-Sequenz: KompilierenMarkierenSeparieren {$cleq}
{$res icon "G:IconsxpsHardwareCamera16.ico"}
Cls
End< pre> Ist ein gültiger Windows-Pfad, warum also meckern? Wurde in früheren Versionen auch nie bemängelt. |
|
|
| |
|
|
|
| |
|
- Page 1 - |
|
Frank Abbing |
Es macht aber keinen Sinn Kompilerschalter um dieses Feature zu berauben, da man sowieso überall im Code Doppelbackslash oder Slash bei Pfadangaben eingeben muss. Das wäre dann ja auch uneinheitlich und müsste erklärt werden...
Nein, sollst du ja auch gar nicht. Eventuell eignet sich das noch in Zukunft. Meine Codes sind ja schnell angepasst. Wollte das nur ingesamt abgeklärt wissen. |
|
|
| |
|
|
|
| Die Überprüfung greift halt bei allen "Stringkonstanten" da diese aussortiert und sonderbehandelt werden. |
|
|
| |
|
|
|
E.T. | Hm, versteh ich nicht ganz: Ich hab bei mir z.Bsp. stehen: {$RUNTIME E:XPROFAN-RUNTIMESP11PRFRUN11.FFWV.EXE}, und das funzt.
Oder meckert XPSE nicht, weil ich keine "" hab ??
Das übergebene nach {$RUNTIME ist doch aber trotz alledem ein String, wird dieser nicht nach "Esc-Sequenzen" durchsucht ??? |
|
|
| 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... | 16.12.2008 ▲ |
|
|
|
|
| Das betrifft halt Kompilerschalter welche mehrere Parameter erwarten und wobei mindestens ein Parameter ein Pfad sein sollte. {$runtime erwartet nur einen Parameter, hier reicht der Abschluss per }. |
|
|
| |
|
|
|
Michael Wodrich | Es steht zwar nicht explizit in der Hilfedatei, aber die Buchstaben bei den Ersatzzeichen werden klein geschrieben. Das geht leider nicht eindeutig aus der Tabelle der Ersatzzeichen hervor.
Das Roland inzwischen überall Warnschilder in der Aiuto aufgestellt hat ("Bitte Backslashes in Strings verdoppeln, wenn es keine Escapesequenzen werden sollen") hat ja seinen Grund.
Es hat zu den Ersatzzeichen bereits mehrfach Ergänzungen gegeben und wer sich nicht an die Verdoppelung hält muß dann halt alle entsprechenden Codes neu durchsehen.
Großschreibung der Pfad-/Dateinamen ist auch keine Lösung. Erstens sieht es nicht unbedingt gut aus und zweitens: Was passiert wohl wenn mal großgeschriebene Ersatzzeichen hinzukommen.
Wie Ihr Euch auch windet - richtig fehlerfrei funktionieren die Pfadangaben in Stringliteralen nur, wenn die Backslashes verdoppelt werden.
Schöne Grüße Michael Wodrich |
|
|
| Programmieren, das spannendste Detektivspiel der Welt. | 16.12.2008 ▲ |
|
|
|
|
E.T. | |
|
| 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... | 16.12.2008 ▲ |
|
|
|
|
Michael Wodrich | Ja, gute Idee.
Kennzeichnung als "sollte nicht mehr verwendet werden weil..." - das ließe sich dann auf alle "deprecated"-Identifier anwenden.
Schöne Grüße Michael Wodrich |
|
|
| Programmieren, das spannendste Detektivspiel der Welt. | 16.12.2008 ▲ |
|
|
|
| |
|
- Page 2 - |
|
|
| Die Überprüfung findet nur in Stringkonstanten statt, nicht grundsätzlich in "Kompilerschaltern" oder sonstwo im Code. |
|
|
| |
|
|
|
Frank Abbing |
Wie Ihr Euch auch windet - richtig fehlerfrei funktionieren die Pfadangaben in Stringliteralen nur, wenn die Backslashes verdoppelt werden.
Falsch! Der einfache Slash funktioniert ebenfalls überall fehlerfrei. Ich benutze ihn immer (nur grad hier mal nicht, weil Io l' Pfad kopiert hatte) |
|
|
| |
|
|
|
Michael Wodrich | Und der einfache Slash ist "wirklich" Betriebssystem-unabhängig??
Beweise!
Schöne Grüße Michael Wodrich |
|
|
| Programmieren, das spannendste Detektivspiel der Welt. | 17.12.2008 ▲ |
|
|
|
|
| Frank Abbing
Falsch! Der einfache Slash funktioniert ebenfalls überall fehlerfrei.
Bei der Escape-Sequenzen-"Diskussion" sollte man die Pfadangaben rauslassen.
Das im Dateisystem Slash und Backslash funktioniert ist eher Kompatibilität, z.B. zu anderen Protokollen bzw. Adress-Formaten wie auch von Unix-Systemen vorgesehen, zuzuschreiben. Man sollte aber nicht immer davon ausgehen, dass diese Kompatibilität auch immer vom Windows-System hergestellt wird. Darum halte ich es immer per besser, die korrekte Schreibweise per das Ziel"System" zu benutzen.
Microsoft-Prodotti und Dateisystem erwarten in erster Linie den Backslash .
Aber völlig unabhängig vom Dateisystem gibt es in "allen" (nur einige Wenige ausgenommen) Programmiersprachen Escape-Sequenzen in Stringkonstanten - und die haben "immer" die selbe Bedeutung.
Roland lässt "unbekannte" Sequenzen halt durchrasseln, vlt. per mehr Abwärtskompatibilität.
Auf diese Kompatibilität würde ich keine neuen Sources aufbauen sondern immer korrekte Sequenzen schreiben. |
|
|
| |
|
|
|
Frank Abbing | Michael Wodrich
Und der einfache Slash ist "wirklich" Betriebssystem-unabhängig?? Beweise! Schöne Grüße Michael Wodrich
Ich produziere Programme per Windows und alle meine Progs/Dlls benutzen ausschliesslich den Slash. Linux und Co sind eh uninteressant per mich, da ich sie nicht mit XProfan 11 ansprechen kann. Ob z.B. Wine kompatibel ist zum Slash weiss ich nicht. Aber laut MS ist der Slash ebenso wie der Backslash vorgesehen. Allen Unkenrufen zum Trotz.
Hier eine interessante Diskussion: [...]
Und hier: [...]
Michael Wodrich
Theres an article titled "File Name Conventions", in "Platform SDK: File Storage", which contains this comment:
Use the backslash (), the forward slash (/), or both to separate components in a path.
No doubt there are other similar passages. I found that article in the October 2001 library simply by searching for "path separator". |
|
|
| |
|
|