| |
| |
|
| - Seite 1 - |
|
Frank
Abbing | XPSE mechert hier: Unbekannte Escape-Sequenz:
KompilierenMarkierenSeparieren {$cleq}
{$res icon "G:IconsxpsHardwareCamera16.ico"}
Cls
End
Ist ein gültiger Windows-Pfad, warum also meckern? Wurde in früheren Versionen auch nie bemängelt. |
|
| |
| |
| |
|
|
| |
| |
| - Seite 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 Hilfe 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 ▲ |
|
| |
|
| |
| |
| - Seite 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 ich den 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 für besser, die korrekte Schreibweise für das Ziel"System" zu benutzen.
Microsoft-Produkte 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. für 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 für Windows und alle meine Progs/Dlls benutzen ausschliesslich den Slash.
Linux und Co sind eh uninteressant für 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". |
|
| |
| |
| |
|
(528)
).
Deutsch
English
Français
Español
Italia