Problem mit CHDIR-Funktion

hRb · Beiträge: 267 Erhaltene Danke: 12

Die Kette der Probleme bei Umstellung von D7 auf XE reißt nicht ab und ich hoffe auf Verständnis, wenn ich in letzter Zeit so häufig Hilfe suche. Es geht um eine simple Standardfunktion Chdir zum Einstellen des Verzeichnisses.

Ich habe in meinem Programm zwei Funktionen, die auf Daten vorgegebener Unterordner zu greifen. Damit nicht jedesmal eine langwierige Ordnervorwahl vorzunehmen ist, kann ich unter Einstellungen die Pfade vorauswählen. Im beigefügten Beipiel habe ich der Einfachheit halber zwei path-Konstante definiert (ggf. anpassen).

Die Befehlsfolge unter Button1 funktionierte unter D7, in dem ich einfach im Opendialog den Filename gesetzt habe. Diese Befehle funktionieren unter XE nicht mehr. Ich muss bei XE - nach dem Opendialog - im angezeigten Feld "Dateiname" (wo ja der pathname steht) erst Return geben, um das Verzeichnis zu wechseln.

Ich habe daher unter Button2 eine geänderte Befehlsfolge versucht, um das Directory vorab einzustellen. Doch hier zeigt sich keine Wirkung. Warum?

Unter Button1 erkenne ich noch eine andere unverständliche Eigenschaft bei der Anzeige des voreingestellten Dateinamens. Er werden sichtbar nämlich nur die letzten ca. 14-15 Zeichen des path-Namens angezeigt (blau markiert). Wenn pathname kürzer als 15-Zeichen, dann natürlich ganz. Man muss erst die Taste Pos1 drücken, um den Pfad vollständig zu sehen. Auch dies ist in XE anders. Wenn die Umstellung des Directory funktionieren würde, dann würde ich dort gleich nur *.suffix eintragen.

Kennt jemand den Effekt und weiß Abhilfe wie ich sofort zum gewünschten Pfad komme?
Gruß hRb

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:

unit Unit1;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.ComCtrls, Vcl.ExtCtrls, IoUtils
  ;

type
  TForm1 = class(TForm)
    Panel1: TPanel;
    RichEdit1: TRichEdit;
    Button1: TButton;
    Button2: TButton;
    OpenDialog1: TOpenDialog;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

const
// im Test auf gültige Ordner anpassen !!
 cPath1='D:\Daten\Delphi7\' ;
 cPath2='C:\Windows\System32\restore\';

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
{funktionsfähige Befehlsfolge unter Delphi7}
begin
 with Form1,  OpenDialog1 do begin
  Filter := 'csv Files ( *.csv)|*.csv|Alle Files( *.* )|*.*';
  DefaultExt := 'csv';
  Filename:=cPath1+'*.csv';
  if Execute then begin {with TForm2.Create(Self) do }
   try
    if FileExists(Filename) then
      Richedit1.Lines.LoadFromFile(FileName);
   finally
   end; end;
end; end;


procedure TForm1.Button2Click(Sender: TObject);
{Directory neu einstellen } // ohne Wirkung
begin
 with Form1,  OpenDialog1 do begin
  Filter := 'csv Files ( *.csv)|*.csv|Alle Files( *.* )|*.*';
  DefaultExt := 'csv';
  Filename:='';  // wenn nicht gelöscht, erscheint willkürlicher Buffertext bzw Text aus Vorgänger-Opendialog
   if TDirectory.Exists(cPath2)
    then ChDir(cPath2);  {'c:\synago7\Datensicherung\*.csv'; }
  if Execute then begin {with TForm2.Create(Self) do }
   try
    if FileExists(Filename) then
      Richedit1.Lines.LoadFromFile(FileName);
   finally
   end; end;
end; end;

end.

Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

hRb · Beiträge: 267 Erhaltene Danke: 12

Da besteht ein Missverständnis! Ich will auch kein Directory einrichten, sondern erreichen, dass ich beim Opendialog im gewünschten Verzeichnis bin und mir die Dateien dieses Ordners angezeigt werden.

Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

hRb · Beiträge: 267 Erhaltene Danke: 12

Hallo Frühlingsrolle,
wieder mal Danke. Wenn ich Opendialog1.InitialDir dem path zuweise, dann funktioniert mein Programm.
Frage mich nur, was dann eigentlich die Funktion Chdir soll bzw. wieso die nicht funktioniert. Es ist ja schön, wenn es bei für neuere Compiler oder neue Betriebssysteme auch neue erweiterte Funktionen gibt, aber die bisherigen Funktionen sollten auch bleiben. Ansonsten kann manh bei Umstellung von Delphi7 auf XE ja keiner Funktion mehr trauen.
Gruß hRb

Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

