Fehler bei Form.ShowModal

[Ykcim]

Zitat von Uwe Raabe:

Aber ist das Form zum Zeitpunkt des fehlschlagenden Aufrufs auch schon erstellt worden?

Das könnte der Grund sein... Die Prüfung, ob die Datei vorhanden ist oder nicht findet im CREATE von TDatenbankUnit statt. Bis Gerade stand das Form_DBZugriffsdatenUnit ganz unten. Ich habe es jetzt nach oben gesetzt, aber das hat nicht den gewünschten Erfolg gebracht...

Delphi-Quellcode:

program iVisitor;

uses
  Vcl.Forms,
  Form_MainUnit in 'Form_MainUnit.pas' {Form_Main},
  Form_DBZugriffsdatenUnit in 'Form_DBZugriffsdatenUnit.pas' {Form_DBZugriffsdaten},
  TMultiLanguageUnit in 'TMultiLanguageUnit.pas',
  TDatenbankUnit in 'TDatenbankUnit.pas',
  TExcelExportUnit in 'TExcelExportUnit.pas',
  TGridDesignUnit in 'TGridDesignUnit.pas',
  TBitMapUnit in 'TBitMapUnit.pas',
  Form_PasswortUnit in 'Form_PasswortUnit.pas' {Form_Passwort},
  Frame_SQLUnit in 'Frame_SQLUnit.pas' {Frame_SQL: TFrame};

{$R *.res}

begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TForm_Main, Form_Main);
  Application.CreateForm(TForm_Passwort, Form_Passwort);
  Application.CreateForm(TForm_DBZugriffsdaten, Form_DBZugriffsdaten);
  Application.Run;
end.

[Ykcim]

GELÖST!

Delphi-Quellcode:

if not FileExists(ExtractFilePath(Application.ExeName) + 'SQL.set') then begin
      if (Form_DBZugriffsdaten = nil) then
         Form_DBZugriffsdaten:= TForm_DBZugriffsdaten.Create(nil);
      ResultDBZugriff:=Form_DBZugriffsdatenUnit.Form_DBZugriffsdaten.ShowModal;
      if ResultDBZugriff>1 then begin
         Exit;
      end;
   end;

Zitat von Uwe Raabe:

Aber ist das Form zum Zeitpunkt des fehlschlagenden Aufrufs auch schon erstellt worden?

Zitat von Sherlock:

Ist sie erzeugt? Also entweder per vom KodeZwerg geshilderten Automatismus oder durch ein simples Form_DBZugriffsdaten := TForm.Create .

Sherlock

Vielen Dank für die Hilfe - die Kombination war es...

Patrick

[KodeZwerg]

Das verstehe wer will, ich tu es gerade nicht.

Wenn in .dpr es automatisch erzeugt wird aber bei Aufruf nicht vorhanden ist, da stimmt doch was nicht.
Das es forciert funktioniert mag ja schön und gut sein, aber normal ist so ein Verhalten nicht.

[Schokohase]

Zitat von KodeZwerg:

Das verstehe wer will, ich tu es gerade nicht.

Wenn in .dpr es automatisch erzeugt wird aber bei Aufruf nicht vorhanden ist, da stimmt doch was nicht.
Das es forciert funktioniert mag ja schön und gut sein, aber normal ist so ein Verhalten nicht.

Das hat was mit dem Timing zu tun.

Die Form wird in der dpr definitiv erzeugt, allerdings zu spät für den entsprechenden Codeteil. Und nur wenn es erzeugt wurde kann man es verwenden nicht wenn es erzeugt werden würde (wenn da nicht vorher die Exception fliegt)

[KodeZwerg]

Eventuell Offtopic, wer weiß das schon

Zitat von Schokohase:

Zitat von KodeZwerg:

Das verstehe wer will, ich tu es gerade nicht.

Wenn in .dpr es automatisch erzeugt wird aber bei Aufruf nicht vorhanden ist, da stimmt doch was nicht.
Das es forciert funktioniert mag ja schön und gut sein, aber normal ist so ein Verhalten nicht.

Das hat was mit dem Timing zu tun.

Die Form wird in der dpr definitiv erzeugt, allerdings zu spät für den entsprechenden Codeteil. Und nur wenn es erzeugt wurde kann man es verwenden nicht wenn es erzeugt werden würde (wenn da nicht vorher die Exception fliegt)

Ich Danke Ihnen für diese gute Erklärung.
Es war mir schon bewusst aufgrund der Fehlermeldung das dieses Objekt noch nicht existiert.
Nur kann ich es gerade nicht nachvollziehen. Ich führe mal ein paar selbst-Tests durch mit .DPR und langsamen Formularen.
Bis jetzt habe ich so ein Verhalten noch nicht erlebt, dass das Laden lange dauern kann schon.
Das ein Objekt, obwohl man es explizit Created nicht erstellt wird erscheint mir im Moment unlogisch.

Was mir einfällt wäre, wenn ich das Hauptformular Visible=True setze, kann es sein das es da schon angezeigt wird bevor Application.Run einsetzt? Sonst ist es für mich unlogisch.

[Schokohase]

Es ist doch ganz einfach

Delphi-Quellcode:

begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TForm_Main, Form_Main); // ruft den Konstruktor auf
  Application.CreateForm(TForm_Passwort, Form_Passwort);
  Application.CreateForm(TForm_DBZugriffsdaten, Form_DBZugriffsdaten); // der auf das hier zugreifen möchte
  Application.Run;
end.

Also wenn im Konstruktor von TForm_Main eine Instanz von TMYSQLDB erzeugt wird, wo dann Form_DBZugriffsdaten verwendet wird, dann passiert das eben.

[himitsu]

Zitat von Schokohase:

Es ist doch ganz einfach

Delphi-Quellcode:

begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TForm_Main, Form_Main); // ruft den Konstruktor auf
  Application.CreateForm(TForm_Passwort, Form_Passwort);
  Application.CreateForm(TForm_DBZugriffsdaten, Form_DBZugriffsdaten); // der auf das hier zugreifen möchte
  Application.Run;
end.

Also wenn im Konstruktor von TForm_Main eine Instanz von TMYSQLDB erzeugt wird, wo dann Form_DBZugriffsdaten verwendet wird, dann passiert das eben.

Die reihenfolge zu ändern ist aber nicht unbedingt eine gute Lösung,
denn die erste so erstellte Form wird zur MainForm,
was bei einer anderen Reihenfolge zu komischen Ergebnissen führt.

Tja, besser wäre es, wenn die Letzte die MainForm würde, aber das wird nicht passieren.
Lösungen: nicht im Konstruktor sowas machen, sondern erst nachdem alles erstellt wurde. (mein Tipp: Delphi könnte ein OnStartup in den TForm bekommen, was im Run als Erstes aufgerufen würde)
oder man muß eben weiterhin mit Messages/Timern sowas manuell machen.

Oder man lässt die abhängigen Forms nicht automatisch erstellen, sondern erstellt sie selber, vor dem Zugriff darauf (es ist eh nicht immer schön, wenn "alles" automatisch erstellt wird, vor allem wenn es dann fast niemals verwendet wird)

Zitat von Ykcim:

Delphi-Quellcode:

   AssignFile(Datei, ExtractFilePath(Application.ExeName) + 'SQL.set');
   Reset(Datei);
   try
      ReadLn(Datei, MyString);
      Connection.Server := copy(MyString, pos(':', MyString)+1, length(MyString));
      ReadLn(Datei, MyString);
      Connection.Username := copy(MyString, pos(':', MyString)+1, length(MyString));
      ReadLn(Datei, MyString);
      Connection.Password := copy(MyString, pos(':', MyString)+1, length(MyString));
      ReadLn(Datei, MyString);
      Connection.Database := copy(MyString, pos(':', MyString)+1, length(MyString));
      ReadLn(Datei, MyString);
      Connection.ProviderName := copy(MyString, pos(':', MyString)+1, length(MyString));
      ReadLn(Datei, MyString);
      Connection.Port := strtoint(copy(MyString, pos(':', MyString)+1, length(MyString)));
   finally
      CloseFile(Datei);
   end;

Du kennst schon TStrings.NameValueSeparator?
Eine TStringList, jenes auf ':' gesetzt und schon könntest du TStrings.ValueFromIndex verwenden, anstatt diesem rumgeCOPYe.
Und vorher vielleicht auch noch Count proüfen, ob die Anzahl passt, mit einer netteren Fehlermeldung, anstatt deinem grauenhaften "Lesefehler". (beim Zuriff über den Index, anstatt über die Namen)

Aber da ich vermute, dass vor dem : jeweils ein "Name" steht, würde ich eher zu TStrings.Values raten.

[Jumpy]

Ich versuche mal ein Scenario zu skizzieren:

MainForm wird erzeugt,
darin im OnCreate wird die TDatenbankunit erzegut,
die wiederum im Create in der Connect-Funktion auf die zu diesem Zeitpunkt noch nicht existierende TForm_DBZugriffsdaten zugreift.

Mit dem Workarround wird sie nun bei Bedarf erzeugt und dann nochmal später automatisch aus der dpr? Kann das nicht auch Probleme machen?

[Delphi.Narium]

Zitat von KodeZwerg:

Eventuell Offtopic, wer weiß das schon

Zitat von Schokohase:

Zitat von KodeZwerg:

Das verstehe wer will, ich tu es gerade nicht.

Wenn in .dpr es automatisch erzeugt wird aber bei Aufruf nicht vorhanden ist, da stimmt doch was nicht.
Das es forciert funktioniert mag ja schön und gut sein, aber normal ist so ein Verhalten nicht.

Das hat was mit dem Timing zu tun.

Die Form wird in der dpr definitiv erzeugt, allerdings zu spät für den entsprechenden Codeteil. Und nur wenn es erzeugt wurde kann man es verwenden nicht wenn es erzeugt werden würde (wenn da nicht vorher die Exception fliegt)

Ich Danke Ihnen für diese gute Erklärung.
Es war mir schon bewusst aufgrund der Fehlermeldung das dieses Objekt noch nicht existiert.
Nur kann ich es gerade nicht nachvollziehen. Ich führe mal ein paar selbst-Tests durch mit .DPR und langsamen Formularen.
Bis jetzt habe ich so ein Verhalten noch nicht erlebt, dass das Laden lange dauern kann schon.
Das ein Objekt, obwohl man es explizit Created nicht erstellt wird erscheint mir im Moment unlogisch.

Was mir einfällt wäre, wenn ich das Hauptformular Visible=True setze, kann es sein das es da schon angezeigt wird bevor Application.Run einsetzt? Sonst ist es für mich unlogisch.

Wenn ich im FormCreate von Form_Main eine Routine aufrufe, die Form_DBZugriffsdaten benötigt, dann existiert es noch nicht, da es in der dpr erst später erstellt wird.

Mach Dir mal ein Programm mit ein paar Formularen, steck jeweils ins FormCreate was rein, um dort 'nen Breakpoint setzen zu können. Setze in der dpr vor das Application.Initialize einen Breakpoint und gehe dann schrittweise durch.

Was wird zuerst aufgerufen? Der Breakpoint im FormCreate des ersten Formulares oder das letzte Application.CreateForm in der dpr?

[KodeZwerg]

Habe es mehr als Verstanden, Danke nochmal für Hinweise diesbezüglich.

Ich wünsche Euch einen tollen Tag!

Zitat von Delphi.Narium:

Mach Dir mal ein Programm mit ein paar Formularen, steck jeweils ins FormCreate was rein, um dort 'nen Breakpoint setzen zu können. Setze in der dpr vor das Application.Initialize einen Breakpoint und gehe dann schrittweise durch.

Was wird zuerst aufgerufen? Der Breakpoint im FormCreate des ersten Formulares oder das letzte Application.CreateForm in der dpr?

Zuerst der vor Application.Initialize ^_^, ich weiß worauf Du hinaus wolltest, Danke auch dafür!