Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

2 oder Mehrer Grafikfenster
Gehe zu Seite Zurück  1, 2, 3  Weiter
 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC.
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
OneCypher



Anmeldungsdatum: 23.09.2007
Beiträge: 802

BeitragVerfasst am: 31.08.2009, 22:16    Titel: Antworten mit Zitat

Leider funktionieren inkey und getmouse auch nicht wenn man sie in die DLL reinpackt.. traurig .. ich weiss nicht genau was da fehlt, damit auch das funktioniert..

wie gesagt, universell kann man das 2. fenster über einen puffer bemalen den man im hauptprogramm befüllt... dann braucht man die line, pset circle ... anweisungen nicht einzeln in die DLL zu programmieren!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
The_Muh
aka Mark Aroni


Anmeldungsdatum: 11.09.2006
Beiträge: 718

BeitragVerfasst am: 31.08.2009, 22:44    Titel: Antworten mit Zitat

Funktioniert im übrigen auch andersrum:
man kann aus der DLL heraus das hauptfenster bemalen (bissel rumgepointer, gfx-modus ohne (oder auch mit) gfx-fenster)

inkey und getmouse.. ich werds mir mal angucken, vll find ich ja ne lösung...
_________________
// nicht mehr aktiv //
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
OneCypher



Anmeldungsdatum: 23.09.2007
Beiträge: 802

BeitragVerfasst am: 01.09.2009, 08:42    Titel: Antworten mit Zitat

Wie kann man aus der DLL herraus das hauptfenster bemalen? Direkt oder auch wieder über nen buffer?

Am elegantestens wäre es natürlich wenn man den Pointer vom jeweiligen Screen direkt als ImageBuffer benutzen könnte. Aber ich glaub, dafür fehlen entsprechende Header infos an der Stelle wo der Screen-Pointer hinzeigt...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
MOD
Fleißiger Referenzredakteur


Anmeldungsdatum: 10.09.2007
Beiträge: 1003

BeitragVerfasst am: 10.09.2009, 15:32    Titel: Antworten mit Zitat

Ich hab jetzt ein wenig rumprobiert und rumgepointert, aber mehr als ein -1 hab ich bei GetMouse im zweiten Fenster nie erreicht.

Ich hab mir mal den Code in der rtlib angesehen.
Für GetMouse wird der Handle zum Fenster verwendet. Ich nehme einfach mal an, dass FB nur einen Handle verwalten kann.

Das man mit anderen Befehlen das zweite Fenster bemalen kann, liegt wohl daran, dass man einen Puffer beschreiben kann, dessen Pointer man einfach übergibt und das dann direkt ins selbsterzeugte Fenster gemalt wird ohne irgendeinen Handle anzusprechen.

Erkennbar ist auch, dass solange das zweite Fenster über dem Hauptfenster ist, im Hauptfenster GetMouse ein Ergebnis liefert, obwohl ja das zweite Fenster im Vordergrund ist. Die Werte die es liefert entsprechen aber dem zweiten Fenster. Das heißt, solange die Maus über dem Fenster mit dem ersten Handle ist, liest er die korrekten Werte ab, egal von welchem Fenster.

Ich vermute also fast, dass das nicht gehen wird.


Inkey hingegen funktioniert etwas anders.
Ein einfaches Inkey im Hauptprogramm sorgt dafür, dass man, egal in welches Fenster eingetippt, immer das Zeichen bekommt. Es muss halt über das Hauptprogramm verwaltet werden und dann ins zweite Fenster mit Draw String reingezeichnet werden.
Dann geht es auch, egal ob das zweite Fenster über dem ersten ist.

Wenn das Inkey aber in der DLL zum zweiten Fenster steht, kann es auch keine Werte auslesen. Als String Ptr zB zeigt es die richtige Adresse, aber es wird nie ein Wert hinterlegt.

Also wird das wohl auch nicht gehen, bis FB mit mehreren Fensterhandles arbeiten kann und dann sind solche Tricks nicht mehr nötig, weil FB von sich aus mehrere Fenster öffnen kann.

Bleibt nur zu hoffen, dass das irgendwann jemand implementiert.

lächeln
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
OneCypher



Anmeldungsdatum: 23.09.2007
Beiträge: 802

BeitragVerfasst am: 11.09.2009, 09:09    Titel: Antworten mit Zitat

@MOD: Klasse das du dir echt die arbeit gemacht hast! RESPEKT! ... Zwar schade das es nicht anders geht, aber immerhin taugt ein in einer DLL-erzeugtes GFX-Fenster zur Darstellung von Inhalten.. das ist ja schon mal was lächeln

Bleibt zu hoffen das die wenigen Herrn die noch an der FBGFX aktiv mitarbeiten die zeichen der Zeit erkennen und da was dran machen grinsen .. es wäre echt super praktisch!


Naja.. und die andere Möglichkeit bleibt ja evtl. bestehen: Mit sicherheit kann man per Betriebssystem-spezifischen API-Befehlen die fehlenden Maus/Tastatur eingaben an der FBGFX vorbei einlesen.. nur wie ... k.A.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
MOD
Fleißiger Referenzredakteur


Anmeldungsdatum: 10.09.2007
Beiträge: 1003

BeitragVerfasst am: 11.09.2009, 13:05    Titel: Antworten mit Zitat

Die wenigen Herren ist gut.

Der einzige aktive Entwickler ist counting_pine und der macht eigentlich nur Bugfixes.
lillo hat die fbgfx entwickelt und fast niemand versteht, wie die arbeitet durchgeknallt

Ja, mit API sollte es gehen.
Man müsste dem zweiten Fenster einen Namen mitgeben (mit WindowTitle), nach dem man per API sucht und so dann die Position auf dem Desktop ermitteln.
Als nächstes müsste man den Rahmen rausrechnen um die genaue Position vom Fenster selbst zu kriegen und dann die Maus per API ablesen und mit der Position des Fensters vergleichen.
Wenn das zweite Fenster im Vordergrund ist und die Maus auf die errechnete Position klickt, ließe sich das schon machen..denk ich.

Müsste man ausprobieren, dazu hab ich aber keine Lust mehr Zunge rausstrecken
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
28398



Anmeldungsdatum: 25.04.2008
Beiträge: 1917

BeitragVerfasst am: 11.09.2009, 14:35    Titel: Antworten mit Zitat

Ähh, MOD, hast du dir den Sourcecode der GFXlib mal genau angesehen?
Da wird auch nur mit Wasser gekocht. Eigentlich ist sie sogar intern schon MW tauglich, aber das wird über die API nicht nach außen getragen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
MOD
Fleißiger Referenzredakteur


Anmeldungsdatum: 10.09.2007
Beiträge: 1003

BeitragVerfasst am: 11.09.2009, 14:50    Titel: Antworten mit Zitat

Ich hab nur den Handle gesehen und bin davon ausgegangen, dass es auch intern nur den einen gibt, was ja auch stimmt.

Wenn da intern doch die Funktionen dazu da sind, hilft das aber keinem weiter, also ist deine Aussage auch nicht gerade hilfreich.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
28398



Anmeldungsdatum: 25.04.2008
Beiträge: 1917

BeitragVerfasst am: 11.09.2009, 16:40    Titel: Antworten mit Zitat

Ich bezog das eher auf das:
Zitat:
fast niemand versteht, wie die arbeitet
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
MOD
Fleißiger Referenzredakteur


Anmeldungsdatum: 10.09.2007
Beiträge: 1003

BeitragVerfasst am: 11.09.2009, 17:04    Titel: Antworten mit Zitat

Dann hab ich das falsch verstanden, aber hilfreich ist es weiterhin nicht grinsen

Zitat:
Da wird auch nur mit Wasser gekocht.


Soweit ich das im englischen Forum verfolgen konnte, ist es aber wirklich so, dass viele den Code nicht verstehen oder besser gesagt die Struktur dahinter.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ThePuppetMaster



Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]

BeitragVerfasst am: 11.09.2009, 18:09    Titel: Antworten mit Zitat

Hab mir das jetzt auch mal angesehen. Eigentlich is das garnicht so undurchsichtig, wie die leute alle behaupten.
Es hat das gut und sauber gekapselt.

Für Windows ist das deutlich leichter zu realisieren, als für Linux. Unter windows wird das "zeug" mit der Muas übrigens mit "GetCursorPos" realisiert. diese Koordianten werden dann von der Fesnterposition rückgerechnet und verwendet.

libfb_gfx_win32.c
Code:
/*:::::*/
static VOID CALLBACK fb_hTrackMouseTimerProc(HWND hWnd, UINT uMsg, UINT idEvent, DWORD dwTime)
{
   POINT pt, rect_pt[2];
   RECT *rect = (RECT *)rect_pt;

   GetClientRect(fb_win32.wnd, rect);
   MapWindowPoints(fb_win32.wnd, NULL, rect_pt, 2);
   GetCursorPos(&pt);
   if ((!PtInRect(rect, pt)) || (WindowFromPoint(pt) != fb_win32.wnd)) {
      KillTimer(fb_win32.wnd, idEvent);
      PostMessage(fb_win32.wnd, WM_MOUSELEAVE, 0, 0);
   }
}


Es reicht also aus, wenn du das ähnlich umsetzt. Via API n Fenster erzeugen. Anschliessend kannst du einfach per eigenem callback die Maus daten abfragen (über n thread) und wenn sich was tut die entsprehenden Functionen der Bibliotek aufrufen. Dann setzt sich das passend rein. Oder du machst es auf ne andere art .. je nachdem, wie du das realisieren möchtest.


Mfg
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ]
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
OneCypher



Anmeldungsdatum: 23.09.2007
Beiträge: 802

BeitragVerfasst am: 13.09.2009, 22:49    Titel: Antworten mit Zitat

auf "GetCursorPos" bin ich auch schon gestoßen, aber ich dachte das wäre zum ermitteln der Grafik-Cursor koordinaten :-/ ... so kann man sich irren happy

Cool, aus dem C-Code werd ich <fast> schlau XD
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
MOD
Fleißiger Referenzredakteur


Anmeldungsdatum: 10.09.2007
Beiträge: 1003

BeitragVerfasst am: 18.09.2009, 01:01    Titel: Antworten mit Zitat

Kurzer Bericht:

Ich bin dabei, eine kleine gfxlib zu erstellen, die multiscreeningfähig und threadsafe sein wird.
Ich werde mich dabei stark an der fbgfx orientieren, sodass man später gut damit zurecht kommen sollte.


Umgesetzt habe ich schon GetMouse und Inkey, da dass ja das eigentliche Problem in dem Thread war lächeln

Damit ein erstes Release nicht allzu lang auf sich warten lässt, habe ich eine Prioritätenliste von Befehlen erstellt, die ich die nächste Zeit einbinden werde.
Ausgeschlossen habe ich schon GetJoystick und Screen (ScreenRes reicht).


Das ganze mache ich jetzt für Win_Only, falls das was wird und ein Linuxexperte mir helfen mag, würde ich das gern darauf ausweiten (DOS ausgeschlossen).


Falls jemand einen besonderen Befehl möchte, kann ich ihn noch auf die Prioritätenliste setzen, ansonsten werde ich mich dazu erst melden, wenn/falls ein erstes Release ansteht.

(Von mir Ausgeschlossenes kann sich später jeder selbst einfügen.)
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
28398



Anmeldungsdatum: 25.04.2008
Beiträge: 1917

BeitragVerfasst am: 18.09.2009, 20:45    Titel: Antworten mit Zitat

Es wäre - meiner Meinung nach - eher sinnvoll einen Ersatz für die gfxlib zu schreiben, der API Kompatibel ist. (Man kann daher einfach die neue .a ins lib-Verzeichnis verschieben, und schon wird die neue gfxlib benutzt)
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
MOD
Fleißiger Referenzredakteur


Anmeldungsdatum: 10.09.2007
Beiträge: 1003

BeitragVerfasst am: 18.09.2009, 21:18    Titel: Antworten mit Zitat

Da hast du Recht, aber wer soll das machen?

Ich versuche mit meinem Versuch jetzt möglichst viel abzudecken, sodass die meisten Sachen verfügbar sein sollten.

Solange keiner eine fbgfx3 schreibt, wird meine Lösung hoffentlich erstmal für die meisten Anwendungen reichen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Sebastian
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 5969
Wohnort: Deutschland

BeitragVerfasst am: 18.09.2009, 21:45    Titel: Antworten mit Zitat

Hallo,