jaenicke · Verfasst: Sa 02.09.17 01:13

hRb hat folgendes geschrieben :

Ansonsten kann manh bei Umstellung von Delphi7 auf XE ja keiner Funktion mehr trauen.

Insbesondere, wenn man noch with benutzt...

Insbesondere wenn man mehrere with-Objekte benutzt und dann noch eines vom gleichen Typ wie die Klasse, in der man gerade ist, ist das fast schon Folter für jeden Leser des Quelltexts... ;-)

mandras · Verfasst: Sa 02.09.17 01:38

Bist Du dir sicher daß es am Delphi liegt?

ich hatte einmal ähnliches (allerdings nicht im Rahmen eines Delphi-Wechsels) da war es ein "Feature" von MS
wobei das Initial Dir nur beim alleresten Programmstart verwendet wurde und danach immer das Verzeichnis
genommen wurde was beim ersten Klick auf "OK" des Dialogs ausgewählt war.
Das fiel mir aber auch erst auf nach ewigen Tests.

Hast Du evtl. gleichzeitig auf ein neu aufgesetztes System gewechselt? Wenn ja prüfe einmal
ob nun beim 2. oder 3. mal das "alte" Programm (also die Exe die mit dem älteren Delphi compiliert wurde) nicht
auch das gleiche Problem aufweist.

jaenicke · Verfasst: Sa 02.09.17 02:09

Das aktuelle Arbeitsverzeichnis wurde früher benutzt, ja. Dafür muss man aber den alten Opendialog benutzen. Der neue Opendialog in Windows versucht den Benutzer zu unterstützen indem versucht wird ein passendes Verzeichnis als initiales zu benutzen, sofern kein anderes als InitialDir gesetzt ist.

Delphi 7 hat noch den alten Dialog verwendet. Das sieht man ja auch, wenn man ihn aufruft, wie alt der ist.

haentschman · Verfasst: Sa 02.09.17 10:12

Moin...

@jaenicke:

Zitat:

Insbesondere, wenn man noch with benutzt...
Insbesondere wenn man mehrere with-Objekte benutzt und dann noch eines vom gleichen Typ wie die Klasse, in der man gerade ist, ist das fast schon Folter für jeden Leser des Quelltexts...

Ich stimme dir zu.

Aber...Wenn ich das in der DP gesagt hätte, wäre ich schon geteert und gefedert worden. :shock:

jaenicke · Verfasst: Sa 02.09.17 14:01

Gibt dazu ja auch entsprechende Beiträge von Marco Cantù und anderen Teammitgliedern der Entwickler von Delphi, die dies entsprechend so geschrieben haben.

haentschman · Verfasst: So 03.09.17 08:41

Moin...

Zitat:

Gibt dazu ja auch entsprechende Beiträge von Marco Cantù...

...bitte Links wo "ist das fast schon Folter für jeden Leser des Quelltexts" das so steht.

hRb · Beiträge: 267 Erhaltene Danke: 12

Hallo, war einige Tage weg. Das ist ja eine Wolke an Antworten! Nun schön der Reihe nach:
1. Die Diskussion um "with" kenne ich an anderer Stelle im Forum. Da habe ich meine eigene Meinung und bin auch viel zu schreibfaul um auf diese elegante, legale Form zu verzichten (habe auch noch nie mit with-Anweisungen Probleme gahabt). Weite daher das Thema nicht aus, zumal eine andere schreibweise mein Problem nicht behoben hätte.

Zitat:

das ist fast schon Folter für jeden Leser des Quelltexts

Du bist doch Profi: dann schafft Du dies! - trau es Dir zumindest zu

2. Mir ging es um den Wechsel eines Verzeichnisses im Zusammenhang mit dem Opendialog, der plötzlich nicht mehr funktionierte. Ok, die bisherige Programmierung (im Opendialog den kompletten path-Namen in Filename eintragen), war einem Lehrbuch entnommen und funktionierte. InitialDir kam da nicht vor und wenn etwas funktioniert suchte man ja nicht nach Alternativen.

Zitat:

"InitialDir kommt auch schon in Delphi vor"

3. stimmt, habe ich jetzt auch gefunden, aber siehe Pkt 2.

Zitat:

Die Methode ChDir() hat an dieser Stelle auch nichts zu suchen.

4. mag sein, aber die Begründung fehlt mir, bzw. den Hinweis auf eine Konsolenanwendung verstehe ich nicht - auch warum ChDir in dieser Befehlsfolge nicht funktioniert.

Zitat:

Hast Du evtl. gleichzeitig auf ein neu aufgesetztes System gewechselt?

5. Nein, stehe nur vor der Notwendigkeit ein viele Jahre altes bewährtes Programm auf WIN10 anzupassen und nutze dazu neuen Compiler. Da freut man sich, wenn der Compiler überhaupt ein startbares exe liefert.

Zitat:

Delphi 7 hat noch den alten Dialog verwendet. Das sieht man ja auch, wenn man ihn aufruft, wie alt der ist.

Wenn der neue Opendialog ein wenig anders aussieht, muss man ja nicht an seiner bisherigen Funktion zweifeln.

Zitat:

Bist Du dir sicher daß es am Delphi liegt?

6. Ja ganz sicher, denn ich habe auf meinem neuen WIN10-Rechner drei Compiler installiert (D7, XE3, Berlin) und so habe ich den unmittelbaren vergleich. D7-Programme laufen auch unter WIN10, wenn man qtintf70.dll in den System32-Ordner kopiert.

Summa summarum: Die Lösung habt ihr mir gegeben. Danke, bin immer wieder beindruckt über die selbstlose Hilfe.
PS: wenn jemand noch eine Lösung kennt, wie man hlp-Dateien (winhlp32.exe) unter Win10 zum Laufen bringt? Unter Win7 und 8.1 gab es noch Lösungen. Aber alle Versuche Win10 auszutricksen scheiterten. Grund: ich muss häufig offline arbeiten und brauche die Delphi7-Hilfe. Oder lässt sich die aktuelle Hilfe auch downladen und örtlich installieren?

jaenicke · Verfasst: Di 05.09.17 19:50

hRb hat folgendes geschrieben :

PS: wenn jemand noch eine Lösung kennt, wie man hlp-Dateien (winhlp32.exe) unter Win10 zum Laufen bringt?

Siehe hier ganz unten, da habe ich das beschrieben:
www.entwickler-ecke....llieren_89408,0.html

haentschman · Verfasst: Di 05.09.17 21:31

Moin...

Zitat:

ich muss häufig offline arbeiten und brauche die Delphi7-Hilfe

...brauchst du nicht.

Zitat:

Oder lässt sich die aktuelle Hilfe auch downladen und örtlich installieren?

www.delphipraxis.net/dp_reference.php
...machmal frage ich mich wie man ohne das leben kann. :zwinker:

Du kannst auch die DP-Referenz als Suchprovider in den Browser integrieren. :zustimm:

Beispiel TEdit:
www.delphipraxis.net...ence.php?query=tedit

Nachtrag:
Stop. Du meinst ohne Internet? Das gibt es noch? :gruebel:

hRb · Beiträge: 267 Erhaltene Danke: 12

Hallo
1. haentschman:

Zitat:

Du meinst ohne Internet? Das gibt es noch?

Ja, gibt es noch! Bin Rentner und sitze gern an ruhiger Stelle im Grünen. Wirst Vorzüge hoffentlich auch noch kennen lernen!

2. jaenicke:
habe Deinen Beitrag aufmerksam gelesen. Meine alles richtig gemacht zu haben, lande aber bei jedem Start von Winhlp32 auf der MS-Homepage:
support.microsoft.co...re-not-included-or-h
Dort kann man entnehmen, dass es unterschiedliche Winhlp-Versionen gibt für 32/64, für Vista, Win7, Win8, Win8.1. Vielleicht genügt es ja nicht irgendeine Version zu kopieren, sondern die "Richtige". Meine Winhlp32.exe ist 10240 Byte lang.
Auf obiger Seite wird auch die manuelle Installation beschrieben. Dabei sind Einträge in der Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft erforderlich. Auch dies habe ich vorgenommen - ohne Erfolg.
Deshalb nochmals Rückfrage zum "Besitzer" und den geschwärzten Stellen: wenn ich bei mir auf "ändern" gehe, dann erscheint ein Eingabefeld mit Desktop-xyz (xyz=6stelliger Alpha-numText). Was gebe ich da genau ein? Mein User-Name? Und da ich als Admi arbeite, dann gleiches nochmal beim Admi?

Es will einfach nicht funktionieren!

Ehemaliges Mitglied Erhaltene Danke: 1

- Nachträglich durch die Entwickler-Ecke gelöscht -

jaenicke · Verfasst: Do 07.09.17 05:55

hRb hat folgendes geschrieben :

