Moin,
ich habe hier ein merkwürdiges Verhalten beim Compilieren, für das ich zwar einen Workaround habe, aber der Sache trotzdem auf den Grund gehen möchte. In der *.dpr:
Delphi-Quellcode:
begin
Application.Initialize;
{$IFDEF debug}
ReportMemoryLeaksOnShutdown := True;
{$ENDIF}
Application.MainFormOnTaskbar := True;
Application.Title := 'xyz';
TStyleManager.TrySetStyle('Aqua Light Slate');
Application.CreateForm(TDM, DM);
if TDialogLogin.login then Application.CreateForm(TfrmMain, frmMain);
Application.Run;
end.
Im Login-Dialog wird zur Anmeldung dann auf das Datenmodul zugegriffen:
Delphi-Quellcode:
userid := TSQLTool.GetInteger(DM.conXYZ, 'user', 'iduser',
'short=' + QuotedStr(EditKuerzel.Text) + ' AND ' +
'BINARY password=' + QuotedStr(EditPassword.Text));
und das geht plötzlich schief, wenn der User die AnmeldeAction ausführt:
| Benachrichtigung über Debugger-Exception |
| --------------------------- |
| Im Projekt mkueche.exe ist eine Exception der Klasse $C0000005 mit der Meldung 'access violation at 0x00cfd016: read of address 0x00000074' aufgetreten. |
Das liegt jetzt daran, dass das Datenmodul (DM) NIL ist. Warum ist das plötzlich so? Die
DPR und der Login sind seit Monaten so am laufen, und haben nie Zicken gemacht. Ich starte das Programm ja mehrmals täglich, und arbeite an der Programmlogik, die mit der Anmeldung überhaupt nix zu tun hat.
Mein Workaround besteht darin, das CreateForm für das Datenmodul in die Login-
Unit zu verlagern:
Delphi-Quellcode:
Initialization
if not assigned(DM) then Application.CreateForm(TDM, DM);
end.
Aber das kann's doch nicht sein, oder? Warum also wird in der
DPR plötzlich das Datenmodul vom Delphi 10.2 prof. scheinbar beim Compilieren übersprungen? Vielleicht hat ja jemand 'ne Idee.
TIA, Poelser