Application.CreateForm hängt

[lxo]

Hallo,

kennt ihr das Problem evtl. das euer Programm unverständlicherweise bei Application.CreateForm hängt.
Also wenn man ein Form öffnen möchte?
Auch wenn man ganz oben bei der Form im Create einen Haltepunkt setzt braucht dieser ewig bis er dort ankommt. ca. 15 Sekunden.
Über den Aufrufstack kann ich auch nicht sehen, dass er noch in irgendwelche anderen Methoden springt.

Hat da jemand einen Tipp?

[TurboMagic]

Hast du Code im OnCreate?

[dummzeuch]

Zitat:

Zitat von lxo (Beitrag 1491511)

Auch wenn man ganz oben bei der Form im Create einen Haltepunkt setzt braucht dieser ewig bis er dort ankommt. ca. 15 Sekunden.
Über den Aufrufstack kann ich auch nicht sehen, dass er noch in irgendwelche anderen Methoden springt.

Hat da jemand einen Tipp?

Mit Debug DCUs compilieren und durchsteppen.

[hoika]

Hallo,
nur in der IDE oder auch einfach so gestartet?

[himitsu]

Datenbankkomponenten auf der Form? (mit falschen Connectiondaten)


Mit einem Profiler nachsehn, wo es hängt. (z.B. AQTime)

oder manuell alles entfernen/deaktivieren/auskommentieren und Stück für Stück wieder rein, bis es wieder hängt,
bzw. Stück für Stück lles entfernen und schauen ab wann es wieder geht.
* Events und Komponenten auf der Form

[jaenicke]

Bei 15 Sekunden ist es doch relativ einfach:
Einfach starten und dann während der Wartezeit anhalten und schauen was der Hauptthread gerade tut, ggf. auch fortsetzen und wieder anhalten...

Ist das auch im Release Modus ohne Debugger so?

[KodeZwerg]

In der .dpr Datei einfach mal die erstellten Formulare durchbenchen. So findest Du schnell heraus auf welches lange gewartet wird. Vielleicht habe ich es auch missverstanden und Du meinst dynamische Forms...

[lxo]

Zitat:

Zitat von TurboMagic (Beitrag 1491549)

Hast du Code im OnCreate?

Ja, aber es dauert schon 15 Sekunden bis ich ins Create komme.

[Klaus01]

.. werden bei Dir die Forms alle automatisch erzeugt?
Werden in einigen Units im Initialization Abschnitt Code ausgeführt?

Grüße
Klaus

[lxo]

Zitat:

Zitat von Klaus01 (Beitrag 1491573)

.. werden bei Dir die Forms alle automatisch erzeugt?
Werden in einigen Units im Initialization Abschnitt Code ausgeführt?

Grüße
Klaus

Zur Laufzeit, wenn das Fenster geöffnet wird, wird es auch erzeugt.
Initialization hab ich kontrolliert wird dort nichts ausgeführt.

Wie himitsu bereits sagt, vermute ich auch es liegt an Datenbankkomponenten oder irgendwelchen anderen Komponenten die noch nebenherlaufen.

[jaenicke]

Zitat:

Zitat von lxo (Beitrag 1491574)

Wie himitsu bereits sagt, vermute ich auch es liegt an Datenbankkomponenten oder irgendwelchen anderen Komponenten die noch nebenherlaufen.

Dann solltest du das aber auch im Stacktrace des Hauptthreads sehen wie schon geschrieben, wenn du auf Pause drückst während der Wartezeit.

[haentschman]

Moin...:P

Zitat:

Ja, aber es dauert schon 15 Sekunden bis ich ins Create komme.

Vor der ersten Zeile des OnCreate werden alle Komponenten "initialisiert". Deshalb die Info auf die Prüfung der Properties usw. :zwinker:

Zitat:

Datenbankkomponenten auf der Form? (mit falschen Connectiondaten)

Das ist der Klassiker. In der Connection zur Designzeit Active = True gesetzt. :zwinker:

[lxo]

Zitat:

Zitat von jaenicke (Beitrag 1491575)

Zitat:

Zitat von lxo (Beitrag 1491574)

Wie himitsu bereits sagt, vermute ich auch es liegt an Datenbankkomponenten oder irgendwelchen anderen Komponenten die noch nebenherlaufen.

Dann solltest du das aber auch im Stacktrace des Hauptthreads sehen wie schon geschrieben, wenn du auf Pause drückst während der Wartezeit.

Wenn ich während der Wartezeit anhalte, komme ich in die CPU-Ansicht und der hält bei "ntdll.RtlUserThreadStart", von da aus weiter in "ntdll.LdrInitializeThunk"

[jaenicke]

Zitat:

Zitat von lxo (Beitrag 1491577)

Wenn ich während der Wartezeit anhalte, komme ich in die CPU-Ansicht und der hält bei "ntdll.RtlUserThreadStart", von da aus weiter in "ntdll.LdrInitializeThunk"

Das ist vermutlich nicht der Stacktrace des Hauptthreads. Nach dem Anhalten musst du schon erst dorthin wechseln (in der Threadansicht doppelt auf den ersten Thread klicken).

[stifflersmom]

Zitat:

Zitat von haentschman (Beitrag 1491576)

Moin...:P
Das ist der Klassiker. In der Connection zur Designzeit Active = True gesetzt. :zwinker:

Und genau dafür ist GExpert mit den Set Component Propertiers Gold wert!
Dort einfach die gewünschte Eigenschaft konfgurieren, z.B.

Delphi-Quellcode:

Component.Connected := false;

und schon wird beim Compilieren das automatisch gesetzt.

[Uwe Raabe]

FireDAC bietet da von Haus aus noch eine andere Möglichkeit: Bei dem ConnectedStoredUsage einfach das auRunTime rausnehmen, dann wird die Connection zur Laufzeit auch nicht aktiviert. (Man kann zusätzlich auch das auDesignTime rausnehmen, dann wird die Connection auch beim nächsten mal in der IDE nicht verbunden.)

Zur Laufzeit kann man das auch pauschal für alle Connections vorgeben, wenn man vor dem Laden des ersten Forms oder Datenmoduls ein

Delphi-Quellcode:

FDManager.ActiveStoredUsage := []

einfügt (auDesignTime ist zur Laufzeit eh irrelevant).

Ergänzend müssen dann auch alle verbundenen DataSets (z.B. TFDQuery) das ActiveStoredUsage entsprechend gesetzt haben, da sonst beim Aktivieren des DataSets implizit auch die Connection geöffnet wird. Das lässt sich zur Designzeit relativ einfach über ein Multi-Select einstellen.

[dummzeuch]

Mir fehlt in der ganzen Diskussion immernoch der einfachste Ansatz: Mit Debug DCUs compilieren und im Debugger durchsteppen.

Ich hatte das ziemlich am Anfang vorgeschlagen.

Wenn der Threadersteller das gemacht hätte, wüsste er jezt, wonach er schauen muss, aber es ist wohl zu kompliziert.

[lxo]

Zitat:

Zitat von dummzeuch (Beitrag 1491590)

Mir fehlt in der ganzen Diskussion immernoch der einfachste Ansatz: Mit Debug DCUs compilieren und im Debugger durchsteppen.

Ich hatte das ziemlich am Anfang vorgeschlagen.

Wenn der Threadersteller das gemacht hätte, wüsste er jezt, wonach er schauen muss, aber es ist wohl zu kompliziert.

Den Ansatz werde ich auch weiter verfolgen. Komme heute leider nur noch dazu mich mit dem Problem auseinander zu setzen.
Vielen Dank schonmal für die zahlreichen Tipps.

[himitsu]

Zitat:

Zitat von lxo (Beitrag 1491577)

Wenn ich während der Wartezeit anhalte, komme ich in die CPU-Ansicht und der hält bei "ntdll.RtlUserThreadStart", von da aus weiter in "ntdll.LdrInitializeThunk"

Der Debugger hält nicht immer im Hauptthrerad.
Meistens ist es der erste/oberste Thread in der ThreadListe (Strg+Alt+T) -> Jenen doppelt anklicken, wenn nicht aktiv.

Und eventuell auch noch ein/mehrmals auf F7 oder F8.
Wenn der aktuelle Stack nichts "schönes" anzeigt, noch etwas weiter und hoffen es kommt was Besseres, auf dem Weg weiter/zurück.

[lxo]

Zitat:

Zitat von himitsu (Beitrag 1491594)

Zitat:

Zitat von lxo (Beitrag 1491577)

Wenn ich während der Wartezeit anhalte, komme ich in die CPU-Ansicht und der hält bei "ntdll.RtlUserThreadStart", von da aus weiter in "ntdll.LdrInitializeThunk"

Der Debugger hält nicht immer im Hauptthrerad.
Meistens ist es der erste/oberste Thread in der ThreadListe (Strg+Alt+T) -> Jenen doppelt anklicken, wenn nicht aktiv.

Und eventuell auch noch ein/mehrmals auf F7 oder F8.
Wenn der aktuelle Stack nichts "schönes" anzeigt, noch etwas weiter und hoffen es kommt was Besseres, auf dem Weg weiter/zurück.

Ich hab den Übeltäter, FileExists auf ein ungültigen Netzwerkpfad. Deswegen kommt das auch nicht bei jedem :wall:

[lxo]

Ich versteh nur nicht ganz, beim ersten mal dauert das ewig bis er bei FileExists ein Ergebnis liefert, wenn man es nochmal versucht kommt direkt ein Ergebnis. Nach einiger Zeit dauert es wieder lange.
Hat da evtl. noch jemand ein Tipp wie man schnell kontrollieren kann ob der Pfad(Netzwerk) erreichbar ist oder nicht?

[TiGü]

Zitat:

Zitat von lxo (Beitrag 1491597)

Ich versteh nur nicht ganz, beim ersten mal dauert das ewig bis er bei FileExists ein Ergebnis liefert, wenn man es nochmal versucht kommt direkt ein Ergebnis. Nach einiger Zeit dauert es wieder lange.
Hat da evtl. noch jemand ein Tipp wie man schnell kontrollieren kann ob der Pfad(Netzwerk) erreichbar ist oder nicht?

Da wird wohl das File Caching zuschlagen und darum beim zweiten Mal schneller gehen: https://docs.microsoft.com/en-us/win...o/file-caching

Ansonsten könntest du vielleicht den Server des Netzlaufwerks anpingen.
Also wenn dein Pfad lautet: \\Mein_lustiger_UNC_Root\Mein_Pfad
Dann kannst du

Code:

ping Mein_lustiger_UNC_Root

machen.
Wenn der UNC-Pfad auf einen Laufwerksbuchstaben gemappt ist, dann musst du noch etwas weiter ausholen:
https://superuser.com/questions/1034...ows-10/1034654

[stifflersmom]

Wenn der Server keine Pings beantworten will, dann bringt das Pingen auf den Server im UNC-Pfad gar nichts...
Von daher kann man auch gleich prüfen, ob eine bestimmte Datei im gemapten Laufwerk existiert und das Ergebnis dann halt nutzen.

[jaenicke]

In solchen Fällen macht es Sinn das asynchron im Thread zu prüfen, damit der Rest der Anwendung nicht blockiert bzw. am Start gehindert wird.

[himitsu]

Der einzige Vorteil vom PING:
* dort ist das mit dem Timeout besser/sicherer geregelt ... der direkte Zugriff auf die Freigabe kann schlimm (nie) enden

Nachteil:
* nur weil der PING geht, heißt es nicht, dass die Freigabe auch erreichbar ist
* * nicht da
* * keine Zugriffsrechte
* aber, wie schon gesagt, nur weil der PING nicht geht, heißt es auch nicht, dass die Freigabe weg ist (PING ist ein Service/Dienst und wenn nicht aktiv, dann gibt es keine Antwortauf die PING-Anfrage)

[dummzeuch]

Zitat:

Zitat von himitsu (Beitrag 1491624)

Der einzige Vorteil vom PING:

Auf neueren Windows ist die Antwort auf Ping standardmäßig abgeschaltet. Da bringt das absolut gar nichts mehr. Wenn ich mich recht erinnere, ist das seit Windows 7 so, kann aber auch schon länger sein.