Zoomen des Inhaltes einer Scrollbox

[oki]

Hi Leute,

ich glaub ich bin am Ende meines Lateins. Folgende Aufgabenstellung:

Ich erstelle in einer Anwendung in einer Scrollbox ein Schema mittels eigener Komponenten (Nachfahren von TCustomControl) zur Laufzeit. In einer Scrollbox natürlich deshalb, weil das Schema größer werden kann als der Bildschirmbereich. Jetzt kann man zwar alles super platzieren, weil es durch die Scrollbox keine festen Begrenzungen gibt, aber die Sache wird bei großen Schematas natürlich etwas unübersichtlich. Praktisch ist dann ja eine Zoomfunktion. Immer wohl gemerkt, dass es nicht um ein Image oder Zeichnen auf den Canvas, sondern um Komponenten auf einer Scrollbox geht.

Nun dachte ich, dass kann man mit SetViewportExtEx lösen. Da tut sich aber gar nichts. Hier mal mein Code:

Delphi-Quellcode:

procedure TSeysolMain_Form.ToolButton4Click(Sender: TObject);
var OSize : TSize;
    ActiveSB : TRTGroupScrollBox;
    Res : Boolean;
    SBDC : HDC;
begin
  OSize.cx := 0;
  OSize.cy := 0;
  ActiveSB := GetScrollBox(self, PageControl1.ActivePage);  // meine aktive Scrollbox holen (eigene Funktion) 
  if Assigned(ActiveSB) then begin
    SBDC := GetDC(ActiveSB.Handle);
    // GetViewportExtEx(SBDC, OSize);
    SetMapMode(SBDC, MM_ISOTROPIC);
    SetWindowExtEx(SBDC, 4, 4, nil); // mal zum testen fest eingestellt
    SetViewportExtEx(SBDC, 100, 100, nil);
    Res := GetWindowExtEx(SBDC, OSize);
    if not Res then // mal schauen, was draus geworden ist
      MessageDlg(Format('Error Size: %d, %d', [OSize.cx, OSize.cy]), mtInformation, [mbOK], 0)
    else
      MessageDlg(Format('Size: %d, %d', [OSize.cx, OSize.cy]), mtInformation, [mbOK], 0);
  end;
end;

Ich hab zwischenzeitlich geprüft, ob die Funktionen ohne Fehler ausgeführt werden. Ist so, liefern True zurück (hab nur etwas aufgeräumt).

Ja, entweder ich bin total auf dem Holzweg und das geht alles überhaupt nicht mit SetViewportExtEx und Konsorten, oder ich mache nur etwas mit der Verwendung der Funktionen falsch. Ich geb aber auch zu, dass ich durch die Thematik SetViewportExtEx, SetWindowExtEx und SetScaleportExtEx noch nicht durchgestiegen bin. Was benutzt man was wofür?

Im Anhang mal ein Screenshot damit man sieht was ich zoomen will. Es jeht um den jeweils sichtbaren Bereich einer ausgewählten Scrollbox.

Tja, entweder ich hab ein Grundsatz- oder ein Teilpproblem. Sicher bin ich mir auf jeden Fall, dass ich ein Problem habe, denn es tut sich nichts.



Schon mal Dank für die Hilfe,

Guß oki

[oki]

Ähm Push :oops:

[tomsson74]

[Edit]Sorry, glaube habe das Thema verfehlt :D[/edit]

[oki]

Hallo tomsson74.

Erst mal Dank dür diene Antwort. Mein primäres Ziel ist es nicht alle Elemente meiner Scrollbox mit einem Scaling an anderer Stelle auszugeben/zu zeichnen, sondern den Inhalt der Scrollbox selber zu zoomen. Im besten Fall bis alles enthaltene so klein ist, bis die Scrollbalken nicht mehr angezeigt werden. Sollte das nicht funzen, so würde ich mich auch mit einem Übersichtsfenster begnügen, dass den gesamten Inhalt der Scrollbox (auch nicht sichtbaren Bereich) in einem Image anzeigt. Ich würde dann im Image den sichtbaren Ausschnitt umrahmen.

Jestzt zu deinem Code. Erst mal Dank. Einige Sachen sind schon etwas klarer geworden. Ich hab aber noch nicht raus bekommen, was du in deiner ItemList für Komponenten speicherst. Du machst da einen Cast auf TGraphicElement. Was ist das?

Gruß oki

roter Kasten! nicht so schlimm, da ich mich damit noch gar nicht auskenne hilft im Moment fast alles.

[stahli]

Hi Oki,

schau mal, ob Dich das weiterbringt...

Wenn alle Stricke reißen, ich habe mal so eine Funktion geschrieben, die den kompletten Bereich einer Scrollbox in ein Bitmap schreibt. Der sichbare Bereich wurde "durchgeblättert" und die sichtbaren Ausschnitte zu einem Bild zusammengesetzt. Ich könnte das mal raussuchen (wenn ich es noch finde).


stahli

[oki]

Hallo stahli,

Dank für deinen Tipp. Das ist schon mal der richtige Weg. Ich benute dann zwar die Methode ScaleConrols, damit meine Scrollbox da bleibt wo sie ist, aber das ist Wurscht. Ich meld mich auch jetzt erst, weil ich da erst mal testen wollte.

Mein Problem ist aktuell nur, dass da einiges durcheinander geht. Das liegt sicher zum einen daran, das die Paint-Methoden meiner Controls prüfen, ob alles dargestellt werden kann. Wenn nicht, vergrößern sie automatisch das Control. Da geht ne Menge den Bach runter. Meine Verbinder besitzen zusätzlich eine Point-Liste ihrer Eckpunkte. Die wird durch die Methode leider nicht verändert. Wie sollte sie auch.

Im Grundsatz macht die Procedure aber das was ich wollte. Ich steh mir halt im Moment selber auf den Füßen rum mit meinen Controls. Aktuell weis ich noch nicht so genau, ob ich das hin bekomme, aber ich versuche es zumindest. Sollte es nicht klappen, so meld ich mich noch mal bezüglich deines Codeangebotes.

Dank dafür :cheer:

Im Anhang mal das Ergebnis des Zoomens, wie es jetzt aussieht. Grusel :mrgreen:

Dank und Gruß oki

[oki]

Das mit dem ScaleControls ist natürlich Unsinn. Scaleby ist schon richtig. Mit allen Standard-Controls sollte das auch ordentlich aussehen und nicht wie bei mir.

Wenn ich das wirklich hinbekommen will, dann muss ich da aber noch ordentlich Hausaufgaben machen bei meinen Controls.

Gruß oki

[stahli]

Hi,

erst mal Respekt für Dein Projekt, das sieht schon nicht schlecht aus :-)

Ich habe in meinem Projekt meine Turniersoftware etwas Ähnliches in Bezug auf größenänderbare Controls in einer Scrollbox umgesetzt.

Wenn Du nicht Standardcontrols verwendest (Edits etc) - oder diese nur auf eigene Controls drauf setzt - taugt das vielleicht auch als Ansatz.

Grundsätzlich habe ich eínen "Designer" von TScrollBox abgeleitet.
Der erhält ein virtuelles Raster und die Eigenschaften StyleMode und StyleSize.
Die Controls sind spezielle Komponenten, die der Designer kennt und die über eine XPos und YPos verfügen (die die Position im Raster bezeichnen).
Wird StyleSize vom Designer geändert, ändert der seine Rasterabstände und veranlasst die Controls, sich daran neu auszurichten und zu zeichnen. Je nach DesignMode und DesignSize können sich die Controls ggf. anders zeichnen bzw. ihre SubControls anders ausrichten.

Vorteil: Die Inhalte der Controls können an die jeweilige Größe angepasst werden. Bei kleiner Spieledarstellung lasse ich z.B. die Spielernamen weg oder kürze irgendwelche Informationen. Bei größerer Darstellung werden mehr Informationen dargestellt. Es wird also nichts gezoomt sondern die Größe der Controls "automatisch" an die Designereinstellungen angepasst.
Weiterhin kann die Darstellung und Funktion der Controls durch die Eigenschaft DesignMode beeinflußt werden. Z.B. werden im DesignMode "construct" Hilfslinien gezeichnet und Anfasser für Größenänderungen verwaltet.

Nachteil: Ziemliche Bastelei und ggf. jede Menge unterschiedliche Darstellungsvarianten. Spezielle Abstimmungen zwischen Designer und Controls erforderlich.


Stahli

[oki]

Hi stahli,
erst mal Dank für dein Lob. Ist auch ein ganz schöner Brocken geworden für nebenbei gemacht. ich habe genau das Problem:

Zitat:

Zitat von stahli

Nachteil: Ziemliche Bastelei und ggf. jede Menge unterschiedliche Darstellungsvarianten. Spezielle Abstimmungen zwischen Designer und Controls erforderlich.

Ich habe meine Controls auf GDI+ umgestellt und zeichne fast alles selber. Das natürlich OOP. Sonst hat man ja eh keine Chance. Leider ist es aber so, dass ich meine Gates (in denen die Ein- und Ausgangswerte angezeigt werden) in der Höhe auf Basis der Schriftgröße berechne. Da steckt das erste Problem. Ich ermittel also beim Zeichnen, wie groß ein Gate ist, dann wie viele Gates ich habe und daraus die minimale Höhe des Controls (plus Titel wenn eingeblende etc.). Beim verkleinern werden jetzt die Control aber eben nicht proportional kleiner, sondern immer etwas größer als soll. Da steckt das erste Problem. Beim Vergrößern stört das nicht hab ich gemerkt. Ich brauch aber leider den umgekehrten Weg.
Das Problem bei meinen Connectoren (Verbinder mit Pfeil) ist mir klar, da muss ich die Koordinaten selber umrechnen. mal schauen, ob Scaleby virtual ist.

Dein Projekt schau ich mir nachher mal an. Im Anhang noch ein Beispiel beim Vergrößern. Da siehts gut aus.

Gruß oki

[stahli]

mal so in´s Blaue:
Und wenn Du bei der Verkleinerung auf die Höhenkorrektur einfach verzichtest?
Lesen kann man dann ja eh nichts mehr und dann wird ein kleiner Teil der Informationen eben noch abgeschnitten.
Zum Nachvollziehen der Struktur könnte das ja reichen (außer für mich - aber ich verstehe das auch nicht bei großer Darstellung :roll: )

Stahli

[oki]

Jo, das ist eigentlich eine gute Idee. Da das zeichnen durch meine vererbte Paint-Procedure des TCustomConrol vorgenommen wird müsste ich mir aber "im" Control merken, dass ich im "Scale!-Mode bin. Zumindest < 1. Somit muss ich raus bekommen, wie ich den Aufruf von Scaleby des Parents mitbekomme. Ob es da eine Botschaft gib?

Das Programm als solchen ist nicht schwer zu verstehen, wenn man weis worum es geht. Das was auf dem Screen zu sehen ist sind Regelkreise, die man zur Designzeit erstellen und für die Regelung diverser Sachen nutzen kann. Wir verwenden es aktuell für die Steuerung/Regelung einer recht komplexen Solaranlage. Du kannst auf dem Bildschirm eigentlich alle notwendigen Regelglieder platzieren (PID-Regler, PT-Glieder, Berechnungsgleider, Logikglieder usw.) und diese mit Verbindern zusammenschalten. Die Software steuert dann entsprechende Karten für analoge und digitale Stellglieder an (Punmpen, Mischer, Heizthermen etc.) Läuft eigentlich sehr gut. Das wird das neue Design mit extrem mehr Funktionalität in der Projekterstellung. Der Studiosi, der aktuell daran arbeitet hat mir gesagt, dass es schön währe, wenn man zoomen könnte. Halt wegen des Überblicks. Tja, und hatte ich mein Problem. Ich find das aber auch geil und nun hat mich der Ehrgeiz gepackt.

Mal sehen, was draus wird. Ich halt dich auf dem laufenden. So lange ich nicht wirklich weis, ob es so lappt lass ich die Frage auch offen. Vielleicht muss ich ja doch auf die "Übersichtskarte" zurückschwenken.

Gruß oki

[oki]

Hi Stahli,

ich hab mal nachgeschaut. Es wird zum scalen der enthaltenen Controls die protected procedure ChangeScale aufgerufen. Diese ist wiederum virtual. Somit besteht die Chance, diese zu vererben. In der vererbten Methode kann ich dann prüfen auf welchem Zoomlevel ich bin (muss ich mal schauen, ob man das abfragen kann, oder ob ich einen eigenen Member anlegen muss) und dementsprechend reagieren (z.B. Umrechnen meiner Verbinderkoordinaten). Das gleiche kann ich dann in meinen Paint-proceduen tun. Wie vorher, entweder Zoomlevel abfragen oder eigenen member bemühen.

Na, mal sehen was das wird.

Ich hab mir mal den Screenshot deiner Software angesehen. Das Rahmendesign deiner Feld-Elemente gefällt mir. Da würd ich bei mir auch gerne was in die Richtung anpassen. Kommt das aus deiner Feder? Ist der Rest (Holzdesign etc.) Skinning?

Kann ich auf jeden Fall Hochachtung zurück senden (ich hoffen es fängt jetzt nicht an aus dem Monitor zu tropfen :lol: ).

Gruß oki

[stahli]

Zitat:

procedure ChangeScale

Kannst Du nicht einfach im "Übersichtsmodus" die Größe Deiner Controls statt an der Zeichenhöhe an der ScrollBox-Größe orientieren?
Dann müsstest Du nichts über eine scalierung regeln sondern zeichnest Deine Controls einfach kleiner. Die Verbindungen müssten dann ja problemlos funktionieren - nur eben der Inhalt der Controls wäre nicht vollständig dargestellt (wie bei meinen Spielen - in den kleineren Darstellungen werden einfach keine Spieler angezeigt, da das ohnehin keiner lesen könnte).

Zitat:

Das Rahmendesign deiner Feld-Elemente gefällt mir. Da würd ich bei mir auch gerne was in die Richtung anpassen. Kommt das aus deiner Feder? Ist der Rest (Holzdesign etc.) Skinning?

Das ist einfach mit den AlphaSkins (TsPanel) gemacht. Kann ich 100%ig empfehlen :-)
Sowohl die Controls als auch den Support. Die Beta 6.0 ist übrigens nochmal deutlich schneller und stabiler :-)

Zitat:

Kann ich auf jeden Fall Hochachtung zurück senden (ich hoffen es fängt jetzt nicht an aus dem Monitor zu tropfen ).

Gerne mehr, ich habe einen Eimer unterm Schreibtisch stehen... ;-)


Stahli

[tomsson74]

Zitat:

Zitat von oki

Ich hab aber noch nicht raus bekommen, was du in deiner ItemList für Komponenten speicherst. Du machst da einen Cast auf TGraphicElement.

Hi,

TGraphicElement ist die Basisklasse für alle grafischen Elemente, die auf meinem "Blatt" gezeichnet werden.
Davon abgeleitet werden Klassen wie TCircle, TRectangle, TText usw..

Bei meiner Anwendung handelt es sich um eine Art Formulareditor.

/Thomas

[oki]

Hi tomsson74,

jo, dann ist das klar. Bei mir habe ich auch einen eigenen gemeinsamen Vorfahren für alle meine Controls.

Gruß oki

[Medium]

Mal eine generelle Sache, die aber fürchte ich für den konkreten Fall vermutlich etwas Spät kommt. Bei graphenähnlichen Abbildungen wie dieser hier (UML-Diagramme fallen z.B. auch in diese Kategorie) würde ich prinzipiell von Komponenten, bzw. konkreter TControls Abstand nehmen, und eine ganz eigene Layerverwaltung implementieren. So etwas ähnliches, wie es auch Vektorgrafikprogramme machen wie z.B. Corel Draw. Da hat ein Spline auch nichts mit einem WinControl gemein, ist aber dennoch klickbar, verschiebbar etc.
Der Vorteil dabei ist dann, dass man zwar alles selbst zeichnen und verwalten muss, dann aber auch die völlige Kontrolle über alles hat, und sich nicht mit teils schwergängigen WinAPI Wurschteleien herumärgern muss.

Wie gesagt, das riesige Projekt derart jetzt umzubauen wäre fürchte ich immenser Aufwand, aber evtl. als Anregung für künftige Projekte dieser Art.

Edith weist mich grad darauf hin, dass Stahli ja schon in die selbe Richtung ging. Demnächst doch wieder den ganzen Thread lesen, okay :stupid:

[oki]

Hi Medium,

ich geb dir bei deinen Ausführungen recht. In meinem konkreten Fall ist es aber so, dass die graphische Darstellung nur ein visuelles Hilfsmittel darstellt um den Regelkreis auch "lesen" zu können. Jedes einzelne Control erledigt eine spezifische Aufgabe. Ein PIDRegler ist hier auch ein echter PID-Regler. Er verarbeitet einen Eingangswert und liefert einen entsprechenden Output gemäß seinen Einstellungen für Proportionalfaktor, I- und D-Wert. Ein PT2-Control reagiert auch dementsprechend. Schaltet man über die Verbinder die Ausgangsgates auf Eingangsgates weiterer Controls, so kann man komplette Regelkreise etc. erstellen. Über Eingangskarten werden die Messwerte der Strecke eingelesen und mittels Ausgangskarten die durch die "Schaltung" gegebenen Werte an die Schaltglieder (Pumpen, Mischer, Heizthermen etc.) ausgegeben. Damit ist die eigentliche Aufgabe des Programms und der zur Designzeit erstellten "Schaltung" die Regelung. Der Ausbau des graphischen Teils ist in dieser Dimension erst jetzt bei der zweiten Version hinzugekommen. Das vorallem, da in der Testanlage für die Abbildung der Regelung alleine über 400 Controls (Regelglieder) platziert wurden. Da hat nach 3 Monaten keiner mehr verstanden, was da was macht. Also peppe ich jetzt sozusagen den Graphischen Teil auf. Die Verbinder sind hier ein wesentlicher Teil zur Verbesserung der Übersichtlichkeit. Nebenbei ist die Bedienbarkeit bei der Erstellung massiv gestiegen. Vorher hat man in den Einstellungen des Controls den Datensender per Combobox ausgewählt. Jetzt kann man mit der Maus die Anfangs- und Endpunkte eines Verbinders auf die Gates eines Controls bewegen und die verbinden sich dann automatisch. Wohl gemerkt, alles zur Laufzeit. Man programmiert also eine Regelung nicht in Delphi, sondern benutzt das Programm und erstellt eine Regelung im Programm als Projekt mittels Drag&Drop.

Somit ergibt sich, dass der Graphik-Teil nur Mittel zum Zweck ist. Alles was da die Performance so stark belastet, das die Regelung auf der Strecke bleibt, wird dann nicht gemacht oder ein besserer Weg gesucht. Sollte das Zoomen also Probleme bereiten, dann fällt das flach und is halt nich. Aber, Nice to have.

Also, in den Controls steckt echte Funktionalität. Hier soll nicht ein "Schaltplan" gezeichnet werden, sondern eine funktionsfähige Schaltung entstehen, die wie ein "Schaltplan" aussieht.

Nebenbei, das funzt auch schon geraume Zeit.

Wenn das ganze Regelungsgeraffel nich wäre, dann würde ich es natürlich so machen, wie von dir beschrieben. Den Löwenanteil der Controls zeichne ich fast ausschließlich mittels GDI+.

Dank für deinen Hinweis und Gruß

oki

[Medium]

Das Eine hat ja nun nicht zwangsweise etwas mit dem Anderen zu tun. Die Klassen könnten im Wesentlichen gleich bleiben was die Geschäftslogik angeht, sie würden lediglich nicht aus der TControl-Hierachie abstammen, sonden einer Basisklasse der eigenen Layerverwaltung. Mir ging es nur um den Verzicht auf von Windows gestellten Fensterfunktionen- und Klassen, so dass am Ende im Grunde nur ein Image oder eine Paintbox da ist in die sich alle Elemente hereinzeichnen, dabei aber selbst keine "Komponenten" mehr in diem Sinne sind. Es ist ja nur eine Darstellungsfrage.
Der Aufwand ist ganz klar vorhanden, und nicht gerade klein, das ganz ohne Zweifel ;). Daher würde ich einen Umbau eines bestehenden Projektes auch eher in die Schublade "wenn Lust+Zeit da" stecken. Für ein komplett neues Projekt würde sich das aber sicherlich lohnen, und wenn man es geschickt anstellt kann man das ganze auch sehr hübsch wiederverwendbar machen.

[stahli]

Hallo Medium,

Du hast zwar geschrieben, ich hätte mich auch in diese Richtung geäußert, das stimmt aber nicht ganz...

Also ob man solche Anwendungen mit Controls aufbaut oder alles auf eine Zeichenfläche schreibt, hängt sicher noch stark von den sonstigen Gegebenheiten ab.

Ich habe durchaus alles auf Controls aufgebaut, die ich dann auf unterschiedlichen Parents in unterschiedlichen Größen anzeigen kann. Auf den Controls selbst habe ich dann teilweise andere Controls positioniert, teilweise aber auch direkt gezeichnet und z.B. "virtuelle" Anfasser verwaltet, mit denen der Anwender die Controls dann verändern und bearbeiten kann.

Ich denke, man muss das von Fall zu Fall entscheiden, manchmal sind Controls die bessere Lösung und manchmal die eigene Kontrolle von Flächen und Positionen.

Wenn es die Aufgabenstellung zulässt und die Objekte eine gewisse Selbständigkeit haben sollen, sollte man m.E. möglichst Controls verwenden, da diese das Handling erleichtern und die Aufgaben (Zeichnen, überdecken, Mausbereiche, Tastatureingabe etc.) übersichtlicher verteilen lassen. Für ein 3D-Konstruktionsprogramm wäre das jedoch z.B. widerum völlig ungeeignet...

Stahli

[oki]

Hi Medium,

ich kann deinem Vorschlag durchaus ne Menge Sympathie abgewinnen. In meinem speziellen Fall ist es ja auch so, das alles, was an Rechenzeit für die graphische Darstellung abgeht der Regelung fehlt. Somit ist ein "virtueller Konstrukt" für die Regelung ein netter Gedanke. Es hätte den Vorteil, dass man den Grafikteil im Notfall einfach ausläßt wenn es mal mit der Performance eng wird. Wichtiger ist eh die Regelung. Gezeichnet wird dann halt später. Eine klare Prioritätenregelung ist da sicher besser zu realisieren.
Mir ist nur im Moment nicht richtig klar, wie ich das umsetzen sollte. Die Bedienung soll halt grafisch erfolgen. Somit muss ich mir doch auch was einfallen lassen wenn ich Größenänderungen usw. vornehmen will. Dann bin ich doch auch wieder an der Stelle der beliebten Objecte in den Vector-Grafikprogrammen. Halt nur nicht für einzelne Linien und Flächen, sondern komplexe Objekte. Die müssen dann auch noch mit meinen "virtuellen" Regelgliedern (Klasseninstanzen) verlinkt sein. Nebenbei auch noch sich ändernde Ein- und Ausgangswerte visualisieren. Also, ich würde jetzt denken, kann ich doch gleich Controls nehmen. Ob das dann zum Schluss performanter ist mag ich jetzt ehrlich nicht einschätzen wollen.

Aber wie gesagt, ich will damit deinen Vorschlag nicht abwerten oder schlecht machen. Hab im Moment nur den Eindruck, dass das eine Stufe komplexer werden würde. Wie ich das umsetzen sollte ist mir auch noch nicht klar.

Hast du denn Erfahrungen an der Stelle und kannst uns das an einem Beispiel zeigen?

Gruß oki