Pfad und Umlaute

[Jan]

Das hier ist eine Fortsetzung von dem Thema "Pfad" von gestern.

Wie in dem Thread bereits erwähnt gesagt, ist das Programm mandantenfähig. Im Verzeichnis mit der Exe gibt es die Verzeichnisse mit den unterschiedlichen Mandanten. Das jeweils geöffnete Verzeichnis = der gewünschte Mandant wird bei Auswahl des Mandanten in eine Public eingelesen. Geöffnet werden die dbf dann wie folgt:

Code: Alles auswählen

USE (MEMVAR->gcDatenpfad + "datenbankname") NEW SHARED

Was auch absolut einwandfrei funktioniert.

Jedenfalls meistens. Es funktioniert genau dann nicht mehr, wenn in dem Pfad ein Umlaut auftaucht. Leerzeichen, Ziffern oder sogar Endungen (bei Verzeichnissen ja eher ungewöhnlich) werden einwandfrei umgesetzt. Nur Umlaute nicht.

Ist das Absicht? Oder ein Bug? Oder übersehe ich da was? Was kann ich dagegen tun?

Jan

[AUGE_OHR]

hi,

Nur Umlaute nicht.

Ist das Absicht? Oder ein Bug? Oder übersehe ich da was? Was kann ich dagegen tun?

die Frage ist wie kommst du zum Sonderzeichen ? Directory() ?

USE (MEMVAR->gcDatenpfad + "datenbankname") NEW SHARED

kein IF FILE(ConvToAnsiCP(cFile)) davor ?

gruss by OHR
Jimmy

[Jan]

Hallo Jimmy,

wie so oft hast Du mal wieder recht. Obwohl ich das extrem irritierend finde. Ich habe nämlich in VX als "Character conversion" "Ansi->OEM" eingetragen. Womit z. B. Umlaute korrekt bei der Ausgabe im laufenden Programm korrekt ausgegeben werden. Damit werden ANSI-Texte im Code wirklich korrekt ausgegeben (normalerweise erwartet Xbase++ ja OEM-Text als Grundlage, was mich aber ungemein stört).

Quintessenz ist jetzt: Den Pfad baue ich jetzt so ein:

Code: Alles auswählen

MEMVAR->gcPfad := ConvToAnsiCP(MEMVAR->gcAppPfad + "Mandantenverzeichnis\")

Für die Ausgabe des Pfades auf dem Bildschirm muß ich dann einbauen

Code: Alles auswählen

oInfo:title := ConvToOemCP(gcPfad)

, weil da ansonsten Murks bei angezeigt wird.

Ich muß gestehen, daß ich das im Moment einfach nur irritierend finde, so wirklich verstanden habe ich das noch nicht, das erscheint mir alles unlogisch. Ich werd mir da noch mal Gedanken drum machen müssen Aber es sieht so aus, als ob Xbase++ in der Tat ausschließlich OEM versteht, und mit der Conversion-Einstellung von mir dieses Manko einfach umgangen wird. Aber warum kann ein Windows-Programm kein ANSI???

Aber Danke für Deinen Tipp, es funktioniert schließlich einwandfrei.

Jan

[Martin Altmann]

Hallo Jan,
soweit ich mich erinnere, funktioniert die automatische Umwandlung nur bei Ausgaben - egal, ob jetzt als Ausgabe "in" ein Xbp oder eine Datenbank - und bei Eingaben - also Lesen aus einer Datenbank.
Lowlevel-Dateizugriffe und -Funktionen sind davon ausgenommen!
Steht - wenn ich mich nicht irre - so auch in der Hilfe...

Viele Grüße,
Martin

[Koverhage]

Martin,

wobei man sich streiten kann ob ein "normaler" USE eine LowLevel function ist

[Armin]

hi Jan,

Probleme könnten jetzt noch Sonderzeichen in Pfad/Mandantennamen machen.

Grüsse, Armin

[andreas]

Hallo Jan,

ich würde an deiner Stelle keinen Mandantennamen nehmen.
Was passiert, wenn der Name sich nachträglich ändert? Kannst du dann auf die Daten gar nicht zugreifen!?
Ich würde an deiner Stelle beim Anlegen des Mandanten eine eindeutige bzw. fortlaufende Nummer nehmen und diese bei den Verzeichnisname verwenden z.B. "Mandant0001" oder ähnliches.

[Jan]

Hallo Andreas und Armin,

jeder Mandant ist 1 Verzeichnis, und die Verzeichnisse werden in einem Verzeichnisdialog immer frisch eingelesen, hieraus kann dann der gewünschte ausgewählt werden. Der Mandantenname steht dann in einer eigenen Einstellungs-Datenbank in dem Verzeichnis, kann also durchaus vom Verzeichnisnamen abweichen, was aber völlig egal ist. Außer, daß bei absurden Verzeichnisnamen-Änderungen der bestimmte Mandant nicht mehr auffundbar ist. Aber normalerweise heißt das Verzeichnis wie der Mandant, wenn das alles über das Programm läuft.

In diesem speziellen Fall war es einfach so, daß ich während der Entwicklung der entsprechenden Module zu Testzwecken ein Verzeichnis fest kodiert hatte (was eben im normalen Betrieb niemals passieren wird). Und da war eben ein Umlaut drin.

Von daher kann von Außerhalb ruhig der Verzeichnisname geändert werden - völlig egal. Und Sonderzeichen im Pfadnamen sollten hoffentlich auch kein Problem sein, ich setze voraus, daß Xbase++ mit allem umgehen kann, was Windows erlaubt.

Jan

[Armin]

Hallo Jan und Andreas,

ich habe Verzeichnisse mit Adressnamen, Werkzeugbezeichnungen usw. (das mögen die Kunden, denn dann können sie auch so drin-rum suchen).

Werden diese geändert, so ändere ich eben auch die Verzeichnisse. D.h. ich erstelle das Verzeichnis mit neuem Namen, kopiere den Inhalt, vergleiche und markiere dann das alte Verzeichnis zum Löschen.
Sonderzeichen ersetze ich mit Unterstrichen. Rechte, bzw. Rechtegruppen ordne ich diesen Verzeichnissen ebenfalls zu, bzw. schränke sie ein.

Läuft mittlerweile problemlos.

Grüsse, Armin

[brandelh]

Das mit den Umlauten in den Pfaden hatten wir schon öfters.

Im Prinzip gebe ich dir Recht, dass die automatische Umlautkonvertierung auch das abfangen müsste, tut es aber nicht. Auch bei einigen anderen Sachen (Sonderzeichen (c) oder (R) in Resourcen etc.) gibt es da Ungereimtheiten.

Meine Empfehlung lautet bei neuen Projekten1) den Editor auf ANSI zu stellen und SET CHARSET ANSI zu verwenden. Dann wird nur noch das automatisch umgesetzt was in DBF Dateien (DBFNTX, FOXCDX je nach Erstellung) liegt und das stimmt immer.

Aber es ist schon verwunderlich, das VX das nicht automatisch so vorgibt ?

1) geändert zur Klarstellung nach dem Einwand von Klaus

[Koverhage]

Hubert,

das wäre fatal, gerade bei "alten" Quellcode. Du müsstest das doch wissen,
wenn Du auf der Developers Conference den Umstieg von Clipper auf Xbase++ aufzeigst.
Das bedeutet man müsste erstmal alle Texte abändern, ein reines Einstellen des Editors auf ANSI führt ja keine automatische Konvertierung der Zeichen durch.

[brandelh]

das wäre fatal, gerade bei "alten" Quellcode ...
Das bedeutet man müsste erstmal alle Texte abändern, ein reines Einstellen des Editors auf ANSI führt ja keine automatische Konvertierung der Zeichen durch.

Ich mache es auch nur bei neuen Sachen, aber so schlimm ist es auch nicht:

1. Mein Editor ( MED.EXE ) konvertiert auf Wunsch beim Speichern in den anderen Zeichensatz ...
2. ein kleines Programm das alle PRG mit memoread() einließt, die Konvertierung durchführt und speichert ist nicht wirklich problematisch

[AUGE_OHR]

hi,

das wäre fatal, gerade bei "alten" Quellcode. Du müsstest das doch
wissen, wenn Du auf der Developers Conference den Umstieg von Clipper
auf Xbase++ aufzeigst.
Das bedeutet man müsste erstmal alle Texte abändern, ein reines Einstellen des Editors auf ANSI führt ja keine automatische Konvertierung der Zeichen durch.

Ja, aber leider ist das so
Wenn man also File Functionen benutzt die auf Windows zugreifen so wird
ANSI benutzt.
hier mal paar Stellen aus meinen GUI Source

Code: Alles auswählen

Aus Windows Nach DBF

  aMP3 := DIRECTORY(ccPath+ccFile)
  cSeek := ConvToOemCP(UPPER(TRIM(ccPath)+TRIM(ccFile)))
  SEEK(cSeek)
  IF FOUND()
...
  ELSE
      APPEND BLANK
      SCANDBF->W9FULLPATH := ConvToOemCP(UPPER(TRIM(ccPath)+TRIM(ccFile)))
      SCANDBF->W9VIDEO    := ConvToOemCP(UPPER(TRIM(ccFile)))

Low-Level Windows nach DBF

      nHandle := FOPEN(ConvToAnsiCP(cFile),FO_READ+FO_SHARED)

      nError := FERASE(ConvToAnsiCP(cFile))


vom Clipboard nach DBF

      FUNCTION HandleDragDrop(aState,oData,oParent)
          LOCAL aFiles := oData:GetData(XBPCLPBRD_FILELIST)
          LOCAL i,  iMax   := LEN(aFiles)

         FOR i := 1 TO iMax
            //
            // DragDrop return ANSI
            //
            aFiles[ i ] := ConvToOemCP(aFiles[i])

***********************************************************

aus DBF nach Windows

   cSeek := ConvToAnsiCP( WM9DBF->W9FULLPATH)
   IF FILE(cSeek)

low-level DBF nach Windows
   FWrite( nHandle, ConvToAnsiCP(UMSATZ->UKDNAME) )

gruss by OHR
Jimmy