MouseOver Sorgt für Programm Crash

[Delphi-Narr]

Hallo,
ich habe ein Programm mit GUI (zu Testzwecken), welches lediglich einen Button zum erstellen eines Objekts besitzt.
Dieses Objekt lädt im Grunde diverse DLLs und führt periodisch Updates auf allen DLLs aus (entsprechende DLL Funktion).
Das Ganze ist wie eine Art Pluginmanager zu verstehen.
Damit auch Strings zwischen den DLLs und dem Hauptprogramm ausgetauscht werden können, ist in den DLLs und den dem Hauptprogramm FastMM4 als erste Unit eingebunden.
Ist ein bestimmtes Plugin aktiv, passiert es nun, dass das Programm scheinbar ohne Grund abstürzt ("Das Programm funktioniert nicht mehr").
Dies passiert manchmal nach 3 Sekunden, manchmal nichtmal nach 3 Stunden.
Je nach MemoryManager war es auch zu beobachten, dass das Programm mit der oben genannten Fehlermeldung abstürzt, sobald man die Maus über das Programmfenster bewegt?!

Da das Programm am Wochenende zum Einsatz kommen soll, wäre es natürlich vorteilhaft, wenn es nicht andauernd abstürzen würde.

Ich lade die Programmstruktur mal als Anhang hoch. Das zum Absturz führende Tool ist "arduino_led". Verwaltet werden die "Plugins" / "Apps" vom MainController, welcher als Verbindung zu den DLLs Instanzen der Klasse "AppClass" erstellt, welche ihrerseits die DLLs laden.
Mit einem simplen Timer wird alle 10 - 20ms (je nach Wahl) die Updatefunktion ausgelöst. Bei der sichtbaren App (in diesem Beispiel nur die arduino_led) wird zusätzlich noch
getScreen aufgerufen und es werden vorher Tastenevents an die DLL geschickt. (Das Programm wird auf der Logitech G19 angezeigt).

Ich weiß leider nicht, wo mein Fehler ist, dass es immer wieder zu abstürzen kommt, da ich zur Laufzeit die DLL ja nicht debuggen kann...

Viele Grüße!

[Sir Rufo]

Hmmm, ob du nun den FastMM einbindest oder um göttliche Unterstützung bittest ist in diesem Falle (strings) eins: nutzlos.

Nimm statt

Delphi-Quellcode:

string

einfach

Delphi-Quellcode:

WideString

und alles wird gut.

[Delphi-Narr]

Hm danke für den Tipp!
Ist das mit

Delphi-Quellcode:

PChar

nicht gewährleistet?
Habe jetzt überall in den Callback Funktionen und in der Init Funktion

Delphi-Quellcode:

WideString

als Variablentyp angegeben.
Mal gucken, ob es jetzt läuft ;)

Hm anscheinend hab ich immer noch was falsch gemacht...

[Sir Rufo]

Also deinen Quellcode habe ich mir nicht angeschaut, aber wenn jemand im Zusammenhang mit einer DLL von

Delphi-Quellcode:

string

spricht, dann kräuseln sich mir die Fußnägel ;)

Ja,

Delphi-Quellcode:

PAnsiChar

oder

Delphi-Quellcode:

PWideChar

funktionieren (der Speichermanager ist aber eigentlich egal, denn die DLL kann auch von anderen Programmen benutzt werden und da gibt es einige, die den FastMM nicht kennen).

Delphi-Quellcode:

PChar

würde ich nicht benutzen, denn dann ist der Typ abhängig vom Compiler (Unicode oder nicht).

Delphi-Quellcode:

WideString

ist ein Datentyp vom Betriebssystem und funktioniert problemlos über die Programmgrenzen (also DLL) hinweg.

UPDATE
Bei den GlobalStorage-CallBack-Funktionen hast du kein

Delphi-Quellcode:

stdcall;

angegeben. Absicht?

Warum definierst du dafür kein Interface? Das würde einiges entzerren.

[Delphi-Narr]

Kann ich verstehen ;)
Das mit dem fehlenden

Delphi-Quellcode:

stdcall

war keine Absicht, hatte ich schlichtweg vergessen.
Habe ich jetzt hinzugefügt. Das Interface ist für eine Version 2.0 schon geplant, aber erstmal wollte ich 1.0 zum funktionieren bringen.
Muss eventuell eine Konvertierung durchgeführt werden, wenn ich Funktionen, die String als Rückgabewert haben als WideString übergeben will oder wird das automatisch gemacht?

Sehr seltsam ist, dass das Programm im Debugger quasi problemlos läuft, ohne ihn jedoch meistens sofort abschmiert. Manchmal kommt trotzdem auch im Debugger der Fehler
"Priveligierte Anweisung"

[Sir Rufo]

Willst du die Funktion oder den Rückgabewert übergeben?

Das sollte so funktionieren

Delphi-Quellcode:

TSomeProc = procedure( Value : WideString ); stdcall;

var
  LSomeProc : TSomeProc;
begin
  ...
  LSomeProc( DateTimeToString( now ) );
end;

[Delphi-Narr]

Ich möchte nur den Rückgabewert übergeben, nicht die Funktion als solches.
So wie in deinem Beispiel sieht das bei mir jetzt auch aus, nur dass es statt

Delphi-Quellcode:

procedure

bei mir eine

Delphi-Quellcode:

function

ist.
Dann muss der Fehler noch wo anders liegen. Auch eine interessante Beobachtung: Ich habe noch zusätzlich zum "Start" Button einen Button auf das Formular gepackt, welcher lediglich die Farbe des Forms auf rot ändern soll.
Wird er zuerst gedrückt (vor Start), klappt es, während der "MainController" aktiv ist, passiert da nichts, der Quelltext wird nicht erreicht (Haltepunkt).

[Sir Rufo]

Wegen dem "Priveligierte Anweisung"-Fehler solltest du deinen Code unbedingt nochmal bzgl. der Aufrufkonventionen prüfen und auch auf nicht initialisierte lokale Variablen.

Wirft der Compiler Warnungen oder Hinweise bei einem kompletten Rebuild?

[Delphi-Narr]

Das werde ich tun. Welche Aufrufkonventionen meinst du dabei?
Ein paar Warnungen spuckt er auf jeden Fall aus, die beziehen sich aber hauptsächlich auf Funktionen in anderen Units, die nicht verwendet werden.
Wenn ich gleich zu Hause bin, werde ich das genau überprüfen und dann hier aktualisieren

[Sir Rufo]

Zitat:

Zitat von Delphi-Narr (Beitrag 1256945)

Das werde ich tun. Welche Aufrufkonventionen meinst du dabei?
Ein paar Warnungen spuckt er auf jeden Fall aus, die beziehen sich aber hauptsächlich auf Funktionen in anderen Units, die nicht verwendet werden.
Wenn ich gleich zu Hause bin, werde ich das genau überprüfen und dann hier aktualisieren

Diese Aufrufkonventionen meine ich

http://docwiki.embarcadero.com/RADSt...ufkonventionen

die müssen auf beiden Seiten (Anwendung, DLL) passen.