ich habe die Diskussion nicht genau mitverfolgt, aber warum erweiterst du die bestehende fbgfxlib nicht um die Mehrfensterfunktionalität, statt eine neue Bibliothek zu schreiben? Die aktualisierte Fassung der Standard-fbgfxlib könntest du ins SVN-System hochladen und somit direkt zur Weiterentwicklung von FreeBASIC beitragen, d.h. du müsstest keine separate Lib unterhalten, sondern könntest direkt am FB-Paket mitarbeiten und in FB 0.21.0 (oder welches auch immer die nächste Version wäre) wäre deine neue Version dann enthalten. lächeln
C ist FreeBASIC gar nicht unähnlich, d.h. nach einer gewissen "Eingewöhnung" kämst du damit sicher auch problemlos zurecht.

Viele Grüße!
Sebastian
_________________

Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
MOD
Fleißiger Referenzredakteur


Anmeldungsdatum: 10.09.2007
Beiträge: 1003

BeitragVerfasst am: 18.09.2009, 22:19    Titel: Antworten mit Zitat

Mag alles stimmen und von C lesen, was ich kann, bis C schreiben ist es auch gar nicht weit. Das Problem ist eher, dass mir die lib ziemlich konfus aufgebaut vorkommt. Ich schaue für meine gfxlib schon die ganze Zeit in die fbgfx, aber wundere mich immer wieder, wohin Funktionsaufrufe führen. Das geht teilweise querbeetein von rtlib nach fbgfxlib und zurück.

Wenn ich da Hand anlegen würde, wäre das gar nicht mehr zu gebrauchen.
So baue ich meine eigene Struktur und weiß ganz genau, was ich mache.

Es ist ja noch nicht mal sicher, dass aus meiner lib was brauchbares wird und falls doch, wird sie von den Funktionen der fbgfx ähnlich sein, sodass ich danach immer noch Strukturen auf die fbgfx übertragen könnte.

Ein weiteres Problem wäre, dass die Win-Version zwar mehrere Fenster erzeugen und handlen könnte, die Linux-Version aber davon nichts hat (wäre also plattformgebunden, was bei FB ja gar nicht sein soll).

Ich würde also erst abwarten, wie sich das entwickelt und bei genügend Interesse am fertigen Produkt (was sich durch Verwenden der lib durch viele Programmierer), könnte man das in die fbgfx einpflegen.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Dusky_Joe



Anmeldungsdatum: 07.01.2005
Beiträge: 1007
Wohnort: Regensburg/Oberpfalz

BeitragVerfasst am: 19.09.2009, 22:26    Titel: Antworten mit Zitat

In der Problembeschreibung sprichst du zwar von EINER Programm.exe; aber wäre ein Walkaround für dich vlt, mit zwei Executables zu arbeiten? Die könnten miteinander über eine (oder mehrere) TMP-File(s) kommunizieren. Die würden Variablen übergeben und als Mutexes funktionieren.

Wenn es dir aber nur um die Bequemen Drawing Primitives geht - sieh dir mal das Beispiel unter examples/WinAPI durch, in dem ein Bildschirmausschnitt von GET auf ein Windows-Fenster übertragen wird. Du kannst einen virtuellen Bildschirmpuffer erstellen (Siehe SCREEN in der Ref, letzter Parameter NO_OUTPUT oder so), von diesem dann mit GET lesen, und das ganze dann auf dem API-Fenster ausgeben. Und solche API-Fenster kannst du (vergleichsweise) bequem beliebig viele erstellen.
Jedenfalls ist das noch IMO bequemer, als mit einer DLL oder 2 EXEs zu arbeiten...


Have a nice day
Ciao
Dusky_Joe
_________________
fully biological degradable

Once, the big wave arrives, you've got two ways, you can go:
Either, you ride it, or you don't do.
But, if you don't ride, you'll never know wether you'd have gone wet.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
funkeld
gesperrt


Anmeldungsdatum: 10.10.2009
Beiträge: 179

BeitragVerfasst am: 12.10.2009, 16:36    Titel: Antworten mit Zitat

Ich möchte diesen Code von Irrlicht in einem Extra-Screen von einer Dll laufen lassen, so wie es weiter oben hier getestet wurde.
So wie er hier steht funktioniert es nicht.
Was muss man beachten?
Wer kann mal konstruktiv helfen.

Danke.

Gruss

Code:

'' ----------------------------------------------------------------------------
'' Irrlicht Wrapper for Imperative Languages - Freebasic Examples
'' Frank Dodd (2006)
'' ----------------------------------------------------------------------------
'' Example 48 : Collision in a Loaded IrrEdit Scene
'' This example demonstrates collision in a scene that was created in IrrEdit
'' the nodes in the scene are found and then collision selection objects are
'' created for them in the same way as you would with a custom created scene
'' ----------------------------------------------------------------------------

'' ////////////////////////////////////////////////////////////////////////////
'' Includes for extension libraries
#include "IrrlichtWrapper.bi"

'' ////////////////////////////////////////////////////////////////////////////
'' global variables

' irrlicht objects
DIM Camera as irr_camera
DIM CameraNode as irr_node
DIM NodeGround as irr_node
DIM NodeBox as irr_node
DIM SelectorGround as irr_selector
DIM SelectorBox as irr_selector
DIM CombinedCollision as irr_selector
DIM CollisionAnimator as irr_animator


'' ////////////////////////////////////////////////////////////////////////////
'' GDB debugger main() function

' -----------------------------------------------------------------------------
' start the irrlicht interface
IrrStart( IRR_EDT_OPENGL, 640,480, 32, IRR_WINDOWED, IRR_SHADOWS, IRR_IGNORE_EVENTS )

' send the window caption
IrrSetWindowCaption( "Example 48: Collision in a Loaded Scene" )

' load an example scene created in irrEdit
IrrLoadScene( "media\CollisionScene.irr" )

' we add a first person perspective camera to the scene so you can look about
' and move it into the center of the map
Camera = IrrAddFPSCamera
CameraNode = Camera
IrrSetNodePosition( CameraNode, 200, 100, 0 )
IrrSetNodeRotation( CameraNode, 0, -90, 0 )

' first we need to get references to the objects in the scene that the viewer
' can collide with
NodeGround = IrrGetSceneNodeFromName( "Ground" )
NodeBox = IrrGetSceneNodeFromName( "Pillar" )

' next we need to create collision objects from the nodes
SelectorGround = IrrGetCollisionGroupFromBox( NodeGround )
SelectorBox = IrrGetCollisionGroupFromBox( NodeBox )

' now that we have collision objects for each of the nodes we need to combine
' them into a collision group
CombinedCollision = IrrCreateCombinedCollisionGroup ()

' creates a meta-selector that is a group of selector objects
IrrAddCollisionGroupToCombination ( CombinedCollision, SelectorGround )
IrrAddCollisionGroupToCombination ( CombinedCollision, SelectorBox )

' finally we add a collision animator to the camera, this constrains the camera
' so that its movement is restricted by collision with the collision groups we
' just created. the parameters we supply are as follows: -
'       The collision objects, the node to be effected by collision,
'       x, y and z radius of the collision area,
'       x, y and z force of gravity to apply to the node affected by collision,
'       x, y and z offset of the node
CollisionAnimator = IrrAddCollisionAnimator(_
        CombinedCollision, CameraNode,_
        30.0,30.0,30.0,_
        0.0,-3.0,0.0,_
        0.0,50.0,0.0 )

' we also hide the mouse pointer to see the view better
IrrHideMouse

' -----------------------------------------------------------------------------
' while the irrlicht environment is still running
WHILE IrrRunning
    ' begin the scene, erasing the canvas with sky-blue before rendering
    IrrBeginScene( 200, 200, 255 )

    ' draw the scene
    IrrDrawScene

    ' end drawing the scene and render it
    IrrEndScene
WEND

' -----------------------------------------------------------------------------
' Stop the irrlicht engine and release resources
IrrStop
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
28398



Anmeldungsdatum: 25.04.2008
Beiträge: 1917

BeitragVerfasst am: 12.10.2009, 16:53    Titel: Antworten mit Zitat

Irrlicht != fbGfx

@Topic:
Nunja schau dir mal den Src der fbGfx an. Die Funktionen der fbGfx werden alle fb_ genannt. Du kannst jetzt in FB die Funktionen deiner Lib genauso nennen und mit exakt (!) den gleichen Parametertypen ausstatten. Wenn du deine Lib jetzt statisch kompilierst und libfbgfx.a (?) nennst, wird der Compiler deine Lib anstatt der fbGfx einbinden.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC. Alle Zeiten sind GMT + 1 Stunde
Gehe zu Seite Zurück  1, 2, 3  Weiter
Seite 2 von 3

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz