Zoomen des Inhaltes einer Scrollbox

[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 ).

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 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

[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