Ach darum geht das nicht. Dann meinte Traude wohl das es mit Lazarus unter Windows geht.

_________________
MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus

Lord Horazont schrieb:

Genau. Wird auch noch eine Weile dauern. Das kommt aber bestimmt, denn das ist ja genau der Grund, warum ich dieses Wahnsinnsprojekt überhaupt angefangen habe.

Lossy schrieb:

Du meinst das "ReleaseDC" nach dem Erzeugen des Rendering Context in der Methode osRenderContextCreate, nicht wahr?
Meine Quelle ist folgende: Windows SDK, Funktion GETDC, Remarks:

Kann natürlich aber auch sein, dass ich das missinterpretiert habe. Ich habe es versuchsweise weggelassen, und das scheint keinen Unterschied zu machen. Ich müsste erst genauer recherchieren, was da im Hintergrund wirklich passiert.

Lossy schrieb:

Da müsstest Du mir jetzt sagen, was Du da genau machst. Denn wenn Du das unveränderte Programm (mit allen nötigen Bibliotheken und einer gültigen Config-Datei) kompilierst und startest, sollte es eigentlich funktionieren.
Wahrscheinlich ist es so, dass Du einen eigenen RC erzeugen willst. Und da habe ich den Benutzer ein wenig im Regen stehen lassen. Es ist ja so, dass man für einen Rendering Context schon ein vorhandenes Window-Handle braucht. Man kann dafür aber nicht das TGUI-Window verwenden, weil

1) ein Hauptfenster sieht nach ob es einen RC <> 0 bekommen hat, wenn ja, nimmt es diesen, wenn nein, erzeugt es einen eigenen (ein Hauptfenster ist eines, das man mit dem Parameter "IsTheMainWindow=TRUE" mit der Methode TGUIMainWindow.Init initialisiert hat). Die Standard-Methode ist also, einen RC von Null zu übergeben.

2) Ein gewöhnliches Fenster (= ein Nicht-Hauptfenster) darf den RC zwar verwenden, aber weder erzeugen noch löschen und auch nicht setzen (damit meine ich: einen übernommenen RC sichtbar für alle anderen Fenster machen).

Und das ist natürlich nicht im Sinne des Benutzers. Der Benutzer braucht eine bequeme Möglichkeit, seinen eigenen RC zu erzeugen und sollte die GUI-Fenster damit beauftragen können. Derzeit ist das aber nicht möglich.
Man müsste das so lösen, dass zunächst einmal ein Nur-Fenster ohne Context erzeugt wird, damit der Benutzer seinen RC erzeugen kann und dann muss das Nur-Fenster in ein GUI-Hauptfenster umgewandelt werden, das alle weiteren nötigen Arbeiten erledigen kann (z.B. den Grafik-Utility-Manager erzeugen). Mit dieser komplizierten Vorgangsweise würde ich den Benutzer ungern belasten. Eine Alternative wäre, den PixelFormatDescriptor an das Hauptfenster zu übergeben.

Allerdings schiele ich bei allen diesen Dingen auf RTTI und das automatische Erzeugen des Fensters. Also, eine flexible Möglichkeit, den Benutzer seinen RC selber wählen zu lassen und gleichzeitig ein automatisches Laden per RTTI zu gewährleisten, habe ich noch nicht in Angriff genommen. Aber ich weiß, dass ich das noch machen muss. Das Programm wendet sich an OpenGL-Programmierer. Und ich weiß auch, dass der RC das Herzblut eines jeden OpenGL-Programmierers ist.

Lossy schrieb:

Grundsätzlich wäre das leicht möglich, wenn man die Verzeichnisse im Konstruktor des Administrators mitgibt. Hatte ich auch vorher so drin. Habe das aber geändert, als ich mit dem Testen anfing: Die Exe+Bibliotheken+Dateien auf einem Stick und damit auf fremden Computern testen, ohne die Daten auf den Computer kopieren zu müssen, da ist eine einfache Config-Text-Datei Gold wert.

Viele Grüße,
Traude

ReleaseDC: Ja ich meine das müsste osRenderContextCreate gewesen sein. Ich habe auch mal ein bisschen in den MSDNs gestöbert. Wobei man bei aller Liebe zu den MSDNs aber nicht vergessen darf, dass Microsoft nicht auf Seiten von OpenGL kämpft. Entsprechend werden meiner Meinung nach die Infos dazu nur noch der vollständigkeit halber "mitgeschleppt".

Ich denke aber diese Aussage bei ReleaseDC bezieht sich das klassischen Zeichnen mit der GDI. Denn da ist es so, dass man sich einen DC (GetDC oder BeginPaint) holt und diesem am Ende der Methode wieder frei gibt.

Bei wglDeleteContext steht, dass man nach dem Aufruf von wglDeleteContext den zugewiesenen DC mit DeleteDC löschen muss.
Bei DeleteDC steht, dass man es nicht verwenden muss, wenn man mit GetDC das Handle bekommen hat. Dann ist ReleaseDC richtig.

Sonst sind die Informationen zum Zusammenspiel eher ziemlich dürftig. Wobei ich aber auch mal in einer Anwendung von mir den DC freigegeben habe und urplötzlich habe ich keine OnPaint Events mehr bekommen. Bzw. du bräuchtest den DC spätestens dann wieder wenn du einen anderen RC aktivieren wolltest. Also ich würde da schon sagen, dass du den DC behalten solltest solange du OpenGL hast. Bei einem zweiten RC sollten die sich dann den gleichen DC "teilen".

Testanwendung: Ich habe das Zip entpackt und das TestProjekt kompiliert. Anschließend habe ich die guiconfig.txt auf meine Verzeichnisse umgebogen und gestartet. Dann kommt es sofort zu dem besagten Fehler.

Ich hatte in dem Zusammenhang halt auch mal geschaut ob du irgendwo die Funktionspointer der dglOpenGL lädst bzw ob du mit ihr den RC aktivierst. Wobei mir da gerade was einfällt. Welche Version der dglOpenGL.pas verwendest du? Ich tippe mal auf irgendwas zwischen 1.8 und 2.0.1! Der Header der noch .NET unterstützt hat (1.3 MB groß). Denn in dem war es so, dass die Funktionen des Headers sich selber geladen haben. Dort gab es für jede OpenGL Funktion eine passende Funktion im Header die nichts anderes gemacht hatte als sich selbst zu laden. Was dezent ausgedrückt, einen ziemlich kranken Verwaltungsaaufwand bedeutet hat und obendrein auch noch OpenGL Fehler produzieren kann. Deswegen hatte ich das der aktuellsten Variante rausgeschmissen. Und dann werden die Funktionspointer nicht mehr automatisiert geladen.

Verzeichnisse: Ich habe so etwas bei meinem usb stick und meinem Backupprogramm. Das Teil speichert in seinen Konfigurationen ab wo sich die zu letzt geöffneten Backupdaten befinden. Da ich auf einem anderen Rechner ab und an mal auf dem Stick was nachschaue ist das ziemlich nervig gewesen, dass ich jedes mal ein neues Verzeichniss auswählen musste, da dem Stick nicht das selbe Laufwerk zugewiesen war. Jetzt musste ich extra dafür in beiden Windows den Laufwerksbuchstaben so anpassen, dass es überall gleich ist.

Eine Konfigurationsdatei ist okay, besonders wenn es später mehr parameter werden. Allerdings sollte man den Entwickler da eher nicht einschränken. Denn aktuell wird die Datei ja immer geladen. Ob man will oder nicht. Aber ich bin was solche Sachen angeht auch ziemlich penibel, störrisch und engstirnig.

Das mit der Konfigurationsdatei wollte ich auch noch anmerken, das hat mich doch etwas gestört. Für das Testen hätte ich jetzt einfach ExtractFilePath(ParamStr(0)) + 'bla\' genommen. Das ist einfach und portabel und braucht noch nichtmal eine Datei

Gruß Lord Horazont

_________________
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

Hallo Lossy,

ReleaseDC: Na dann ist ja wohl das Eliminieren des ReleaseDC richtig. Denn wenn es keine Auswirkungen hat, ob es drinsteht oder nicht, ist es ja überflüssig.

@Windows API: manchmal kommt man ihr auf die Schliche, manchmal nicht, manchmal findet man etwas durch reinen Zufall heraus (ich zumindest). Die Beschreibung der Windows API, die bei meinem Delphi 7 dabei ist, ist ja offensichtlich uralt. Mich würde interessieren, wann diese Kerle wirklich aufgehört haben, Delphi zu warten. Wobei mir bewusst ist, dass diese "Kerle" vermutlich am wenigsten dafür können.


Ha, JA, genau. Ich habe diesen Header auch gar noch nicht allzulange, habe aber beim Herunterladen schon gemerkt, das das der Gleiche war, den ich schon hatte - ich muss wohl damals im Zeitdruck gewesen sein, den ich habe auf ein neuerliches Herunterladen damals verzichtet. OK, ich besorge mir den neuen Header und schau mal, was da zu ändern ist.

@Config-Datei: Das mit der Config-Datei ist nicht allzu ernst zu nehmen. Kann man auch leicht wieder ändern. Z.B. hat Lord Horazont auch (zu Recht) mal kritisiert, dass ich meine Themedatei zu statisch gehalten habe. Sie ist noch unverändert aber ich sammle Kritikpunkte immer in einer Liste und arbeite sie letzendlich ab. Diesen Thread hier nehme ich sehr ernst.

@Lord Horazont: ExtractFilePath(ParamStr(0)) + 'bla\': funktioniert das im Windows und Linux gleichermaßen?

Danke fürs Feedback
Traude

ExtractFilePath ist eine SysUtils funktion und zumindest unter FPC entsprechend angepasst. Bei den \ und / kannst du dich auf die Variable PathDelim verlassen, die glaube ich in System oder SysUtils deklariert ist. Die hat immer den richtigen Wert. Vollkommen korrekt hieße es also:
ExtractFilePath(ParamStr(0)) + 'bla' + PathDelm

Ich habe aber bei meinem "virtuellen" Dateisystem noch eine automatische umformung zur aktuell passenden Version dabei. Ich weiss nicht, inwiefern das für dich in der GUI in Frage kommt (by the way, hast du eigentlich möglichkeiten, eigene Dateisysteme einzuhängen, also irgendwie zu verhindern, dass deine GUI automatisch TFileStream.Create benutzt? Wäre für VFS sehr praktisch).

Gruß Lord Horazont

_________________
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

Nein hab ich nicht, klingt aber interessant, und zwar deshalb, weil ich mit meinen Pascal-FileStreams und überhaupt mit der ganzen Dateiverwaltung sowieso nicht sehr glücklich bin - das Dateisystem ist der einzige Bereich, der kein Unicode unterstützt (weder in Delphi noch in FPC).

Bei einer GUI ist das nämlich haariger als anderswo, denn ich dringe zum Benutzer durch. Angenommen ich bin ein Russe, dann möchte ich meine Dateien auch mit cyrillischen Buchstaben benennen, ist doch klar. Eingeben könnte das der Russe in einen File-Save-Dialog, denn die GUI-Elemente können das. Aber der FileStream kann es nicht. Der Russe kann sich auch keine cyrillischen Dateinamen anzeigen lassen, weil die Dateiverwaltungsfunktionen auch nur 8 Bit können. Das macht aber garnichts, denn die cyrillischen 16Bit Dateinamen schaffen es ohnehin nicht auf die Platte, sondern werden dabei verstümmelt. Mumpf.

Eigentlich müßte man die die Dateiverwaltung UND das Laden und Speichern auf eine ganz neue Basis stellen. Das ganze ist aber ein Zeitproblem, denn ich sammle zwar hier Hinweise, was ich übersehen habe und muss die dann natürlich auch umsetzen, aber ich möchte eigentlich nicht von meiner Roadmap abweichen, denn da sind noch ein paar größere Brocken dabei. Hinweise wie das mit dem neuen Header ziehe ich vor, weil das natürlich vordringlich ist, gibt ja auch einen Geschwindikeitsschub. Das Dateisystem möchte ich eigentlich nicht vorziehen, weil ich da bestimmt längere Zeit hängenbleiben werde.

Naja eine Notlösung währe bestimmt jede Datei als Zahl zu speichern und in der Datei selbst den Wirklichen namen.
Weißt du wie ich meine ? das ist zwar blöd, aber dafür am sichersten und bestimmt auch nur eine Notlösung.

Du könntest in der Datei ja an erste Stelle den richtigen Namen speichern, aber der Dateinamen selbst ist "nur" eine Zahl mit einer passenden Endung.
Ich weiß nicht warum das beim Dateisystem sowieso nicht intern so gemacht wird. Das währe doch das beste oder nicht?

Oder spricht da was da gegen ?

_________________
MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus

Meine Notlösung schaut derzeit so aus, dass ich das Problem verdränge. Nicht sehr professionell, ich weiß, Ich hab inzwischen in irgendeinem Delphi Forum eine FileStream-Komponente entdeckt, die Unicode kann. Vielleciht komme ich später mal drauf zurück.

Zahlen in einem normalen Verzeichnis hätte ich nicht so gerne, weil Zahlen für Menschen ziemlich unanschaulich sind.

so meinte ich das auch nicht. Die Zahlen sollten nur dazu dienen die Dateien öffnen zu können.
Z.B.

Ich habe einen Datei namen mit umlauten:
Nasenbär
Das Dateisystem speichert Nasenbär in ein uniCode String oder so.
Also so wie auch das Änderungs Datum gespeichert wird.

Naja, aber evlt. ist das im Moment noch gar nicht so wichtig.
Wenn ich mal lust habe kann ich ja mal schauen, ob ich diese

OSSupport
anpasse für Lazarus.


Klinkt nicht schlecht.

PS: Einige deiner antworten lese ich leider erst jetzt.

Evlt. könntest du das noch so machen das auch Canvas unterstützt wird.

Toll währe es wenn die Komponente unbändig von verwendeter Grafik Schnittstelle währe.

_________________
MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus

Pluto schrieb:

Rein Grundsätzlich ist das System so aufgebaut, dass es genau das können soll. Aber - ich habe meine ersten Gehversuche in Grafikprogrammierung auch mit der Canvas gemacht (eine Kugel aus Vierecken, die sich dreht). Und bin dann auf OpenGL umgestiegen. Ich würde sagen: beides probiert, kein Vergleich.
Traude

PS: Aber eigentlich hast Du doch Lazarus - Bist Du damit nicht zufrieden?

wie meinst du das ?
Du verwendest doch jetzt OpenGL oder ?

Evlt. währe es schöner, wenn für die GUI Canvas genommen wird oder so, und für "aufwendige" Animationen OpenGL bzw. das auf Wunsch natürlich auch OpenGL oder Canvas verwendet wird...

_________________
MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus

Ja ich verwende reines OpenGL. Ich meine, dass es mit OpenGL besser ist als mit der Canvas. Mit der Canvas zu zeichnen war mühsam. Die Schrift ist etwas anderes. Hier tut man sich mit der Canvas leichter. Aber wenn man mal ein gutes Schriftsystem hat, ist das in OpenGL auch kein Problem mehr. Im Gegenteil, man hat dann z.B. auch 3D-Schriften zur Verfügung.

ach... das währe für mich ein Grund das mal in OpenGL zu Probieren. Zeichnest du Ständigt ? oder nur dann wenn es notwendig ist ?
Allerdings läuft OpenGL nicht auf allen Rechnern Problemlos, Canvas hingegen schon.

_________________
MFG<br> Michael Springwald, <br>
Bitte nur Links in Deutsch, nutze überwiegend Lazarus

Mal das eine, mal das andere. Es kommt auf die Anwendung an. Bei der GUI pass ich sehr auf, dass nur dann gezeichnet wird, wenn es wirklich nötig ist. Die GUI "steht" praktisch ziemlich oft. Wenn sich etwas auf dem Bilschirm tun soll, dann muss natürlich ständig gezeichnet werden, bei einem Spiel zum Beispiel. Ist ja auch nicht anderes als ein Daumenkino.