Registriert: Di Dez 16, 2014 10:18 Beiträge: 32
Programmiersprache: C++
Guten Morgen, ich möchte gerne eine Windows Anwendung schreiben. Ich arbeite mit VS2013 C++. Die Benutzeroberfläche würde ich mit Windows Forms realisieren. Die OpenGL RC/DC wird einem panel zugewiesen; nach diesem Schema: http://www.codeproject.com/Articles/160 ... ndows-Form
Es funktioniert auch alles einwandfrei, also die Szenen werden alle so dargestellt wie ich es möchte. Nun möchte ich ein picking einbauen. Also eine Interaktion mit der Maus, die z.B. Punkte verschieben kann.
Ich wäre folgendermaßen vorgegangen:
Dem panel ein MouseMove Event zuweisen (Wenn die Maus über dem Handle bewegt wird, wird eine Funktion aufgerufen)
Falls die Cursor sich über einem Punkt befindet, kann dieser verschoben (Ändern der Darstellung des Cursor, Klicken und ziehen sodass die Koordinaten verändert werden und wieder anzeigen lassen)
Problem: Wenn ich dem RC/DC das Handle von dem panel zuweise, scheinen keine Events des panels mehr zu funktionieren. Sprich, wenn ich die Maus über dem panel bewege, wird die Funktion nicht aufgerufen.
Meine Frage: Das Warum würde mich interessieren? (optional) Welche Lösungsansätze gibt es, um das zu umgehen? Kann man openGL auch anders in Windows Forms darstellen? Oder ist auch alles Quatsch was ich da betreibe? Welche anderen Möglichkeiten gibt es die Anwendung zu verfassen? Also keine Windows Forms, sondern z.B. MFC, ... (Windows Forms erscheinen mir relativ einfach, daher habe ich mich dafür entschieden).
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
NativeWindow verarbeitet Events über WndProc und wenn man ein Form erzeugt, wo das NativeWindow als Child agiert(eigentlich üblich, sonnst braucht man Windows Forms garnicht), dann muss man die Events vom Form und NativeWindow angucken(WndProc und parent Variable setzen). Beispiel
NativeWindow ist ein bisschen trügerisch, man kann ein Fenster erzeugen aber eigentlich erlaubt die dahinter liegende API das erzeugen jeglicher Windows Komponenten(class Variable), vom Button bis hin zu einem Fenster. Wenn man ein OpenGL Context haben will in Windows Forms, dann erzeugt man in der Regel eine Panel oder Control Komponente und benutzt den Window Handle sowie Device Context um der OpenGL API zu sagen "über den Bereich rendern". Je nach dem welche Komponente man erzeugt sind bestimmte Eigenschaften gesetzt. So hat z.B. ein Window default ein Window Decorator der sich um den Fensterrahmen kümmert und alle Events werden durchgeschleift und ein Button besitzt diesen nicht. Label haben z.B. keine Keyboard Events aber letzlich kann man alle Filter selber einstellen und das macht man auch, wenn man selber ein Fenster erzeugt, ohne Windows Forms.
edit: Ich persönlich mag WPF mehr und hab für meine letzte App SharpGL verwendet. Das kann man ganz bequem über Visual Studio Extension Manager laden und installieren und es sind Beispiele dabei. Da gab es aber noch ein paar bugs im OpenGL 3-4 Kontext.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Mo Nov 08, 2010 18:41 Beiträge: 769
Programmiersprache: Gestern
beecksche hat geschrieben:
Das Warum würde mich interessieren? (optional) Welche Lösungsansätze gibt es, um das zu umgehen? Kann man openGL auch anders in Windows Forms darstellen? Oder ist auch alles Quatsch was ich da betreibe? Welche anderen Möglichkeiten gibt es die Anwendung zu verfassen? Also keine Windows Forms, sondern z.B. MFC, ... (Windows Forms erscheinen mir relativ einfach, daher habe ich mich dafür entschieden).
1.) Kann verschiedene Ursachen haben, am wahrscheinlichsten ist das dein "Fenster" (=Panel) Transparent ist oder das dein Fenster nicht angezeigt wird. 2.) Probier mal ShowWindow auf dem WindowHandle deines Panel nachdem du OpenGL aktiviert hast und schau dir vorher den Style an wegen der Transparenz. 3.) Nein, OpenGL braucht unter Windows immer einen DeviceContext. Wenn du kein Fenster (viele Controls wie etwa Panel sind intern Fenster), dann bleibt nur ein Bitmap. Da schaltet OpenGL aber auf Softwarerendering um. 4.) MS sagt das du keine Forms Projekte mehr machen sollst. Aber das ist deine Sache 5.) Ja da gibt es eine ganze Reihe an Moeglichkeiten. Am einfachsten duerften wohl solche Wrapper wie OpenTK sein.
Welche anderen Möglichkeiten gibt es die Anwendung zu verfassen? Also keine Windows Forms, sondern z.B. MFC, ... (Windows Forms erscheinen mir relativ einfach, daher habe ich mich dafür entschieden).
Wen du es möglichst einfach haben willst und es nicht zwingend C/C++ sein muss, würde ich mir mal Lazarus angucken. Da wird dir sehr viel Arbeit abgenommen, was Panels, Forms, etc. betrifft.
Registriert: Mo Sep 23, 2002 19:27 Beiträge: 5812
Programmiersprache: C++
beecksche hat geschrieben:
Welche anderen Möglichkeiten gibt es die Anwendung zu verfassen? Also keine Windows Forms, sondern z.B. MFC, ... (Windows Forms erscheinen mir relativ einfach, daher habe ich mich dafür entschieden).
Wenn es rein um OpenGL und Fensterhandling geht, dann glfw.
Braucht man noch was drumherum, also Komponenten wie Panels, Buttons, Dropdowns etc. dann qt.
Ansonsten gibt es direkt von Khronos auch nocht EGL, aber das bietet (zumindest unter Windows und für OpenGL) afaik nur ATI/AMD an.
Beide Lösungen laufen auf sehr vielen Platformen. Mein glCapsViewer z.B. ist mit qt gemacht und lässt sich dank CMake recht einfach auf Windows, Linux und MacOSX erzeugen
"etwas frickelei" habe ich für mich schonmal relativ abstrahiert implementiert, ich weiß nicht ob das leuten hilft: quickglscene.hppquickglscene.cpp Das ist lose an meine Engine gebunden, die Referenzen auf den Rendergraph kann man einfach wegstreichen und die Methoden paint() und sync() entsprechend anpassen. In sync() müssen die Daten vom UI-Thread an den oben erwähnten OpenGL-Thread übergeben werden, in paint() läuft der OpenGL Thread und man muss seine Rendercalls durchführen. Der paint() aufruf läuft vor allen anderen Drawcalls, die Qt durchführt, sodass man unabhängig von der Widgetreihenfolge im Tree immer ganz "unten" liegt. Wenn man das nicht will, dann braucht man andere Methoden für das Rendern (z.B. erstmal in eine Textur und dann sich tatsächlich in den Qt Scene Graph reinhängen). Für meinen Use-Case aber nicht erwünscht.
Zusätzlich bietet die Klasse noch Signals, z.B. advance(), welches kurz vor dem nächsten Frame angibt, wieviel Zeit seit dem letzten Frame verstrichen ist. Die Klasse kann als QtQuick-Control registriert werden:
_________________ 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
Mitglieder in diesem Forum: 0 Mitglieder und 14 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.