okay, initialisert isses, nächstes problem bitte - ich machs mir wohl heute nicht mehr einfach... :/
(diesmal weniger Code und mehr Pointer - sry again)

Zum problem:

ich erstelle mit schön vielen Pointern in ner OnClick-Prozedur ein Panel und einen neuen Thread, der OpenGL initialisiert, malt und schliesslich, beim Mausklick auf das panel wieder deinitialisiert. So weit, so gut.



Noch funktioniert alles.
Wenn ich jetzt aber (z.B. beim OnDblClick des Panels) den Destroy des Panels aufrufe, crasht das programm.

ich habe es getestet, das Panel zu erstellen und zu zerstören, ohne mit OpenGL drauf zu malen, macht keine probleme.
der Thread ist sicher beendet und OpenGL ist auch korrekt Deinitialiser

und falls damit jemand was anfangen kann:

Der Destruktor des Panels


und der Thread

Die Showmessage mit "Thread beendet" WIRD angezeigt!

Also der letzte Code hat mir entschieden besser gefallen. Dann will ich mal anfangen.

1: Pointer auf Klassen sind schwachsinnig, da Klassen selber bereits Pointer sind. Das new davon ist noch unsinniger, da du den Speicher jetzt praktisch doppelt belegt hast, da die Klasse ja mit .create alloziiert und erstellt wird. Also das würde bei mir in etwas so aussehen.


2: Zu dem problem. Ich schätze mal, dass es daher rührt, dass du dem thread sagst er solle sich zerstören (terminate) und just danach bereits sein komponente zerstörst. Dabei kann es aber sein, dass er kurz zuvor schon deine Terminated abfrage passiert hat und dann lustig weiter rendert obwohl das Objekt bereits gar nicht mehr da ist. Das kann nur schief gehen. Dein Destroy muss mit dem zerstören so lange warten, bis der Thread fertig ist.
Eine Möglichkeit wäre ein TEvent welches du nach dem Term setzt und vor dem destroy so lange darauf wartest, bis es gesetzt wurde.

Abgesehen davon funktioniert ShowMessage in Threads nicht. Kann dir jetzt nicht genau sagen warium ist aber so. Ich meine MessageBox von Windows könnte aber schon funktionieren.

Ich weise nochmal auf das OnIdle Event hin, falls du nicht unbedingt den zusätzlichen Thread benötigst. Wenn man den Parameter done auf false setzt, dann wird das Ereignis ständig aufgerufen und man hat Nebenläufigkeit ohne sich um die Threadsicherheit zu sorgen. Bei den VCL Funktionen muß man nämlich immer aufpassen, weil die meisten nicht für mehrere Threads ausgelegt sind.

@showmessage: Meine ich doch, dass ich das schonmal irgendwo hatte und mich auch gefragt hatte, woher das kommt. Bei einem Netzwerkprogramm führte das stellenweise sogar zum Totalverlust des Threads. Fall jemand dafür mal eine logische Erklärung findet ...

_________________
"Light travels faster than sound. This is why some people appear bright, before you can hear them speak..."

ShowMessage erstellt ja eine eigene Form für den Dialog und ruft nicht die MessageBox von Windows auf. Vermutlich darf man das nur aus dem VCL Thread heraus machen, so daß man da mit synchornize arbeiten muß.

hm, das ist mir jetzt ehrlich gesagt zu hoch - wie gesagt, das liegt in ner onclick-prozedur, wenn ich das ganze als lokale variable der prozedur machen würde würde diese ja automatisch beim beenden der prozedur destroyed, meinen tests zufolge destroyed sich damit auch das panel selbst (also ist es nicht nur ein pointer?) - bei ner erstellung per new() bleibt das ganze aber auch wenn die prozedur abgelaufen ist



das problem ist aber: wenn ich erst den thread beende, 10 sekunden warte und dann das panel zerstöre... das ergebnis kommt aufs selbe raus


es wird wohl drauf rauslaufen dass ich es letztendlich doch mit Onidle mache, auch wenn ich lieber 4 Render-Threads mit niedriger priotität und einen mit normaler prio für die berechnung der koordinaten der körper (ist ne simulation, also soll die berechnung so genau wie möglich werden) hätte


die showmessage wird angezeigt, kann natürlich sein dass dann im hintergrund crasht - wenn du mir dazu mehr sagen könntest wäre das natürlich toll

Ja klar. Damit bleibt der Speicherbereich in dem der Pointer deiner Klasse abgelegt auch nach der Beendigung deiner Prozedur erhalten. Spaß bei Seite. Deine Klasse bleibt so lange im Speicher bis jemand free aufruft. Wenn dies nicht geschieht, weil niemand mehr eine Variable mit der Instanze deine Klasse hat, dann wird sie beim Beenden des Programms von Windows entfernt.

Anders Beispiel zum Verständis von Klassen.
Blub beinhaltet nun auch eine vollständige klasse. Und es existiert nur EINE instanze deiner Klasse. Aber zwei Variablen die auf diese Klasse zugreifen. Ich hoffe das Hilft ein wenig. Ein gut gemeinter Rat von jemanden der das schon länger macht. Lass die Threads sein und beschäftige dich erst einmal mit normalen Objekt Orienterter Programmierung. Also bevor du da jetzt mit irgendetwas weiter machst. Das ist wirklich nicht böse gemeint aber du solltest dringesnst mal ein wenig mit Objekten beschäftigen bevor du da weiter machst.


Jain. Das Ergebniss ist womöglich das Selbe. Muss aber nicht. Durch das Event würde nur sichergestellt werden, dass das Panel noch existiert so lange du noch darauf zeichnest. Du kannst ja nicht, das Panel (inklusive WindowsHandel) zerstören und OpenGL versucht dann noch auf das Fenster zu zugreifen. Das wäre so in etwa als wolltest du mit deinem Auto fahren, was dir 10 Sekunden voher geklaut wordern wäre!!! Das geht ja auch nicht. Hoffe das war ein wenig verständlich, was ich damit meine.


Willst du mit den Threads nur zeichen oder soll da auch noch Interaktion oer so etwas bei sein?


Wie gesagt weiß es nicht mehr so 100%tig. Werde mich aber mal schlau machen. Allerdings hatte ich das Phänomen bei mir. Könnte aber auch woanders dran gelegen haben. Probiere es aber mal aus und gebe dann bescheid.

*gg*
sich mit OOp zu beschäftigen wird da wohl keinen Sinn machen, es wird eher Sinn machen, sich mit Delphis interpretation von OOP zu beschäftigen - und da gebe ich zu bin ich nicht wirklich auf dem laufenden



du verstehst mich falsch - angenommen ich habe 2 buttons, einer von beiden um den thread zu beenden und einer um das panel zu destroyen. ich beende also erst den thread und warte dann bis ich sicher sein kann dass er sich beendet hat (von mir aus auch ein jahr, das ergebnis wird das selbe sein) - selbst wenn ich dann das panel zerstöre crasht es
oder soll ich dich so verstehen, das openGL ein eigenleben entwickelt und selbst dann noch rendert wenn mein thread es nicht mehr tut??



ich wollte in einem Haupthtread berechnungen machen und eine DisplayList erstellen, und dann in x anderen threads x verschiedene ansichten auf die selbe szene (mit niedrigerer Priorität) machen... naja, muss so dann wohl auch klappen
Interaktion - nein


da ist das merkwürdige, dass das 100% funktionierte - ich konnte showmessage 3mal im thread aufrufen und bekam sie auch dreimal angezeigt... naja, das showmessage hatte ich ja eh nur zwischendrin zum fehlersuchen drin (sagt mehr aus als ein beep ) - ohne tat es ja auch nicht


inzwischen habe ich angefangen, das ganze ohne Threads zu bauen, allerdings interessiert es mich immernoch warum das nicht ging *gg*

Bitte? Was ist denn an Delphis OOP "falsch"?


Dann habe ich dich wirklich falsch verstanden. Das sollte dann kein Problem des zerstörten Panels sein. Hattest du das Programm mal so umgestellt wie ich es in dem Beispielcode gemacht hatte? Also überall bei den Objekten das ^ weg? Auch im Destroy des Panels? Ich kann es mir nur dadurch erklären, dass du irgendwo auf etwas zugreifst was du nicht darfst.
Wie Crasched das Programm denn? Unbekannter Software Fehler, Access Violation oder invalid Pointeroperation? Und vor allem viel wichtiger wann? Wenn du das Panel zerstörst, wenn der Thread zerstört wird oder wenn du das programm beendest? Hattest du auch mal versucht den Fehler im Debugger von Delphi zu finden? Der springt kleverer Weise dahin wo der Fehler aufgetreten ist. Meistens jedenfalls.


Dadurch, dass du mitels einer Displayliste arbeitest kannst du dir eigentlich die Threads sparen, da die Threads eh warten müssten, bis die Liste fertig ist und dann kannst du die Zeichnungen auch 100%tig gleichtig im Hauptthread (Application.OnIdle) machen. Es würde sich da vielleicht eher lohnen die Berechnungen in einen Thread auszulagern. Und wenn der Thread mit den berechnungen fertig ist, dann per Synchronize die Aktualisierung der Displayliste anzustoßen. Dann aktualisierts du die Liste auch nur genau dann wenn nicht gerendert wird. Oder es wird nicht gerendert wärend aktualisiert wird. Ist nur so eine Idee die mir spontan einfällt. Wobei es da auch wieder darauf ankommt was du alles berechnest.

"falsch" in dem sinne nichts, bloss hat jede sprache in der realisierung des ganzen ziemliche unterschiede und wenn man 2 jahre nix mit delphi gemacht hat und sich zwischendrin in php und java ein bisschen einarbeitet hat man einfach "andere" vorstellungen
(beispiel: bei java ist ein String schon ein recht kompliziertes Objekt, bei Delphi... naja, ein string halt ^^)


da ich inzwischen das ganze programm auf ne Feste zahl an Fenstern umgeschrieben habe kann ichs leider nicht mehr testen *gg*
aber ich merk mir das für die Zukunft



naja, das mit displayliste kommt mir inzwischen auch spanisch vor... wenn ich sie viermal nacheinander auf verschiedene DCs zeichne wird sie nur auf dem letzten gezeichneten DC dargestellt oO habs jetzt vorerst mit ner zeichen-prozedur gelöst bis ich mein Wissen über Displaylisten entsprechend erweitert habe *seufz*

Und das mit den Transformationen und Matrizen... puäh, das werden schöne Ferien ^^
(Frage zu gluLookAt: wenn die letzten drei Parameter 0,1,0 sind darf ich nicht senkrecht nach oben oder unten schauen, sonst gibts Probleme oder?)

Hallo erstmal,

ich lese hier schon länder mit und musste mich doch gleich mal regestrieren wo ich das hier lese

wie Lossy eX schon sagte kannst du in delphi bei objekten das "^" immer weglassen, da diese schon "von haus aus" immer zeiger sind.

das problem mit dem beenden deines threads dürfte ein kombination aus dem folgendem sein:






ich gehe mal davon aus das p^.Thread in deinem panel in ungefähr so definiert ist:



jetzt übergibst du aber die adresse vom dem speicherbereich wo dein thread ist und nicht den zeiger auf den thread.
sprich du hast zwar auch wieder einen zeiger (delphi handelt "@" und "^" beide als zeiger) der aber irgendwo hinzeigt, nur ich auf deinen thread

@T^ ist die adresse wo dein thread abgelegt ist.
T^ ist der zeiger auf deinen thread.


das zweite problem ist, das du überprüfst ob deine thread-variable ungleich nil ist (Thread <> nil) und greifst dann aber auf den speicherbereich zu auf den deine thread-variable zeigt (Thread^.Terminate) zu, der aber nil sein kann


zu dein timing problemen mit deinem thread.
mach einfach "Thread.WaitFor" nach dem "Thread.Terminate". dann kannst du sicher sein das er wirklich zerstört wurde.

ps.
hier findest du etwas über zeiger und delphi: www.delphi-source.de

puh, danke erstmal

wie gesagt, momentan komme ich auch inzwischen ohne den thread aus und vor allem mal ohne pointer ^^ - aber sobald ich meinen nächsten thread bastel oder auch nur an nen pointer denke werd ich das hier mindestens dreimal durchlesen

danke!

Freut mich ja, wenn sich deine Probleme in Luft aufgelöst haben.

Wie versprochen habe ich mir mal die Threads angeschaut und folgendes äußerst merkwürdiges festgestellt.


Der Code liefert eine Exception.


Dieser Code hingegen funktioniert anstandslos.

Warum das eine geht aber das andere aber nicht darüber kann ich nur spekulieren. Allerdings scheint das MessageBox irgendetwas zu machen, damit das ShowMessage funktioniert. Ergo. Am Besten die Finger von ShowMessage in reinen Threads lassen. Das funktioniert mit einem entschiedenen manchmal. Sofern man allerdings ein Fenster (TForm) aus dem Thread erstellt hat klappt das ShowMessage.

PS: zum Thema Multithreading gibts hier ein äußerst interesantes Multithreading Tutorial. *selbstbeweicher*