habe Deinen Beitrag aufmerksam gelesen. Meine alles richtig gemacht zu haben, lande aber bei jedem Start von Winhlp32 auf der MS-Homepage:

Lösche bitte einmal die Datei im Windowsverzeichnis und prüfe (Aktualisieren - F5), ob sie wirklich nicht mehr da ist, bevor du die neue Datei kopierst.
Leider zeigt Windows bei Rechtekonflikten nicht unbedingt an, dass die Datei gar nicht überschrieben werden konnte.

Ich vermute daher, dass dort noch die Originalversion liegt.

Von welcher Windowsversion hast du die Datei geholt?

hRb hat folgendes geschrieben :

Deshalb nochmals Rückfrage zum "Besitzer" und den geschwärzten Stellen: wenn ich bei mir auf "ändern" gehe, dann erscheint ein Eingabefeld mit Desktop-xyz (xyz=6stelliger Alpha-numText). Was gebe ich da genau ein? Mein User-Name? Und da ich als Admi arbeite, dann gleiches nochmal beim Admi?

Die geschwärzten Stellen enthalten lediglich meinen Rechnernamen. Das dürfte bei dir Desktop-xyz sein.
Als neuen Benutzer solltest du deinen eigenen Benutzernamen eintragen, ja.

Ich hoffe du meinst mit "als Admin arbeiten" nicht, dass du die UAC bzw. Benutzerkontensteuerung deaktiviert hast oder mit dem versteckten Administrator Konto arbeitest. Damit handelst du dir nur unnötige Probleme ein.
Dann kann es durchaus sein, dass das nicht wie beschrieben funktioniert.

Frühlingsrolle hat folgendes geschrieben :

Wenn du nicht gerade Win10 nutzt,

Doch, es geht um Windows 10. Das hatte er in seiner Frage doch explizit geschrieben, deshalb ja auch mein Verweis auf die Anleitung für Windows 10.

jaenicke hat folgendes geschrieben :

hRb hat folgendes geschrieben :

PS: wenn jemand noch eine Lösung kennt, wie man hlp-Dateien (winhlp32.exe) unter Win10 zum Laufen bringt?

Siehe hier ganz unten, da habe ich das beschrieben:
www.entwickler-ecke....llieren_89408,0.html

hRb · Beiträge: 267 Erhaltene Danke: 12

Hallo zusammen,
zunächst die gute Nachricht: ich habe es geschafft. Winhlp32 läuft auch unter WIN10!
Kann vielleicht noch etwas "Erhellendes" beitragen, denn es gab unterschiedliche Lösungen:
Bei den Kollegen www.delphipraxis.net...dows-10-oeffnen.html
wird eine rar-Datei zum download angeboten. Entpackt man die, so findet man drei Dateien
- Install.cmd
- winhlp32.exe vom 4.8.2009 Länge=296.960 Byte
- winhlp32.exe.mui 4.8.2009 Länge= 35.328 Byte
Ich habe zwei Rechner: eines mit Betriebssystem WIN7 das per update auf WIN10 umgestellt wurde. Dort lief die Datei cmd (job) auf Anhieb und die hlp-Dateien ließen sich auf dem System sofort anzeigen.

Etwas hartnäckiger verhielt sich mein neues WIN10-Notebook. Dort verweigerte das Betriebssystem einige job-Aufrufe (man frage mich nicht warum), so dass ich in der cmd-Datei aufgeführten Schritte mit Admi-Rechten manuell ausführte:
- Suchen in C:\windows nach winhlp*.* (alle .exe, .mui löschen). Beachte ich fand auch exe und mui in einem Odner
C:\Windows\WinSxS\x86_microsoft-windows-winhstb.resources_.... (mit sehr langer NR), die aber nur 3 kB lang ist
- winhlp32.exe nach c:\windows und winhlp32.exe.mui nach C:\Windows\de-DE kopieren (nicht en-EN!)
- danach regedit starten und händisch die in der cmd-Datei eingetragenen Schlüssel eingeben.
Letzteres war ein wenig aufwändig (sehr sorgfältig arbeiten), aber nun schnurrt das ganze auch auf diesem Rechner.
Anmerkung: mehrere Versuche auf ähnliche Art scheiterten, weil ich offensichtlich nicht die "richtige" exe bzw. mui hatte.
Und noch ein Hinweis: die install-Pakete auf der Microsoft-Homepage scheitern, weil in der cmd-Datei auf Betriebssystemversion abgeprüft wird. Und in diesem Job wird auf Win10 nicht mehr geprüft. Folgrich error.
Schließe damit das Thema ab. Danke an alle!

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme