Problem mit OpenDialog

[xi.xi]

Hallo Leute!

Mein kleines Projekt stürzt nach rund 1min ab, nachdem ich versucht habe eine Datei zu öffnen. Kann mir jemand den Grund sagen?
Würde mich echt freuen. Ich bekomm schon graue Haare. Der Fehler sollte bei Open Dialog sein, denn ohne das öffnen einer Datei läuft es.

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

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

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin

  if OpenDialog1.Execute() then begin

  end;

end;

end.

Danke schon mal !!

[hoika]

Hallo,

schicker Quellcode ...
kein bisschen Info ;)

Zitat:

nachdem ich versucht habe eine Datei zu öffnen

Der Code für Öffnen / Auslesen würde mich eher interessieren.


Heiko

[DeddyH]

An dem bisschen Code kann es eigentlich nicht liegen. Wie sieht denn der Teil zwischen begin und end aus?

[xi.xi]

Hat denn der Code zwischen begin und end eine relevanz, wenn es schon ohne dem Code nicht funkioniert? Hab den noch gar nicht geschrieben!!!

[hoika]

Hallo,

was heisst das denn nun ?

Ist der Code oben dein "kleines" Projekt ?
Also bei mir würde das nicht abstürzen ;)

Es sei denn, man öffnet ein leeres CD-Laufwerk innerhalb des Open-Dialoges,
dann würde aber eine Exception oder was auch immer kommen.

Ein Absturz ist unwahrscheinlich.

Entweder du verschweigst uns Code oder (wenn das wirklich der ganze Code ist),
es ist etwas anderes faul.

Viell. beschleunigt dein Öffnen-Code das ganze ?

Ich tippe mal auf fehlerhafte SetLength-Benutzung (?)

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
 // was passiert hier ???

  if OpenDialog1.Execute() then begin

  end;

end;

Heiko

[xi.xi]

Es tut mir echt leid das ich nicht mehr infos habe und ich weiss, dass es echt schwer ist daran was zu finden.
Aber mehr hab ich wirklich nicht! Ich bin ja auch am suchen. Dachte das jemand das Problem schon mal hatte.
Ich habe das Programm jetzt mal auf Win Vista laufen lassen und da läuft es auch ohne Probleme. Bei Win7 stürzt es ab.

Hab im Protokoll nur gesehen das die Zeile
Modul entladen: UNKNOWN_MODULE_16. Prozess Project1.exe (1152)
nicht unter Vista vorkommt und da schmeißt Win7 das Programm raus.

Danke Euch! Ich werd mal weiter suchen!

[p80286]

Also etwas mehr Infos dürfen da schon kommen.
Wenn das Programm den Inhalt hat, den wir hier sehen, dann funktioniert es.

Wenn dann etwas "schiefläuft","abstürzt" oder sich sonst irgendwie nicht wie erwartet verhält, sollte man sich vergegenwärtigen, daß der Fehler meist vor der Tastatur sitzt. In diesem Falle, auf welche Datei willst du zugreifen?
Hast Du die notwendigen Rechte, gibt's die Datei überhaupt etc.

Gruß
K-H

[hoika]

Hallo,

noch mal die Frage an den TE,
ist das wirklch das ganze Programm ?

Wenn nicht und du willst uns nicht mehr Code geben,
wie sollen wir dann helfen ?


Heiko

[DeddyH]

So wie ich das verstanden habe, ist das bereits der ganze Code. Nun wäre einmal interessant zu wissen, welche Versionen von Delphi und Win 7 das sind, die sich nicht mögen.

[xi.xi]

Hallo DeddyH

Ja so ist es! Ich hab Delphi 2009 und Windows 7 Ultimate. Um zum öffnen einer Datei kann man sich einfach eine aussuchen. Kann auch eine Leere Textdatei sein. (egal)
Denke mal das sich da was nicht verträgt mit win7.
Hat einer win7 und kann das nachvollziehen?

Danke

[Andreas L.]

Guck mal hier: http://www.delphipraxis.net/internal...084178#1084178

Vielleicht ist das bei dir auch der Fall.

[xi.xi]

Die Debuger einstellungen "Debug in spawned Prozessen" ist ausgeschalten. Die Datei kann üball auf dem Rechner liegen, immer das gleiche Problem.

Aber guter Tipp. Danke für die Hilfe!
War es aber leider nicht!

[Bbommel]

Was heißt denn eigentlich "Programm stürzt ab"? Wie genau äußert sich das? Gibt es eine Fehlermeldung, friert das Programm ein, oder "verschwindet" es einfach? Erscheint denn eigentlich der OpenDialog oder wird der erst gar nicht angezeigt?

Delphi 2009 & Win7 geht jedenfalls, habe ich hier auch.

Bis denn
Bommel

[Frankfurtoder]

Passiert der "Absturz" nur wenn du im Debugger bist oder auch außerhalb der IDE?

[xi.xi]

Hab jetzt mal ohne Debugger laufen lassen und da läuft alles.
Also bestimmt andere Debugger Einstellunge.

Aber so komme ich erst mal weiter. Danke Frankfurtoder

[maddin1502]

Hallo, ich weiß dieses Thema ist schon etwas älter, ist aber das Neuste, das ich finden konnte.

Ich habe das gleich Problem mit dem OpenDialog (mit dem SaveDialog ists das Gleiche).
Egal was für Quellcode zwischen den Zeilen steht. Hier ein einfaches nichts machendes Testprogramm:
DAS IST DAS KOMPLETTE PROGRAMM, ALSO BITTE NICHT DIE STANDARTANTWORT, DASS HIER CODE VERHEIMLICHT WIRD!!!
Wer es nicht glaubt sollte es doch erstmal kurz testen (Win7+Delphi2009)

Code:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

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

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  if form1.OpenDialog1.Execute then
  begin

  end;
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  if form1.SaveDialog1.Execute then
  begin

  end;
end;

end.

Und nun zur genauen Fehlerbeschreibung.
1. Ich öffne das Projekt
2. Klicke auf Start (F9, der kleine grüne Pfeil) --> Programm startet
3. klicke auf button1 ODER button2 (ist egal, beides führt zum gleichen Fehler)
4. schließe den entsprechend geöffneten Dialog
5. schließe das ausgeführte Programm per "X"

Nun spuckt mir Delphi die Fehlermeldung aus:
http://s5.directupload.net/images/100615/m9u2c9ig.jpg

Egal ob man nun ja oder nein drückt hängt sich Delphi beim nächsten bedienen auf, z.B.: wenn man Delphi dann schließen möchte oder das Projekt neu Starten (F9) möchte --> Freeze und man bekommts nur noch mit Gewalt geschlossen. Ob ein weiterarbeiten und speichern ohne weiteres möglich ist wieß ich nicht, habs nie probiert und wäre mir auch einfach zu unsicher zwecks Datenverlust.

Ohne Debugger läufts übrigegens und auch außerhalb von Delphi, wenn man dann einfach nur die EXE ausführt.
Es ist ja aber nicht Sinn und Zweck der Sache den Debugger immer auszuschalten...

Mein System ist WIN 7 Professional + Delphi 2009

Grüße
Maddin1502

[daywalker9]

Das ist ein Problem von Delphi auf Win 7 X64. Hier gibt es einen Workaround um diesen Fehler zu vermeiden:


Debugger Workaround

[bernau]

Hat nicht direkt was mit deinem Fehler zu tun aber

Du schreibst

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
  if form1.OpenDialog1.Execute then
  begin

  end;
end;

form1 kannst du weglassen.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
  if OpenDialog1.Execute then
  begin

  end;
end;

Du greifst direkt auf die instanzierte Variable zu. Was passiert, wenn das TForm1 neu instanziert wird? Dann greift die neue Instanz auf OpenDialog1 von form1 zu und nutzt nicht die eigene instanz. Noch schlimmer, wenn Form1 nicht das Hauptformular ist, kann es ja sein, daß form1 zufällig mal freigegeben wird, die andre Instanz noch auf form1 zugreift. Dann knallt's.

[maddin1502]

OK, aber was jetzt mit instanziert gemeint ist, versteh ich nicht. Habe zwar schon ein paar Programme geschrieben,
aber mit den Wort Instanz ansich kann ich nichts anfangen. Vielleicht kannst du es nochmal für Anfänger erzählen.
Ich habe es mir im Prinzip aus groben Grundkenntnissen selber beigebracht mit Delphi zu programmieren,
da sind ein paar Fachbegriffe leider auf der Strecke geblieben...

Ich nutze es immer so, weil nun mal der Opendialog auf Form1 liegt (bei mir war Form1 bisher immer das Mainform), das habe ich bisher bei allen Proceduren und Komponenten so gemacht. Arbeite ich auf einem andere Form und möchte den Opendialog ansprechen, muss ich dem Programm doch mitteilen wo er liegt und dies muss ich doch nunmal so machen oder nicht?!? Und wenn man eigene Proceduren im Stile "procedure oeffnen" ist es doch zwingend notwendig "Form1." davor zu setzen, sonst findet die procedure keinerlei Komponenten (heißt ja nun auch nicht TForm1.oeffnen)...

Naja, ich schaue mir mal den Debuger Workarround an.
Danke erstmal für die Hilfe.

EDIT:
@daywalker9, DANKE ES GEHT. Habe das automatische Programm genutzt zum verändern der Datei und jetzt kommt keine Fehlermeldung mehr und Delphi läuft wunderbar. SUPER. (Und natürlich hab ich ein 64bit System, fehlte in meiner Beschreibung)

[DeddyH]

TForm1 ist die Klasse, Form1 die Instanz der Klasse, also das konkret erzeugte Objekt. Zur Verdeutlichung:

Delphi-Quellcode:

type
  TMyClass = class  //Definition der Klasse
  end;

...
var Class1, Class2: TMyClass; //2 Variablen vom Typ der Klasse
begin
  Class1 := TMyClass.Create; //Anlegen einer Instanz und Speicherung in der 1. Variablen
  try
    Class2 := TMyClass.Create; //Anlegen einer weiteren Instanz und Speicherung in der 2. Variablen
    try
      ShowMessage('Wir haben jetzt 2 Instanzen von TMyClass.');
    finally
      Class2.Free;
    end;
  finally
    Class1.Free;
  end;
end;

[xZise]

Moin,
ich will jetzt nicht als obermeckerer rüberkommen. Aber einmal mach einen neuen Thread auf ;) Zweitens hänge Bilder bitte als Anhang an.

Und mit "instanziert" meinen wir, dass wenn du jetzt diese Form nochmal erstellst, dann passt das hinten und vorne nicht mehr. Es müsste folgendermaßen zu demonstrieren sein (in der Projekt Datei):

Delphi-Quellcode:

[...]var
  f : TForm;

begin
  [...]
  Application.CreateForm(TForm1, f);
  Application.CreateForm(TForm1, form1);
  form1.Free;
  [...]

Habe gerade kein Delphi hier, aber jetzt dürfte es nicht mehr funktionieren, weil form1 nicht mehr existiert, aber der OpenDialog umbedingt die von form1 haben will.

Oder anders ausgedrückt: Dein Programm versucht von form1 den OpenDialog zu holen. Aber die Form selber kennt ja bereits den OpenDialog und muss nicht (quasi) erst das Bruder-/Schwesterformular nach den Dialog fragen.

MfG
Fabian

[Luckie]

Zitat:

Zitat von maddin1502 (Beitrag 1028948)

Und wenn man eigene Proceduren im Stile "procedure oeffnen" ist es doch zwingend notwendig "Form1." davor zu setzen, sonst findet die procedure keinerlei Komponenten (heißt ja nun auch nicht TForm1.oeffnen)...

Nicht wenn man sein Konzept etwas durchdenkt. Methoden der Form-Klasse kennen natürlich die Komponenten der Form. Ist deine Prozedur eine Methode der Form-Klasse sind in ihr auch die Komponenten bekannt. Das überflüssige davor schreiben der Instanz kann sogar zu Fehlverhalten führen und sollte deshalb auch unterlassen werden.

[Bbommel]

Zitat:

Zitat von maddin1502 (Beitrag 1028948)

Ich nutze es immer so, weil nun mal der Opendialog auf Form1 liegt (bei mir war Form1 bisher immer das Mainform), das habe ich bisher bei allen Proceduren und Komponenten so gemacht. Arbeite ich auf einem andere Form und möchte den Opendialog ansprechen, muss ich dem Programm doch mitteilen wo er liegt und dies muss ich doch nunmal so machen oder nicht?!? Und wenn man eigene Proceduren im Stile "procedure oeffnen" ist es doch zwingend notwendig "Form1." davor zu setzen, sonst findet die procedure keinerlei Komponenten (heißt ja nun auch nicht TForm1.oeffnen)...

Es gibt natürlich auch Situationen, in denen es gar kein Problem oder sogar richtig und nötig ist, wenn du auf eine Instanz von TForm1 zugreifst (also auf form1), um dann auf z.B. den Öffnen-Dialog, der auf diesem Form liegt, zugreifen zu können. Ein Beispiel kann das sein, was du selber geschrieben hast, nämlich wenn du aus einem anderen Form auf dieses zugreifen willst (und dir zu dem Zeitpunkt auch sicher sein kannst, dass Form1 existiert).

In vielen anderen Situationen ist es aber überflüssig und schafft potentielle Fehlerquellen, daher sollte man es sich schlicht erst gar nicht an solchen Stellen angewöhnen. Dein Beispiel ist insofern ganz passend: form1.OpenDialog1.Execute funktioniert zwar bei so einem einfachen Programm problemlos, ist aber überflüssig, weil innerhalb der Klasse TForm1 das OpenDialog ja bekannt ist.

Wenn du dann irgendwann mit komplexeren Programmen arbeitest, in denen du Forms zur Laufzeit erzeugst und freigibst oder ein und dieselbe Form vielleicht mehrfach verwendest, dann fallen dir genau diese Dinge auf die Füße.

Auch dein anderes Beispiel mit der eigenen "procedure oeffne" ist ganz interessant, denn wahrscheinlich wäre es sinnvoll, diese auch als Methode von TForm1 umzusetzen, wodurch auch hier kein "form1" mehr nötig wäre. (Eine Methode ist eine Prozedur oder Funktion einer Klasse, um kurz nicht für neues Begriffswirrwarr bei dir zu sorgen).

Bis denn
Bommel

[maddin1502]

@ xZise
warum einen neuen Thread aufmachen, wenn der hier genau meinen Fehler anspricht??? Und gelöst war der hier auch nicht, da man immer eine zu ungenaue Fehlerbeschreibung reinsetzt.
Bei meinen Programmen ist Form1 immer da :), das verschwindet nur wenn ich das Programm schließen will. Aber ist schon gut Jungs, ihr habt halt mehr Ahnung von der Materie... da merke ich erstmal wie Noobig doch mein Wissen ist, aber für meine Bedürfnisse reichts.

@Bbommel
Tja ich habe mir es so angewöhnt, weil ich meist eine Procedure über eine Komponente schreibe (Bsp: Button1Click...) und dann merke, dass ich die hier angewanden Sachen doch auch noch hier und da gerne automatisch machen würde. Jetzt mal ein kleines aktuelles Beispiel: ein Sortieren Button, der meine Tabelle alphabetisch sortiert. Der Button ist auf Form1 und die Tabelle auch, dann ist mir schon klar, dass ich "form1." einfach weglassen kann.
Aber warum nen Button lassen, wenn man es doch immer automatisch (nach einer änderung des Tabelleninhalts) machen kann. Also Button weg und ne übergreifende "procedure sortieren" her. Wenn dort jetzt "form1." fehlt ists auch blöd.

Zitat:

denn wahrscheinlich wäre es sinnvoll, diese auch als Methode von TForm1 umzusetzen

Also sollte ich eine solche allgemeine "procedure sortieren" (aufgeführt unter Var) dann eher hier einsetzen, aber WIE?

Code:

  
  type
  Speicherort=record
    pfad: string[255];
    end;
  TForm1 = class(TForm)
   StringGrid1: TStringGrid;
   ...
   ...
   ...
   procedure PageControl1Change(Sender: TObject);
   ??????HIER HIN??????????????
  private
    { Private declarations }
  public
    { Public declarations }
  end;

Einfach "procedure sortieren" geht dann ja nicht mehr, da müssten ja noch Werte in Klammern dahinter, weiß halt nur nicht welche


Ist jetzt aber nun wirklich etwas Offtopic...

[Bbommel]

Zitat:

Zitat von maddin1502 (Beitrag 1028967)

Zitat:

denn wahrscheinlich wäre es sinnvoll, diese auch als Methode von TForm1 umzusetzen

Also sollte ich eine solche allgemeine "procedure sortieren" (aufgeführt unter Var) dann eher hier einsetzen, aber WIE?

Genau so war es von mir gemeint. Deine deine neue Sortier-Prozedur ist ja auch genau für das TForm1 weil diese dessen Funktionalität erweitert und auf dem Form immer eine Liste sortiert. Du baust sie dann so ein:

Delphi-Quellcode:

  type
  Speicherort=record
    pfad: string[255];
    end;
  TForm1 = class(TForm)
   StringGrid1: TStringGrid;
   ...
   ...
   ...
   procedure PageControl1Change(Sender: TObject);
  private
    { Private declarations }
  public
    { Public declarations }
    procedure Sortieren;
  end; 

[...]

procedure TForm1.Sortieren;
begin
  [...]
end;

Parameter brauchst du für die Prozedur nicht zwingend - nur dann, wenn du mit den Parametern auch etwas machst, genau wie in jeder anderen Prozedur auch.

Du könntest die Prozedur auch in den Private-Bereich einbauen. Das hängt dann davon ab, ob du möchtest, dass "fremde" Forms darauf zugreifen dürfen (public) oder nicht (private).

Bis denn
Bommel

[maddin1502]

Ach ja so war das. Habe nicht mehr gewusst, dass es unter public oder privat muss. Hatte ich mal in der Schule, aber leider wieder vergessen.

Wo wir gerade bei CreateForm usw waren (ich weiß nicht ob man das dazu braucht). Gibts eine Möglichkeit das MainForm zu schließen und hinter wieder zu öffnen? Mal ein Beispiel was ich zurzeit gerade brauche. Ich möchte einen "Neu" Button anlegen, der alles wieder so Zurücksetzt, wie es beim Öffnen des Programms war. Gibts da eine einfache und schnelle Methode dafür (Form1 neu laden/kreieren/erstellen oder so)? Ich könnte auch allen Inhalt der Tabellen löschen und manuell alles zurücksetzen, wäre aber keine elegante Lösung.

[David Martens]

@maddin1502:
1.
um auf Post #19 zurückzukommen:

Zitat:

Ich nutze es immer so, weil nun mal der Opendialog auf Form1 liegt
...
(heißt ja nun auch nicht TForm1.oeffnen)...

Der Opendialog liegt nicht auf Form1, sondern gehört zum Objekt TForm1. Jedesmal wenn du eine Instanz von TForm1 erzeugst d.h. den Speicher für das Objekt bereitstellst und und und,
Das machst du mit:

Delphi-Quellcode:

Application.CreateForm(TForm1, Form1);

dann wird in dieser Instanz auch ein neuer Opendialog erzeugt. Das ist ja gerade der Witz an OOP.

Dein erstens Posting kann nicht funktionieren weil:

Delphi-Quellcode:

form1.OpenDialog1.Execute

heist: du willst den OpenDialog1 aus der Variable form1 ausführen. In der Deklaration ist der OpenDialog1 aber privat:

Delphi-Quellcode:

  TForm1 = class(TForm)
    ...
    OpenDialog1: TOpenDialog;
    ...

Daher kein Zugriff. Ist ja auch so gewollt.

2. zu #26:
Das ist nun wirklich ein neuer Thread, aber um die Frage zu beantworten.
Nein, du kannst kein Objekt zerstören und dann aus dem zerstörten Objekt heraus sichselber wieder aufmachen. Denk' mal drüber nach!!! Das einzig was du machen kannst, was aber noch unsauberer ist, du kannst ein Objekt erzeugen, dann dein MainForm schließen und es dann von dem Objekt wieder öffnen lassen. ABER:
Du solltes immer eine Inizialisierungsmethode schreiben die alles wohldefiniert anfangen lässt.

Gruß David

[maddin1502]

@David Martens
Ich will jetzt nicht klugscheißen, aber bei mir geht das mit dem "form1.opendialog1.execute".
Habs gerade nochmal mit einen meiner älteren Programme getestet:

Code:

if form1.opendialog1.Execute then
begin
        assignfile(f,form1.opendialog1.FileName);
        reset(f);
        if filesize(f)>0 then
        begin
        read(f,ergebnisse);
        form1.StringGrid1.ColCount:=strtoint(ergebnisse.zellen[0]);
                for i:=1 to (stringgrid1.RowCount) do
                begin
                        inhalt:=ergebnisse.Zellen[i];
                        for j:=1 to (stringgrid1.ColCount-1) do 
                        begin
                                if pos('/',inhalt)=0 then
                                begin
                                stringgrid1.Cells[j,i-1]:=Inhalt;
                                end;

                                if pos('/',inhalt)>0 then
                                begin
                                stringgrid1.Cells[j,i-1]:=copy(inhalt,1,pos('/',inhalt)-1);
                                delete(inhalt,1,pos('/',inhalt));
                                end;
                        end;
                end;
        end;
        closefile(f);
end;

Vielleicht liegt es daran, dass meine Programme einfacher strukturiert sind. Das mit dem "Objekt orientiert Programmieren" versteh ich immer noch nicht so genau, will einfach nicht in meine Rübe rein, was das nun genau heißt.

Zitat:

Nein, du kannst kein Objekt zerstören und dann aus dem zerstörten Objekt heraus sichselber wieder aufmachen. Denk' mal drüber nach!!!

Das ist mir schon klar, dass ein zerstörtes Objekt sich nicht selber weiderherstellen kann. Zu dem Punkt wo der Wiederherstellungsbefehl kommen müsste, gibts ja nichts mehr, wo dieser Befehl stehen könnte (Der wäre dann auch mit zerstört).
Aber jetzt mal rein theoretisch, könnte sich ein Form selbst nochmal aufrufen? Ist jetzt so gedacht, dass man zuerst einen "Zwilling" öffnet und das alte Form dann schließt.

[David Martens]

ok, nochmal fürs Verständnis: versuch es mal hiermit http://www.delphi-treff.de/object-pa...torientierung/

[Bbommel]

Hi David,

auch wenn wir jetzt ein bisschen weg vom Thema sind, muss ich deinen vorletzten Post doch noch mal korrigieren, sonst ist der arme Maddin ganz verwirrt und wundert sich, warum seine Programme überhaupt funktionieren. ;)

Zitat:

Zitat von David Martens (Beitrag 1029109)

Dein erstens Posting kann nicht funktionieren weil:

Delphi-Quellcode:

form1.OpenDialog1.Execute

heist: du willst den OpenDialog1 aus der Variable form1 ausführen. In der Deklaration ist der OpenDialog1 aber privat:

Delphi-Quellcode:

  TForm1 = class(TForm)
    ...
    OpenDialog1: TOpenDialog;
    ...

Daher kein Zugriff. Ist ja auch so gewollt.

Was du schreibst, stimmt so aus zwei Gründen eigentlich nicht:

1. Wenn du in Delphi neue Komponenten hinzufügst, dann erscheinen die im Quellcode an einer Stelle in der Klassendefinition, bevor die Sichtbarkeit explizit angegeben wurde. Damit sind sie dann nicht "private", sondern "published" oder "public", also sichtbar und von außen verfügbar.
2. Selbst wenn der OpenDialog1 nur "private" wäre, dann wäre er innerhalb der gleichen Unit auch von außen durchaus sichtbar, also auch hier keine Probleme für den Code von Maddin.

Das macht zwar Maddins bisheriges Vorgehen nicht unbedingt richtiger, aber funktionieren tut es bei kleinen Projekten ja erst mal schon.

Ich hoffe, dass das jetzt nicht zu klugsch***erisch rüberkam, ich wollte nur verhindern, dass Maddin noch stärker verwirrt wird, als eh schon. ;)

Bis denn
Bommel

[xZise]

Zitat:

Zitat von maddin1502 (Beitrag 1028967)

@ xZise
warum einen neuen Thread aufmachen, wenn der hier genau meinen Fehler anspricht??? Und gelöst war der hier auch nicht, da man immer eine zu ungenaue Fehlerbeschreibung reinsetzt.

Naja das ist ja noch besser ;) wenn du in einem ungelösten Thread eine neue (andere) Frage aufwirst.

Zu deinem Sortieren: Du könntest das auch allgemein machen, aber dann würde ich als Parameter das zu sortierende Objekt übergeben. Dadurch kannst du das theoretisch wiederverwenden.

Also im allgemeinen würde ich halt möglichst nie auf globale Variablen zugreifen, sondern alles als Parameter oder als Attribut einer Klasse implementieren.

MfG
Fabian

[maddin1502]

Erstmal rießigen Dank für die Hilfe und sorry für die Off Topic Frage. Werde mich dann wohl mal näher mit OOP beschäftigen wenn ich Zeit habe, aber bisher brauchte ich es nicht (oder ich nutze es schon unwissentlich).

Würde sagen, Problem gelöst, lag nur an kleiner Macke zwischen Win7 64bit und Delphi.

[myownshadow]

Hallo !
Ich habe seit einigen Wochen nun auch dieses Problem mit dem OpenDlg. Nutze aber W7-32.
Leider funktioniert der Link auf den Workaround nicht mehr.

Bei mir erscheint, nach jedem OpenDlg Aufruf die Meldung "Das Programm funktioniert nicht mehr ..."
Ist unerklärlich, da mein Program seit langem einwandfrei funktioniert. Ich benutze Delphi mit dem RAD Studio 2010

[Dalai]

Zitat:

Zitat von myownshadow (Beitrag 1215674)

Leider funktioniert der Link auf den Workaround nicht mehr.

Mit ein bisschen Phantasie ist das kein Problem: einfach die Suchbegriffe, die in der URL vorkommen (z.B. "debugger crash workaround"), in die Suche eintippen, die man auf der "Not found"-Seite bekommt, und schon findet man die aktuelle Seite: http://www.monien.net/delphi-2009-wi...sh-workaround/. Einziger Nachteil hierbei: die Bilder auf der Seite sind wohl nicht mehr vorhanden.

Keine Ahnung, ob das hilft, denn zum Thema selbst kann ich nichts beitragen.

MfG Dalai