|
Fehler vor OnCreate finden
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo Zusammen,
ich habe ein großes Projekt, welches im Unternehmen seit Monaten ohne Probleme läuft. Mit diesem Programm arbeiten 2 Abteilungen und ca. 30 User täglich. Da die Software ein Benutzerberechtigungssystem beinhaltet gibt es natürlich auch einen LogIn. Jetzt habe ich einen Rechner, auf dem das Programm einen Fehler auswirft. Nach der Anmeldung mit irgendeinem Benutzernamen kommt angehängte Fehlermeldung. Da es der einzige Rechner ist, der Probleme macht, und ein altes Betriebssystem drauf war, welches einige Fehler im Protokoll anzeigte, habe ich Windows10 aufspielen lassen. Leider ohne Erfolg. Das Programm wurde vorher auf dem Rechner nicht verwendet, weil es der Azubi-Rechner ist... Ich dachte, ich könnte einfach ganz schlau alles mitloggen, was passiert. Leider ohne Erfolg, denn ich habe die LogIn-Procedure komplett geloggt und die OnCreate und OnShow Procedure des Hauptfenderts der Software. Die LogIn-Procedure läuft ohne Fehler durch. Leider tritt der Fehler dann auf, bevor OnCreate oder OnShow starten. Das heißtz ich habe ein schwarzes Loch, indem ich nicht weiß, was passiert und wie ich da dran kommen kann. Ich vermute das er in dieser Zeit die DFM-Datei den Main-Form ausführt, aber die kann ich meines Wissens nicht loggen, oder? Hat jemand eine Idee, wie ich da drankommen kann. Vielen Dank Patrick |
AW: Fehler vor OnCreate finden
Hallo,
die Meldung sieht wie NIL-Access aus. Compilier dein Programm mit MadExcept oder Eurekalog. Dann wird dir genau angezeigt, wo der Fehler auftritt (incl. Unitname und Zeile). Liegt dein Programm im Programme-Verzeichnis oder woanders? Liegt das Programm auf dem Azubirechner in einem anderen Verzeichnis wie bei den anderen Rechner? Mit "etwas" Aufwand könnte man auch den Delphi-RemoteDebugger benutzen. |
AW: Fehler vor OnCreate finden
Also das Programm liegt im gleichen Ordner. Der Ordner liegt auf dem File-Server, da das Programm ohne Installation ausgeführt werden kann. Bei allen anderen klappt das so wunderbar.
Wie funktioniert der Remote-Debugger? Vielen Dank Patrick |
AW: Fehler vor OnCreate finden
Hallo,
zum Remote-Debugger gibt es genug gute Links... Funktionsweise: - Exe mit externen Debug-Optionen starten - Delphi auf eigenem Rechner starten -> mit Exe über das Netzwerk verbinden - Debuggen so in etwa Was passiert, wenn das Programm auf den Azubi-Rechner lokal ausgeführt wird? |
AW: Fehler vor OnCreate finden
Funktioniert es leider auch nicht.
Ich habe MadExcept jetzt eingebaut. Es scheint so zu sein, dass er bei der Erstellung von ComboBoxen Probleme hat. Ich versuche das gerade einzugrenzen... |
AW: Fehler vor OnCreate finden
Ist der Rechner deutlich schneller oder langsamer als die anderen?
Auf jeden Fall ist wohl irgendeine Variable Nil. Möglicherweise wird eine Zuweisung
Delphi-Quellcode:
hier nicht ausgeführt bevor die Variable verwendet wird.
MyVar := TMyObj.Create
Bei der Initialisierung einer Anwendung kann der zeitliche Ablauf immer etwas variieren. |
AW: Fehler vor OnCreate finden
Der Rechner ist von der Performance her im Mittelfeld - nicht der schnellste aber auch definitiv nicht der langsamste.
Ich habe keine Ahnung, was ich machen soll... Patrick |
AW: Fehler vor OnCreate finden
Hallo,
Zitat:
Sind die bereits über die IDE gefüllt, also in der DFM? |
AW: Fehler vor OnCreate finden
Wie sieht denn der Stacktrace des Fehlers aus?
|
AW: Fehler vor OnCreate finden
Hallo Zusammen,
wir haben mittlerweile 2 Rechner, auf denen es nicht läuft - aber beide sind keine Produktiv-Rechner, sondern Azubi-Laptops. Mit der Berechtigung scheint es nichts zu tun zu haben. Auch wenn man als Admin angemeldet ist kommt der Fehler. Ich bin mir nicht mehr sicher, ob es wirklich an den Combos lag. Ich habe nicht viel Erfahrung mit Bug-Reports. Ich habe ihn mal angehängt. Fällt jemandem etwas auf? Ansonsten versuche ich das mal mit dem Fern-Debuggen hinzubekommen. Vielen Dank Patrick Zitat:
|
AW: Fehler vor OnCreate finden
Zitat:
Sieh Dir mal die Comboboxen etc. im Designer genauer an. Es gibt ein paar Dinge, die manchmal nicht in der creation sequence des forms funkionieren, wie z. B den ItemIndex einer Combobox zu setzen. Das hängt damit zusammen, das einige der Operatione eine Window handle erfordern. Die VCL legt das zwar nach Bedarf an (versucht es zumindestens), aber das kann schiefgehen. Was oft auch nicht funktioniert, ist der Versuch, den focus explizit in Code zu setzen, anstatt dafür die Activecontrol-Eigenschaft des Forms zu verwenden. |
AW: Fehler vor OnCreate finden
Relevant scheinen mir diese Teile zu sein:
Zitat:
Sherlock |
AW: Fehler vor OnCreate finden
Im Zweifelsfalle:
Die Fehlermeldung enthält eine Fehleradresse. Programm kompilieren und auf betroffenen Laptop starten. Fehleradresse merken. In der IDE auf den ersten Befehl in der dpr nach dem führenden Begin 'nen Breakpoint setzen. Programm in der IDE mit Debugger starten. Wenn das Programm am Breakpoint stehen bleibt im Menü die Option "Suchen/Laufzeitfehler suchen" wählen. Dort die Fehleradresse eingeben. Die IDE sollte Dich dann zu der Stelle bringen, an der der Fehler aufgetreten ist. Im Umfeld dieser Stelle nach möglichen Fehlerursachen suchen. Alternative: Programm mit ausführlicher MAP-Datei erstellen. Programm auf Laptop starten. Fehlereradresse merken und diese in der MAP-Datei suchen. Wird sie gefunden, so steht vor der Fehleradresse die Nummer der Zeile, in der der Fehler auftritt. Mehr oder weniger weit darüber steht, um welche Quelltextdatei es sich handelt. Dort dann nach möglichen Fehlerursachen suchen. Ansonsten: EurekaLog, madExcept Nutzt Du die JEDIs? Dann nimm dort den TJvDebugHandler, der hilft Dir an Fehlerursachen zu gelangen. |
AW: Fehler vor OnCreate finden
Hallo Zusammen,
ich habe es jetzt mit dem Remote-Debugger versucht. Mit einer "Hello World" Anwendung klappt das wunderbar. Aber wenn ich mein Projekt compiliere, startet das Prgramm nicht auf der Remote-Maschine. Die exe-Datei wird zwar angelegt, aber starten tut sie nicht. Komischer Weise beendet sich auch scheinbar der Debugger. Jedenfalls wird der grüne Button wieder sichbar. Aber wenn ich draufklicke passiert nichts... Wenn ich aber die das Projekt in Delphi schließen möchte, wird gesagt, dass es eine Debugger-Sitzung gibt... Kennt jemand das? Ich mein Projekt zu groß? Die Debugger-EXE ist 70MB groß, die Release-EXE ca. 25MB. Vielen Dank Patrick |
AW: Fehler vor OnCreate finden
Mach doch mal eines nach dem anderen. Du hast einen Call Stack, was sagst Du dazu? Meine Anmerkungen schon gelesen?
Sherlock |
AW: Fehler vor OnCreate finden
Hallo Sherlock,
ich habe Deine Anmerkung gelesen. Aber ich weiß nicht, wie ich sie umsetzen muss.:oops: Ich weiß nicht, wie ich gezielt zu dem Punkt komme. Ich habe Haltepunkte im OnCreate und OnShow des Hauptfensters gesetzt, aber vorher crasht das Programm. Aber nicht auf der Entwicklungsmaschine, deshalb tue ich mich gerade so schwer damit... LG Patrick |
AW: Fehler vor OnCreate finden
Liste der Anhänge anzeigen (Anzahl: 1)
Hallo Delphi.Narium,
ich habe jetzt aus dem Bug-Report von MadExcept die Fehler-Adresse ausfindig gemacht (00534460). Dann habe ich die Adresse gesucht. Jetzt stehe ich vor diesem Bildschirm. Bei dieser Ansicht habe ich noch nie verstanden, was ich damit anfangen kann und wie ich von dort aus zu dem entsprechenden Code komme... Ich habe den Bildschirm als Screenshot angehängt. Vielen Dank Patrick |
AW: Fehler vor OnCreate finden
Hallo,
der Fehler steht doch direkt da. Deaktiviertes oder unsichtbares Fenster kann den Fokus nicht erhalten. Ursache1: Du hast im Code ein xxx.SetFocus; Wahrscheinlich im FormCreate. Zu diesem Zeitpunkt existiert aber das (Windows-)Fenster-Handle der Komponente noch nicht. Ursache2: Die xxx bei xxx.SetFocus ist zu dem Zeitpunkt nicht sichtbar Quick&Dirty1: try XXX.SetFocus; except ; end; Quick&Dirty2: ins FormActivate verschieben und trotzdem try except drumrum |
AW: Fehler vor OnCreate finden
Mein Problem ist aber, dass ich nicht weiß was xxx ist und wo es aufgerufen wird. Ich habe OnShow und OnCreate schon komplett auskommentiert, damit der Inhalt garnicht zur Anwendung kommt. Aber das Programm crasht trotzdem. Im ganzen Main-Form gibt es nur einmal SetFocus und das habe ich gerade herausgenommen - ohne Erolg...
Auf der Entwicklungsmaschine und ca. 40 anderen Rechnern läuft es ohne Probleme, sondern nur auf zwei Rechnern, die nicht produktiv genutzt werden. Ich bin leider noch nicht bei der Fehlerbehebung, sondern ich versuche herauszufinden, wo der Fehler entsteht... Hast Du eine Idee, wie ich das anstellen kann? LG Patrick |
AW: Fehler vor OnCreate finden
Hallo,
das war zu schnell. Es geht ja um das TMS TAdvStringGrid, genauer und dein Grid_not_printed. Das hier grätscht rein Vcl.Themes TUxThemeStyle.DoDrawText dann folgt AdvGrid 41726 +667 TAdvStringGrid.WMLButtonUp und der Auslöser ist AdvGrid 26797 +1 TAdvStringGrid.EditCell Das ganze soll beim Erzeugen des Formulars passieren? Sehr verwunderlich. Notlösung wäre das Editieren des Grids im Objektinspektor zu deaktivieren. Bei TAdvStringGrid gibt es ja mehrere Stellen, nicht nur Gridoptions-goEditing, DirectEdit usw.. Bei den beiden Rechnern scheint jemand an den Grafikeinstellungen rumgeschraubt zu haben. Test wäre ein leeres Projekt und dann das Grid_not_printed per Copy&Paste dort drauf. Außerdem würde ich mal bei den Events des Grids nachschauen, ob da "böses" passiert. |
AW: Fehler vor OnCreate finden
Die Option goEditing ist deaktiviert. Ich arbeite bei dem Grid mit der Procedure CanEditCell:
Delphi-Quellcode:
Warum das zu diesem Zeitpunkt irgendwie Ärger macht wüßte ich nicht und vor allem, warum nur auf diesen beiden Rechnern...
procedure TFrame_Listendruck.Grid_not_printedCanEditCell(Sender: TObject; ARow,
ACol: Integer; var CanEdit: Boolean); begin CanEdit:=(ACol in [15,16]); if (Sender as TAdvStringGrid).Cells[19,ARow]<>'' then begin CanEdit:=(ACol in [7,8,13,14,15,16,18]); end; if ARow=1 then CanEdit:=(ARow in [1]); end; LG Patrick |
AW: Fehler vor OnCreate finden
Hast Du eine MAP-Datei?
Findest Du in ihr die Fehleradresse? Wenn ja, sollte das in etwa so aussehen:
Code:
Jede Zeile besteht aus vier Blöcken. Jeder Block aus der Zeilennummer des Quelltextes, die zu dieser Fehleradresse gehört, 0001:Fehleradresse.
Line numbers for NameDerFehlerhaftenUnit(NameDerFehlerhaftenUnit.pas) segment .text
47 0001:00295DC8 48 0001:00295DEA 49 0001:00295DF7 50 0001:00295DFC 51 0001:00295E05 52 0001:00295E1F 54 0001:00295E2D 55 0001:00295E39 57 0001:00295E3C 58 0001:00295E53 60 0001:00534460 61 0001:00534480 In diesem Beispiel wäre der Fehler in der Unit NameDerFehlerhaftenUnit.pas in Zeile 60 zu finden. Dahin gehen, Breakpoint (ggfls. ein paar Zeilen davor) setzen und dann schrittweise durchsteppen. Findest Du die exakte Fehleradresse nicht, so suche nach einem Wert, der etwas kleiner ist. Also statt nach :00534460 z. B. nach :005344. Gehe zur entsprechenden Stelle im Quelltext und steppe ab dort schrittweise durch. Sherlock hat drauf hingewiesen, dass der Fehler "irgendwo im Umfeld von TAdvStringGrid.Click" zu suchen ist, hoika hat das präzisiert. In welcher / welchen Units nutzt Du das TAdvStringGrid? Eine dieser Units wird den Fehler (vermutlich) enthalten. Wird dort irgendwo programmatisch ein OnClick-Ereignis dieser Komponenten ausgelöst? Oder wird eine Routine aufgerufen, die eine programmatische Änderung des TAdvStringGrid auslösen könnte. Wenn ja, kommentiere diese Routinen aus und prüfe, ob der Fehler bestehen bleibt. Wenn nein, aktiviere die entsprechenden Stellen im Quelltext wieder, aber immer nur eine, damit Du feststellen kannst, welche konkret den Fehler verursacht. Wenn der Fehler mit CanEditCell zusammenhängt, kann das ein Timingproblem sein. Irgendwas ist bei diesen beiden Rechnern noch nicht da, was bei den anderen Rechner zum Zeitpunkt des Aufrufes dieser Routine schon vorhanden ist. Im Screenshot ist nicht wirklich viel "sinnvolles" zu sehen, aber: Scrolle soweit vor oder zurück, bis Du eine Info findest, mit der Du was anfangen kannst. Notfalls per Einzelschritt durchsteppen, bis Du an eine für Dich "verständliche" Stelle kommst. In dem Fall liegt der Fehler dann "irgendwo davor". Das der Fehler nur auf diesen beiden Rechnern entsteht, hängt damit zusammen, dass sie (vermutlich) sehr ähnlich sind, sowohl in Bezug auf Hard- als auch auf Software. Eventuell sind sie aus irgendeinem Grund etwas schneller oder etwas langsamer oder laden andere Treiber ... Sie stolpern über einen versteckten Fehler, der auf den anderen Systemen (ggfls. bei nur marginaler Änderung von was auch immer) ebenfalls auftreten kann. So ein bisschen sowas wie 'ne Zeitbombe. |
AW: Fehler vor OnCreate finden
Und es gibt keine Ereignisbehandlung für das Click in diesem Grid?
Delphi-Quellcode:
Frame_ListendruckUnit 284 +1 TFrame_Listendruck.Grid_not_printedClick
Sherlock |
AW: Fehler vor OnCreate finden
Hallo,
verlagere das Füllen des Grids ins FormActivate. Zusätzlich könntest du dein Grid-Event etwas absichern:
Delphi-Quellcode:
Formularvariable
bAfterFormActivate: Boolean; procedure TForm1.FormCreate; begin bAfterFormActivate:= False; // müsste eigentlich schon False sein end; procedure TForm1.FormActivate; begin // ganz unten bAfterFormActivate:= True; end; procedure TForm1.Grid_not_printedCanEditCell() begin if not bAfterFomActivate then begin CanEdit:= False; Exit; end; end; |
AW: Fehler vor OnCreate finden
Hallo,
Zitat:
siehe CallStack Seite 1. |
AW: Fehler vor OnCreate finden
Hallo,
Zitat:
Man muss den Callstack ja von unten nach oben lesen. 007e1f0e +1b3a NedCom.exe AdvGrid 41726 +667 TAdvStringGrid.WMLButtonUp 00454ef5 +0025 NedCom.exe System.SysUtils StrLCopy 005c0e57 +0057 NedCom.exe Vcl.Themes TUxThemeStyle.DoDrawText Genauer das WMLButtonUp ist schon sehr komisch. Das wird ja nicht vom Anwender erzeugt, sondern intern vom Grid in der WndProc. Was ich auch schon mal hatte im Zusammenhang mit TMS und Laptop mit Touchscreen: in Form1 Doppelklick auf ein Grid, Form2 öffnet sich, ein Mausklick von Form1 wurde an Form2 "durchgereicht". |
AW: Fehler vor OnCreate finden
Hallo Zusammen,
vielen Dank für Eure Hilfe! Ich versuche nachfolgende zu antworten: Zitat:
Zitat:
Zitat:
Zitat:
Zeitbombe: Das sehe ich auch so, deshalb beschäftige ich mich damit, obwohl es noch kein Ausfall auf einer Produktivmaschine gibt. Zitat:
Zitat:
Die 005345D4 finde ich nicht, aber die 00000260: Zitat:
Zitat:
Zitat:
Hat jemand vielleicht ein Idee, warum das mit dem Remote-Debugger nicht klappt? Vielleicht würde ich ja so der Ursache auf die Spur kommen... Vielen Dank für Eure Mühe - diese Art der Fehlersuche ist für mich Neuland! LG Patrick |
AW: Fehler vor OnCreate finden
Zitat:
Der Fehler hat aber nichts mit dem beschriebenen Crash beim Start zu tun. Zitat:
Adresse 005345D4 ist die Stelle im Code, an der der Fehler auftritt. Die muss nicht exakt in der Mapdatei stehen, denn der Fehler muss ja nicht direkt mit dem Start der Methode auftreten. Die 260 bedeutet wahrscheinlich, dass auf eine Property eines nicht initialisierten Objekts zugegriffen wird, die 260 Byte nach dem Beginn der Klassendefinition kommt. Mehr sollte der Stacktrace verraten. |
AW: Fehler vor OnCreate finden
Zitat:
Dann kam mir beim googeln nach "TUxThemeStyle.DoDrawText" das da:  https://stackoverflow.com/questions/...-of-the-screen |
AW: Fehler vor OnCreate finden
Liste der Anhänge anzeigen (Anzahl: 1)
Hier der BugReport - etwas gekürzt um doppelte Einträge
|
AW: Fehler vor OnCreate finden
Hallo,
Zitat:
Und es stet ja auch kein ButtonClick-Event im MadExcept-Log auf Seite 1. Ausserdem gibt es kein WMLButtonDown, sonder nur ein WMLButtonUp; Noch mal an den Threadersteller: Woher weißt Du, dass es in/vorm OnCreate passiert? So wie ich es verstanden habe, hast Du ein Hauptprogramm, was ein anderes Form startet und dort kommt schon beim Erzeugen (nicht in FormActivate) der Fehler? Was mir noch aufgefallen ist. Das Grid steckt ja in einem Frame, ist der vielleicht nicht sichtbar oder hat den Focus nicht?! Schreib mal in TFrame_Listendruck.Grid_not_printedClick eine einfache MessageBox als erste Zeile, um zu sehen, wann die Klick-Methode aufgerufen wird. Ausserdem noch eine MessageBox zu Beginn und Ende des FormActivate. MessageBox = Remote-Debugger für Arme ;) |
AW: Fehler vor OnCreate finden
Such in der MAP-Datei bitte nach :005345D4.
Wenn das nicht da ist, nach :005345 und wenn das nicht da ist nach :0053. Findest Du irgendwo hinter dem ersten "Line numbers" der MAP-Datei was dazu? Wenn nein, könnte es sein, dass der konkrete Fehler nicht in dem Teil des Programmes geschieht, für den Du Quelltext besitzt, also z. B. Komponenten, für die Du nur die DCUs hast. (Gibt es sowas oder hast Du für alles auch die Quelltexte?) Zitat:
@Ykcim Schlimmstenfalls: Pflastere jede, wirklich jede Prozedure am Anfang und am Ende mit ShowMessage ein:
Delphi-Quellcode:
Durch den Kompilerschalter muss Du dann nicht alles wieder entfernen, bevor die Software in Betrieb geht. Den Kompilerschalter kannst Du dann von
// irgendwo am Anfang:
{$DEFINE MsgDebug} Function TForm1.NameDerFunktion : keineAhnung; begin {$IFDEF MsgDebug}ShowMessage('Start NameDerFunktion');{$ENDIF} ... der eigentliche Funktionsinhalt. {$IFDEF MsgDebug}ShowMessage('Ende NameDerFunktion');{$ENDIF} end;
Delphi-Quellcode:
nach
{$DEFINE MsgDebug}
Delphi-Quellcode:
ändern und die Meldungen sind mit dem nächsten Kompilieren wieder weg.
{ $DEFINE MsgDebug}
Statt ShowMessage ... kannst Du auch 'ne Loggingfunktion nehmen, die diese Meldungen in 'ne Datei schreibt (sofern Du sowas gerade zur Verfügung hast). Und nein, wirklich schön ist dieser Lösungsvorschlag nicht, aber als Notnagel kann man's schonmal durchgehen lassen ;-) |
AW: Fehler vor OnCreate finden
Hallo hoika,
Zitat:
Delphi-Quellcode:
Der Benutzer gibt seinen LogIn-Namen und ein Passwort ein. Wenn beides passt, wird über eine Datenbankabfrage geprüft, schließt sich das LogIn-Fenster und das Programm setzt den Start fort.
begin
Application.Initialize; Application.MainFormOnTaskbar := True; if ( not DoLogin ) then Exit; Application.CreateForm(TMain, Main); Application.CreateForm(TForm_Zeichnungen, Form_Zeichnungen); Application.CreateForm(TForm_Filter, Form_Filter); Application.CreateForm(TForm_Passwort, Form_Passwort); Application.CreateForm(TForm_LogIn, Form_LogIn); Application.CreateForm(TForm_Start, Form_Start); Application.CreateForm(TForm_Return, Form_Return); Application.Run; Main.WindowState:=wsMaximized; end. Die Eingabe kann ich auch machen. Allerdings muss ich jedes Mal meinen Benutzer neu eingeben. In der OnShow-Procedure des Main-Form wird der Benutzer in eine Tabelle geschrieben, gemeinsame mit dem Computernamen. Beim öffnen des LogIn-Fensters wird geprüft, ob sich dieser Rechner schon mal angemeldet. Wenn ja, wird der letzte Benutzer-LogIn in das Eingabefeld geschrieben. Das Passiert nicht. Also tritt der Fehler vorher auf. Zitat:
Ich habe in der Procedure des Ok-Buttons des LogIn-Fensters und in der onCreate Procedure des Main-Forms und in der onShow-Procedure des Main-Forms mit Hilfe einer TStringList eine Datei schreiben lassen, wobei ich nahzu Zeileweise den Durchlauf den Programm-Codes logge. Diese Datei habe ich dann auf den FileServer abgelegt - immer unter dem Namen des Rechners mit Datum und Uhrzeit. Die Datei würde auch im Exception-Fall geschrieben. Bei den Problem-Rechnern wird die Datei im Login-Fenster geschrieben, aber keine vom Main-Form. Bei allen anderen Rechnern klappt das. Deshalb gehe ich davon aus, dass der Fehler nach dem erfolgreichen LogIn, aber vor dem onCreate des Main-Form auftritt. Aber was ist dazwischen und wie kann ich das loggen? Vielen Dank Patrick |
AW: Fehler vor OnCreate finden
Hallo Delphi.Narium,
warum den Umweg über die Map-Datei? Auf Seite 1 ist der komplette Call-Stack. Der Fehler tritt intern im TAdvStringGrid auf, weil der Inplace-Edit anzuzeigt wird. Der Fehler sagt ja, dass das SetFocus des Inplace-Editors fehlschlägt. Entweder ist das Grid oder der Frame nicht sichtbar, oder siehe StrLCopy es wird Speicher bei Theming überschrieben. Da fallen mir noch 2 Sachen ein 1. FastMM4 wegen dem möglichen Speicherüberschreiben 2. in den Grafikoptionen mal alle visuellen Effekte außer Kantenglättung deaktivieren (rechte Maustaste auf Computer/dieser PC -> Erweiterte Systemeinstellungen -> Leistung) |
AW: Fehler vor OnCreate finden
Hallo Delphi.Narium
Zitat:
|
AW: Fehler vor OnCreate finden
Hallo,
zu spät dein Post bemerkt. Mir sind in der Dpr 2 Sachen aufgefallen Application.CreateForm(TForm_LogIn, Form_LogIn); wird erzeugt, aber wohl nicht mehr gebraucht? Application.Run; Main.WindowState:=wsMaximized; Das hat keine Wirkung, weil Delphi in der Run-Methode bleibt, bis das Hauptprogramm (Main) beendet wird. Aber jetzt zu deinem Post. Was passiert, wenn du die DoLogin-Methode mal ausklammerst? Vielleicht macht dein Login-Fenster ja was "kaputt". |
AW: Fehler vor OnCreate finden
Zitat:
|
AW: Fehler vor OnCreate finden
Zitat:
Delphi-Quellcode:
begin
Application.Initialize; Application.MainFormOnTaskbar := True; if ( not DoLogin ) then Exit; Application.CreateForm(TMain, Main); Application.CreateForm(TForm_Zeichnungen, Form_Zeichnungen); Application.CreateForm(TForm_Filter, Form_Filter); Application.CreateForm(TForm_Passwort, Form_Passwort); Application.CreateForm(TForm_Start, Form_Start); Application.CreateForm(TForm_Return, Form_Return); Main.WindowState:=wsMaximized; Application.Run; end. |
AW: Fehler vor OnCreate finden
Ok, Fehler nicht in MAP-Datei, damit ist dann klar, das hoikas Ansatz der einzig verbleibende Weg zum Finden des Fehlers ist.
Delphi-Quellcode:
In welchen Formularen wird das TAdvStringGrid genutzt?
begin
Application.Initialize; Application.MainFormOnTaskbar := True; if DoLogin then begin Application.CreateForm(TMain, Main); Application.CreateForm(TForm_Zeichnungen, Form_Zeichnungen); Application.CreateForm(TForm_Filter, Form_Filter); Application.CreateForm(TForm_Passwort, Form_Passwort); Application.CreateForm(TForm_Start, Form_Start); Application.CreateForm(TForm_Return, Form_Return); Main.WindowState:=wsMaximized; Application.Run; end; end. Könnte eventuell eine Änderung der Application.CreateForm ... - Reihenfolge was ändern (außer TMain, das als erstes Formular ja zum Hauptformular der Anwendung wird). |
AW: Fehler vor OnCreate finden
Zitat:
|
| Alle Zeitangaben in WEZ +1. Es ist jetzt 02:55 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz