Das deutsche QBasic- und FreeBASIC-Forum

[Sebastian]

[OneCypher]

@Cherry: ABSOLUT KRASS

Ich hatte sowas ähnliches überlegt um mehrere Buffer-Fenster in einem MDI-Fenster unterzubringen!
Ich schätze, mit der attach-funktion wird genau das auch funktionieren!

Leider werd ich in den nächsten tagen und nächste woche nicht dazu kommen das genau auszuprobieren, aber, das ist schon absolut fantastisch!!!

Ich mag die fb-gfx-lib auch lieber! Da erscheint alles noch aus den QB-Zeiten so vertraut

Kennst du eine möglichkeit die Funktion DoEvents() in einen Thread zu packen?
So dass das fenster sich auch ohne expliziten aufruf der jeweiligen DoEvents-Funktion erneuert?

Bei mir stürzt das programm immer ab, sobald ich .DoEvents in einen Thread packe

Das mit dem NULL-Screen ist ne feine sache , die funktion, so wie du sie implementiert hast, hatte ich auch innem SDL-Projekt realisiert.

Einzig schade wäre, wenn man das "nur" für Windows so realisieren kann. Für Linux wär sowas auch klasse
Vielleicht mit GTK? Da hatte ich ja auch mal was mit versucht.. aber das is ziemlich instabil, wenn man dort die gtk_main() als Thread aufruft..
( http://forum.qbasic.at/viewtopic.php?t=7079 )

[MOD]

DoEvents ist eine Funktion innerhalb eines UDTs, da will das Threadstarten nicht ohne Weiteres.

Das Problem hab ich im EventSystem-Tutorial per Static gelöst (siehe Sub "eventSub" und Function "windowCreate").

Das könnte dir vielleicht weiterhelfen.

[Cherry]

Probier mal: ThreadCreate(This.DoEvents, @This)

Dann natürlich einen Do Until QuitMessage...Loop rein und in den Destructor ein ThreadWait.

[OneCypher]

@Cherry: Sorry, habs gerade auch noch gesehen XD .. war da irgendwie verrutscht, sorry!!!! (habs auch korrigiert)
Die Ehre, gebührt natürlich dir

@MOD: Es ist eigentlich kein Problem eine Funktion eines UDT als Thread zu starte. Das geht natürlich nicht direkt sondern nur indirekt über eine static-funktion. z.B:

[Sebastian]

[Cherry]

Nein, darum auch das [quote] rundherum: OneCypher hat geschrieben "@Sebastian: DAS IST ABSOLUT KRASS, etc. etc."

[OneCypher]

@Cherry: Ich hab deine Änderungen jetzt mal ins Projekt übernommen. Hab mal alles kurz angetestet
Unter welche Lizenz stellt man diesen Quelltext am besten?

[nemored]

Kommt drauf an, was du willst. Wenn du es möglichst frei handhaben willst, wäre wahrscheinlich LGPL ganz gut. MIT kenne ich nicht so gut, könnte auch in Frage kommen
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.

[Westbeam]

Oder WTFPL, die ist ganz gut, wenn es WIRKLICH frei sein soll.

[Jojo]

Vielleicht hilft dir diese Zusammenstellung ja: http://www.osscc.net/en/licenses.html#compatibility
BSD ist toll.

[Westbeam]

Sag ich ja. WIRKLICH frei halt.

[Cherry]

[OneCypher]

@Cherry: Ich denke, das er im Constructor automatisch einen Screen erzeugt, hast du schon 100% korrekt implementiert!
Denn ein GFX-Screen MUSS erzeugt "sein" bzw "werden", damit man überhaupt FB-Images mit ImageCreate korrekt anlegen und benutzen kann.
Bei meinen Versuchen stürzt jedes Programm ab sobald man Grafikbefehle auf einen Image-Buffer anwenden will bei dem KEIN GFX-Screen vorher erzeugt wurde.
Ich bin dann auch der Meinung, man sollte einen initialisierten Screen nicht mehr nachträglich deaktivieren..

Was genau macht:

[28398]

Es ersetzt den Nachrichtenhandler.

btw. gehört zu gutem Code gehört an dieser Stelle auch, dass man den alten Handler beim Schließen des Fensters wieder einsetzt und darüber in Kenntniss setzt.

[OneCypher]

@28398: Ich weiss leider jetzt nicht genau, was du damit meinst. Du darfst das aber gerne mal in das Projekt einbauen, damit ich mir das mal anschauen kann

[Cherry]

@OneCypher: ich meinte, dass fbWindow nicht sofort einen fbWindow-Screen erzeugen sollte.
@28938: Stimmt, nur wird die alte Prozedur hier nie mehr benötigt, weil das Platzhaltercontrol quasi für immer durch den fbWindow-Screen ersetzt werden soll. Aber du hast Recht, ich sollte vllt noch eine Detach-Funktion schreiben, und dann muss ich das natürlich speichern.

[28398]

@Cherry: Siehe Signatur.
Es ist immer gut möglich, dass ein Control beim Erstellen Speicher alloziert. Damit dieser korrekt freigegeben werden kann, muss der alte Handler bei WM_DESTROY wieder eingesetzt werden und ebenfalls eine WM_DESTROY-Nachricht bekommen. Es muss ja nicht unbedingt Speicher sein, Handles gibts ja auch noch.

@OneCypher:
Das ist nicht mehr das ganz einfache Win32-rumgeplänkel^^

[Cherry]

[OneCypher]

@cherry: Hm, also, ich hatte das schon so konzipiert, dass sich direkt ein fenster öffnen soll.
Denn das hat mehrer gründe:
einerseits wollte ich es für jeden "normalen" freebasic-programmierer ermöglichen mehrere GFX-Ausgabefenster zur verfügung zu stellen
und andererseits glaube ich das diese "attach" funktion eine plattformübergreifende programmierung nicht leichter macht!
auch wenn diese attach-funktion ziemlich faszinierend ist

ich hatte überlegt, die reopen-funktion in screenres() umzubennenen und eine neue namens screen() anzulegen.
so das eine solche screen-erstellung so nahe wie möglich an die GFX-lib-syntax angelehnt ist.

im nächsten schritt such ich mir die richtiigen api-funktionen für ein linux-X11-pendant zusammen und fange eine plattformübergreifende fbwindow-lib zu schreiben

Das soll dich natürlich an nichts hindern .. also ich würde es sehr begrüßen, wenn du noch ideen hättest die du hier implementieren könntest

PS: ich hab den quelltext für die fbwindow.bi aus seite 1 aktualisiert, da waren noch ein paar sachen drin, die nich so ganz funktioniert hatten..
über die funktion .Resized() kann man auslesen ob die größe eines screens durch den benutzer geändert wurde.
ein beispiel liefere ich noch dazu!
und bei mir hatte dein code immer ein fenster erzeugt dessen größe man nicht ändern kann. Die stelle hab ich ein bischen umformuliert.
konkret: