ich meinte die kleinen weissen Quadrate, wo man dran verschieben kann.
OFrame.dll: Verschieb- und skalierbare Controls
-
-
-
Ach so. Momentan ist es so, dass die Greifer immer angezeigt werden, es sei denn, die Größe kann nicht geändert werden (minimal=maximal). Ich werde mal testen, wie es anders aussieht und ggf. ein Flag einführen, mit dem beide Modi wählbar sind.
-
Hm, dafür müsste ich das Parentfenster subclassen, weil die WndProc der Controls keine Daten mehr liefert, wenn die Maus das Control verlässt. Das würde den Umgang wieder unnötig komplizieren.
-
und "ON LEAVE" einfach Maximal=Minimal=aktuell setzen? Oops, ich denke wohl zu sehr in javascript...
-
Falls du WM_MOUSELEAVE meinst, das arbeitet meines Wissens nach nur innerhalb der Funktion TrackMouseEvent() oder wird nur ans Parent-Fenster gesendet. Es ist so, sobald der Zeiger das (Child-)Control verlässt, versiegen alle Nachrichten. Somit bleibt nur, das Hauptfenster zu subclassen, was ich eigentlich komplett verhindern wollte.
-
Dann wärs fast besser, die Greifer erst garnicht darzustellen (solange man sie trotzdem angreifen kann - falls Windows das überhaupt zulässt)...
-
Mir fällt bestimmt noch was ein, nur hab ich wenig Zeit und Ruhe im Moment.
Ich finde übrigens, die Greifer sehen gar nicht mal so schlecht aus... -
P.S.: Mit TrackMouseEvent() lag ich schon gar nicht mal so daneben. Es geht...
-
Zitat
...(solange man sie trotzdem angreifen kann - falls Windows das überhaupt zulässt)
Keine Sorge, ist alles selbstgemacht. Fast schon (x)profan. :cool:
Hab die Zip mal neu hochgeladen: http://frabbing.bplaced.net/OFrame.zip -
Ups, noch einen Bug gefunden. Jetzt aber.
-
Angeblich gibts auch eine Funktion WM_MOUSEHOVER, also HOVER, nicht OVER. Toll, langsam nimmt das Ding Gestalt an - fast schon brauchbar...:prof: Kann man den Hintergrund auch voll-transparent machen und das Ausgrauen beim Überlagern vermeiden? Dann wären wir nämlich schon fast bei verschiebbaren Zeichnungselementen, die eine entfernte Ähnlichkeit mit WinWord-Zeichenelementen hätten... Was mir letztlich vorschwebt, sieht man in Geometrieprogrammen wie z.B. Geogebra...
Gruss -
Zitat
Angeblich gibts auch eine Funktion WM_MOUSEHOVER, also HOVER, nicht OVER.
Ja, auch die kann man mit TrackMouseEvent() anfordern.
ZitatToll, langsam nimmt das Ding Gestalt an - fast schon brauchbar...:prof: Kann man den Hintergrund auch voll-transparent machen und das Ausgrauen beim Überlagern vermeiden?
Ich hab das versucht, aber leider immer überlagerte Bilder erhalten. In der Grafik im Control-HDC erscheint auch das, was sich gerade darüber befindet, also das OFrame-Control. Deswegen meine halbwegs transparente Lösung.
ZitatDann wären wir nämlich schon fast bei verschiebbaren Zeichnungselementen, die eine entfernte Ähnlichkeit mit WinWord-Zeichenelementen hätten... Was mir letztlich vorschwebt, sieht man in Geometrieprogrammen wie z.B. Geogebra...
GrussKannst du einen Screenshot zeigen?
-
-
Hm, Ähnlichkeiten sehe ich aber nicht wirklich...
-
-
Werd mal sehen was ich machen kann.
-
Also das so hinzubekommen gelingt mir nicht:
PrintWindow() arbeitet anscheinend nicht richtig mit XP oder Child-Windows. Laut Andreas Miethe gibt es unter Vista keine Probleme.
WM_PRINT und WM_PRINTCLIENT funktionieren auch nicht wie gewünscht. Layered-Windows scheiden von vornherein aus, das lässt sich nicht auf Child-Windows anwenden.Das Problem ist, dass Windows keine Kopie des Fensterinhalts bereit hält, sondern durch Messages ein Programm dazu veranlasst, den Inhalt neu zu zeichnen. Darum erhalte ich als Grafik von einem Control nicht den originalen Inhalt, sondern nur die aktuelle Draufsicht. Verdecken andere Fensterteile das Control, so sind sie quasi eingebettet in die Grafik, die der DC mir zurück gibt. Mit solchen Grafiken kann ich den Hintergrund für transparente Controls nicht rekonstuieren, ohne Geisterbilder zu erzeugen.
Deine Geogebra-Objekte sind wohl vom Programm erzeugte, sprite-ähnliche Dinger, die quasi auf das Fenster geblittet werden. Das scheidet für mich aus, weil oframe eigenständige Controls sein sollen und sind. Die Dll soll mit allen möglichen Programmen zusammen arbeiten und nicht nur auf ein Programm zugeschnitten.
-
ich dachte mir schon sowas... Danke für deine Bemühungen, und sorry daß ich dich da in was reingejagd habe das du ursprünglich ohnehin nicht wolltest.
Gruss -
Ich lerne gerne dazu und einige neue Sachen waren auch dabei.
Ich könnte noch mit Regionen arbeiten, dazu müsste ich quasi eine Image-nach-Region-Routine schreiben. Wahrscheinlich wäre die ganze Rechnerei aber doch etwas langsam.
-
So, bin doch noch etwas weiter gekommen.
Mit der Transparenz bin ich nun ganz zufrieden. Bei Überlagerungen von transparenten Controls untereinander kann es mitunter noch zu sehr leichten Geisterbildern kommen, aber das fällt kaum auf, es sei denn, man achtet grad darauf und legt es darauf an.
WM_PRINT und WM_PRINTCLIENT funktionieren übrigens doch wie gewünscht. Man muß die jeweile Message aber im Superclassing abfangen und dort ein WM_PAINT schicken! Tja, darauf muß man erst man darauf kommen...
Benutzen konnte ich die Messages jedoch letzten Endes nicht, weil ich sie für OFrame im Painting von WM_PAINT benötigt hätte. OFrame arbeitet darum jetzt mit einer Kopie der Grafik im DC, die von jedem Control im WM_PAINT gemacht wird. Einfach und effektiv. Und unter einem Control werden sogar alle (OFrame-)Controls sichtbar. Dahinter lässt sich nichts mehr verstecken.
Gleichzeitig damit ist jetzt auch das leichte Flackern bei den Texten und Icons weg. Double-Buffered eben. :doing:Lange Rede - kurzer Sinn. Testet es einfach aus.
http://frabbing.bplaced.net/OFrame.zip -
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!