Openfiledialog wird nich ausgeführt

[v2afrank]

Vielleicht könnte es ja mal jemand mit einem neuerem Delphi testen bitte.
Ich habe folgenden Fall gehabt.
Ein Kunde beschwerte ich darüber das mein Programm nicht mehr funktioniert. Er wollte eine Datei öffnen aber der opndialog hat nicht funktioniert.
Nach einigem suchen kann ich es jetzt nachbilden. Man nehme einen Opendialog1 und stelle als Filename
'C:\Production\87.POS.EL3?Rev.A1POSFORABC- TMS MTBF C project\Software\0815MAIN.hex'
ein. (Ich weiß der Name ist Blödsinn aber so kann man den Fehler nachbilden)
Klicke ich jetzt schon in der IDE auf Test Dialog passiert gar nichts. Keine Fehlermeldung kein Dialog nichts. Was ist da los? Auf die Schnelle konnte ich es jetzt nur mit Delphi 6 und Delphi 2006 testen. Vielleicht kann es mal jemand mit einer neueren Delphi Version testen.
Nehme ich das Fragezeichen raus funktioniert es, aber warum ?

[Klaus01]

.. das Fragezeichen ist eine Wildcard für ein Zeichen (incl. kein Zeichen).
Ich denke, der OpenDialog will einen korrekten Pfad und nicht eine "mögliche" Anzahl von unterschiedlichen Pfaden.

Grüße
Klaus

[v2afrank]

Naja, wenn dann ist es nicht dokumentiert 'C:\Production\87? Caaa' funktioniert.
Der openfieldialog von c# kommt damit auch klar. Ich versuche noch mal eben VB6 (das habe ich gerade zur Hand)

[PaPaNi]

Ich glaube auch, das liegt am Fragezeichen im Pfad.

Ein dumme Frage...
Wie kann man ein Verzeichnis mit dem Fragezeichen im Name überhaupt erzeugen?

Explorer sagt sofort schon beim Eintippen, dass dieses Zeichen nicht erlaubt ist.
Ein Filemanager-Tool z.B FreeCommander erlaubt mir das auch nicht.

[Uwe Raabe]

Hier (Delphi 11.3, Win10) geht der Dialog auf, gibt aber eine Fehlermeldung über ungültige Zeichen im FileName, wenn ich ihn mit OK abschließe.

[v2afrank]

Habe ich nicht dabei geschrieben. Das ist mehr oder weniger ein alter Dateiname von unserer chinesischen Niederlassung.Die Fragezeichen werden wahrscheinlich von einem chinesischen Dateinamen kommen
Der wird aus einer Inidatei gelesen. Diese Ini habe ich mir besorgt und konnte das dann so weit zurück führen. Ursprünglich war es auf dem Laufwerk x. Ich vermute die Datei oder das Laufwerk existiert nicht mehr aber ich frage mich mal nach.

[v2afrank]

Zitat:

Zitat von Uwe Raabe (Beitrag 1530576)

Hier (Delphi 11.3, Win10) geht der Dialog auf, gibt aber eine Fehlermeldung über ungültige Zeichen im FileName, wenn ich ihn mit OK abschließe.

Das Verhalten finde ich auch absolut richtig. Macht übrigens VB6 auch so. Es ist halt ein altes Tool mit Delphi 2006 welches nicht mehr umgestellt wird. Danke

[himitsu]

Ja, bei "ungültigen" Verzeichnis-/Dateiname geht der Dialog nicht auf ... das ist schon immer so, bei der neueren DialogAPI seit Win7 mindestens.

Und genial ist dabei auch, dass der Dialog im Rückgabewert sagt, dass der Nutzer auf das [X] geklickt habe. :lol:

[v2afrank]

Wobei Uew ja getestet hat. Bei neueren Delphi Versionen geht der Dialog auf

[himitsu]

Das von mir genannte verhalten hat nichts mit Delphiu zu tun,
es stamm rein von der verwendeten WinAPI, egal ob direkt verwendet oder in der RTL gekapselt.

[v2afrank]

Ist das wirklich so ? VB6 verhält sich richtig und erzeugt einen Laufzeitfehler. Delphi 11.3 meldet auch den Fehler.
Aber mein Delphi6 und 2006 erzeugen keine Fehlermeldung und arbeiten so als ob der Benutzer auf Abbruch gedrückt hat. Den Fehler kann man ja also abfangen. Darum glaube ich eher nicht das es nur von der WINAPI kommt, oder ?

[himitsu]

Also mindestens in Delphi XE hatten wir schon das Problem, dass ungültige Pfade (ungültige Syntax, nicht nicht-existierender Pfad) den Dialog nicht öffnete.

Und so weit ich mich glaub erinnern zu können (viele Jahre ist es her), kam da direkt beim Aufruf der API bereits als Ergebnis das "Cancel" zurück, ohne einen Fehlercode, als ich mich damals durch die RTL gedebuggt hatte.

[Rolf Frei]

Wenn dein INI File da ein ? drin hat, ist beim konvetieren/speichern der Ini Datei etwas schief gelaufen und aus einer vermutlich UTF-8 (oder besser Unicode) INI eine ANSI Datei gemacht worden, vermutlich sogar mit deinem Programm. D6 ist nicht unicodefähig und alle Ini-File Funktionen rufen da die Ansi Version der Windows Funktionen auf. Deine INI's dürfen also keine Zeichen enthalten, die nicht mit ISO8859 dargestellt werden können. Solche ungültigen Zeichen werden dann mit ? dargstellt. Mit anderen Worten, die Daten in deiner INI sind dann "kaputt" ohne chinesische Zeichen.

Einzige Lösung ist, das Verzeichnis unbenennen auf was, ohne Unicode Zeichen. Alternativ aber wahrscheinlich nicht so einfach schnell zu machen: Deine alten Programme mit neueren Delphi Versionen kompilierern, die unicodetauglich sind (ab D2009).

[himitsu]

INI niemals UTF-8.
Offiziell kennt die INI-WinAPI nur ANSI und Unicode (UCS-2 UTF-16 ohne BOM)

TMemIniFile sollte es egal sein und es dürfte mit jeder Codierung, auch mit BOM umgehen, können.
Aber TIniFile nicht.



Ich weiß nicht was passiert, wenn eine INI geändert wird, aber da vermutlich sollte es auch passieren.
Wenn beim Speichern, via WinAPI/TIniFile, erkannt wird, dass es nicht in ANSI passt, dann wird automatisch auf Unicode umgestellt.

[Rolf Frei]

Wir reden hier von D6 und da werden die A-Varianten der Windows Funtkionen genuntzt und diese verabreiten nur ANSI Dateien. Wenn man da mit einem D6 Programm eine Unicode INI liest, kommen für Unicode Zeichen nur ? zurück. Spätestens bei Schreiben mit D6 sind diese INI-Dateine "kaputt" und enthalten ? anstelle der Unicodezeichen.

[himitsu]

Upps, D2006,
ja, dort werden die ANSI-APIs benutzt und die können nur ANSI, bzw. übersetzen Unicode.

Nicht umkodierbares wird meistens als ? übersetzt.
(Achtung, Delphi reagiert bei ungültigem UTF-8 anders und gibt oft stattdessen einen Leersting zurück, egal ob zu ANSI oder Unicode)