Hallo,
erst mal eine kurze Einführung in die Umgebung:
Ich entwickle z.Zt. in Lazarus/WinXP32bit eine Arbeitsumgebung, die (3) OpenGL-Kontexte zum Output verwendet.
Für das Problem relevant sind zwei Formulare, 'MainForm' und 'OutputForm', auf MainForm befinden sich zwei DCs in Panels, auf der OutputForm der dritte.
Da die Ausgabe animiert ist, ruft ein Timer (auf MainForm) nacheinander alle Kontexte auf und rendert.

Läuft alles bisher prima, nun zum eigentlichen Problem:
Das Programm muss bisweilen Nachrichten via ShowMessage oder MessageDlg ausgeben. Diese Dialoge lassen sich aber nicht mehr schließen, wie als ob auf den Buttons keine onClick-Methoden hinterlegt wären (gilt auch für den Schließen-Button oben rechts).
Folgende Ursache konnte ich isolieren: Das Problem tritt nur auf, wenn der Timer läuft, genauer gesagt nur, wenn SwapBuffers des Kontextes auf 'OutputForm' regelmäßig aufgerufen wird. Erhöhe ich das Timerintervall von 30 auf 50, funktioniert ebenfalls wieder alles.
Natürlich will ich weder das Timerintervall vergrößen, noch auf den OGL-Output auf dem Zweitformular verzichten.

Hatte jemand von Euch bereits ähnliche Probleme bzw. Ideen, wie man das lösen könnte?
Alle Ansätze sind willkommen, ich bin gerade am Verzweifeln...

Gruß, Josua

Schade dass keiner Rat weiß.
Dann werde ich wohl erst mal mit Behelfslösungen auskommen und später evtl. ganz auf Standard-Dialoge verzichten müssen. Diesen Thread lass ich noch ein paar Tage offen, für den Fall dass doch jemand antwortet.

MfG, Josua

Lässt du dem Betriebssystem auch irgendwo Zeit die Nachrichten die es bekommt (u.a. durch das Drücken der Buttons) zu verarbeiten? Wenn nicht, dann liegt es daran. Ruf doch nach dem Rendern (z.b. nach SwapBuffers) unter Windows Application.ProcessMessages auf. Diese Funktion arbeitet alle offenen Nachrichten ab, und dann sollten auch deine Dialoge wieder funktionieren. Bei einem hohen Timerintervall hat das OS natürlich wieder Zeit dies selbst zu erledigen, weshalb es dann klappt.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Ein guter und sinnvoller Vorschlag, aber daran liegt es nicht, das hab ich bereits versucht. Ein zusätzliches ProcessMessages im OnTimer-Event hat nichts bewirkt.
Abgesehen davon, die Buttons reagieren, wenn auch nur rein optisch (Fokus, Klick-"Animation"). Das spricht dagegen, dass die Eventqueue nicht abgearbeitet wird. CPU-Auslastung des Programms ist übrigens i.A. <5%, es soll ja eine Betriebsanwendung sein und kein Game Wers will, ich hab den Prototypen zur Veranschaulichung beigefügt; der Fehler lässt sich leicht reproduzieren, wenn man z.B. versucht, eine der Schriften unten links zu löschen.

Das Programm (unfertig): BeamIt.zip (2MB)

Ich hab mal testweise die genauen Grenzen der noch möglichen Intervalllängen ermittelt: ab Timereinstellung 32 funktioniert es wieder. Damit ist es kein so großes Problem wie zuerst angenommen, aber es nimmt mir leider die Möglichkeit, die etwas ruckeligen Animationen auf diese Art einfach flüssiger zu gestalten.
Ich denke allerdings, dass ich zum Kompromiss greifen werde, dass ich das Timerintervall dynamisch vergrößere, sobald ein Modalfenster angezeigt wird, und danach wieder herabsetze. Unsauber, aber sollte klappen.

Sollte jemand noch Ideen haben, wie man das Ganze lösen kann, anstatt Workarounds zu treffen, dafür bin ich natürlich weiterhin offen und dankbar...

Gruß, Josua

Verwende doch einfach einen asynchronen (z.B. threaded) timer auf jedem der Formulare, die arbeiten in der Regel nicht auf auf WM_TIMER Basis.

Modale Fenster blockieren jedoch die message queue und deswegen werden keine Nachrichten (z.B. WM_TIMER (vom TTimer)) nicht abgearbeitet, deswegen werden deine Fenster auch nicht gerendert.

In dem kannst du dann aber nicht Rendern, da du den OpenGL-Kontext nur in dem Thread verwenden kannst, in dem er erstellt wurde. Erstellen kannst du ihn nur da, wo auch dein Fenster erstellt wurde… Was wiederum im Hauptthread ist, in dem auch die modalen Fenster liegen. Dass die modalen Fenster in einem anderen Thread arbeiten können, glaube ich auch nicht, aber da fängt das gefährliche Halbwissen an. Zumindest habe ich in erinnerung, dass die WinAPI generell nicht Threadsafe ist, was die Fenster betrifft.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Die Fenster werden ja gerendert, auch während aller Dialoge (das kann man in dem angfügten Programm leider ohne die Datenbank mit renderbaren Inhalten nicht direkt sehen, du kannst aber mal ein neues Lied erstellen und per Drag'n'Drop auf eines der schwarzen Panel ziehen (Zweitfenster übrigens per F10/F11 steuerbar)).
Die Problematik beschränkt sich im Eigentlichen auf die Modalfenster, die sich zwar öffnen, aber nicht wieder schließen lassen.



Seh ich genauso. Ich denke, die Modaldialoge funktionieren nur modal, weil sie eben den aktuellen Thread (bis auf die eigene message queue) blockieren, bis sie abgearbeitet sind. Dialoge in anderen Threads bedürften einer ganz anderen Blockierungsmethode. http://de.wikipedia.org/wiki/Dialogfenster#Modale_und_nichtmodale_Fenster legt nahe, dass modale Dialoge generell nicht in weiteren Threads liegen (können?).

cheers

die lösung des problems, heißt dann wohl gänzlich auf messagebox und co der winapi verzichten und ne eigene kleine gui basteln oder eine fertige bemühen

naja gute nacht erstmal bin zu müde um nochmal weiter auszuholen

Was gibt es denn da an fertigen Komponentensuites, die Lazarus/FPC - kompatibel sind, nicht schneckenlangsam, weitgehend vollständig und auch noch optisch gut anzusehen?
Ich hatte aus Designgründen (TPageControl ist ein Designkiller) schon vorher mal überlegt, sowas zu machen, aber ich könnte mir vorstellen, dass da recht wenige Optionen offenstehen, wenn obiges alles erfüllt sein sollte.
Dieser Seite nach gäbe es die Möglichkeit, GTK (1,2), QT oder "fpGUI" zu verwenden, ich habe soweit noch mit keinem gearbeitet.
Hast du schon sowas gemacht und vielleicht eine Empfehlung?
lg

gtk, qt, fpgui und co sind ansich ja nur wrapper die den presentation layer des jeweiligen betriebssystems (w)rappen

ich meinte eigentlich eine gui die im opengl kontext selber läuft/gemalt wird.

hier im dgl-club hat mal jemand ein kleines gui system geschrieben, mir fällt aber der name gerade nicht ein (die forum suche hilft da eventuell)

http://www.delphigl.com/forum/viewtopic.php?f=13&t=7616

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Danke für den Link, die GUI in OGL zu rendern ist aber wohl nicht praktikabel. Zum einen soll das Programm auch auf Netbooks mit minimaler OpenGL/3D-allgemein-Unterstützung flüssig laufen, zum anderen möchte ich die Verwendung von OpenGL überhaupt in einer späteren Version kapseln und alternative Renderer (DX, CPU) anbieten.

Und was QT & co angeht, versteh ich da was falsch, oder sind das nicht sog. leichtgewichtige Komponenten, die sich erst mal komplett selbst organisieren und zeichnen und nur im letzten Schritt die Win32-API bemühen (Panel, Window oder DC)? Wenn dem so wäre, stehen die Chancen gut dass modale Fenster neu und abseits von Win32 implementiert werden.

greetings