Liebe Leidensgenossen

Ich möchte euch mal wieder zu MDI Childs ein wenig "nerven".

Ich habe festgestellt, das unter VB2010 das Öffnen/Anzeigen von Childs im Vergleich zu VB6 wesentlich länger dauert. Auch wird beim Laden der Childs anscheinend generell NICHT die Größe der Form bei der Erstellung verwendet, sondern irgendein Standartwert (ca. 3/4 der Bildschirmgröße). Erst im Load Event bekomme ich die Möglichkeit, die Childform auf die richtige Größe zu stutzen.

Das sieht dann natürlich etwas "sparsam" aus, wenn dann ca. 10-30 Childs laden, anzeigen und scalieren. (Ca. 10s wildes "Fenster-Geflimmer).

Es hat anscheinend nichts mit der Hardware Performance zu tun, denn selbst auf modernen MultiCore Workstations mit neuester Grafikhardware gehts genauso gemütlich zu, wie auf alten, lahmen Maschinen mit 2GHz SingleCores und Chipsatzgrafik. Manchmal habe ich sogar (subjektiv!) den Eindruck, da gehts sogar noch etwas flüssiger zu.

Fällt hier jemandem dazu etwas ein? Es würde mir schon helfen, wenn die Childs mit einer vordefinierten (kleinen) Größe oder erstmal als Symbol starten würden. Aber alle meine Voreinstellungen werden bis jetzt anscheinend beim Laden ignoriert...shit!

Gruß, Stefan

Hatte schon befürchtet, das niemand damit was anfangen kann, und nun "hagelts" doch noch Erstaunliches!

Also:

1. @RFG: Ja! Leider ist diese Anzahl Childs erforderlich, und zwar so schnell wie möglich und alle gleichzeitig. Stehe gleichzeitig bei 2 Projekten vor diesem Problem. (Beide eine Art Prozessvisualisierung, bei denen nach Auswahl eines vorkonfigurierten "Presets" Prozessdaten verschiedener Anlagenteile in Childs nebeneinander angezeigt werden müssen. Man konnte auch bei der bestehenden alten VB6 Anwendung durchaus erkennen, wie die Childs der Reihe nach eingeblendet wurden. Das war auch nie ein Problem, solange es halt halbwegs zügig und "flimmerfrei" vonstatten geht. Meine ersten Versuche unter VB2010 sehen dagegen recht "sparsam" aus! :-))

2. @TF: Docking Frameworks hört sich in der Tat SEHR interessant an. Da werde ich mal weitergraben!

3. @PF: Den Konstruktor "new" werde ich mir auch genauer anschauen (wie auch immer das gemeint ist..event beim Erstellen einer Form? ich werds schon finden...) Das Ding hört sich jedenfalls so an, als wenn es ohne große Änderungen implementierbar ist, und erstmal das (Flimmer) Problem stark mildern könnte. Oder meinst du sogar den Punkt 4 (Von EDR)?

4. @EDR: Denn DIESER Tip beschreibt ziemlich genau, was ich möchte! Ich muß eh beim Erstellen der Childs einige Parameter übergeben, sodaß das auch genau der richtige Zeitpunkt sein sollte, die Größe und Position festzulegen! Genau DAS werde ich als Erstes morgen mal austesten!

Nebenbei war ich auch nicht ganz untätig und habe schonmal alle unnötigen REDIMS der Childs aus den Projekten rausgeholt. (Wenns von der Performance her ging, habe ich es in der Vergangenheit manchmal wohl nicht so ganz eng gesehen mit der Codeoptimierung..:-)) Von den 10s Geflimmer bin ich heute schonmal bei ca. 5s angekommen.

Danke euch! Da hab ich erstmal wieder Futter....

Also...beim "new" gleich die Position und Größe angegeben klappt. War mal wieder zu sehr in VB6 "festgehangen" und hatte deswegen noch eine Fensteränderung drin, "WÄHREND" die Form schon sichtbar war. (Hab ich aus irgendeinem Grund damals so mit "Top" und "Left" gemacht, weils nicht anders ging. Ich glaube, VB6 erlaubte das nur, wenn Form schon sichtbar, alter Müll halt!

Habs jetzt so gemacht:

"PicNum", weil es ein ganzes Array von Childs ist und jedes Child anhand dieser Public-Vari wissen muß, welche laufende Nummer es bekommen hat.
Kein "Bounds" wie vorgeschlagen, sondern "DesktopLocation" und "With" und "Height", weil ich´s direkt in Pixel haben muss, und nicht relativ zur Gesamtfläche.
Die Positions- und Größen- Variablen werden schon vorher berechnet, direkt nachdem das Hauptfenster maximiert wurde. (Kann halt auch mal was anderes sein, je nach Bildschirmauflösung und Hauptfenstergröße.
Die Performance ist nun sogar etwas höher, als bei der alten VB6 Version! Schön!
Gruß, Stefan

Aber:

Weder ich, noch mein Aufgabengebiet sind im Sinne des Programmierens "normal"!

Du warst noch nie in der Steuerwarte eines großen Chemibetriebs und hast dir da die Steuerungs- und Visualisierungssoftware genauer angeschaut, oder?

Dort wird vielfach (und mit Erfolg!) mit solchen Techniken gearbeitet. In meinem Fall z.B. geht es um eine Visualisierung, bei der auf mehreren, teilweise 46" großen Bildschirmen eine ganze Chemianlage interaktiv dargestellt und bedient wird. Und zu jeder Meßstelle, zu jedem Alarm, zu jeder Regelung, zu jedem Antrieb, zu jedem Motor, zu jeder Batch- oder Phasensteuerung gibt es da immer eine kleine Form, auf der die Bedienelemente dieses Objekts (FIX) beheimatet sind. Diese Formen können im Minimalfall nur aus einem Alarmlabel und einem Reset Button bestehen, können aber auch sehr komplex sein, wenn es um rezepturgesteuerte Ablaufsteuerungen geht. Es gibt darüberhinaus natürlich noch weitere "Detail-Formen", die nur bei weiterem Analyse-Bedarf oder zur Konfiguration aufgerufen werden, und die man dann auch frei positionieren, "anheften" oder wieder wegklicken kann.

Im Hintergrund kann auf der Midiform im einfachsten Fall ein einfaches Flußdiagramm oder PID als Bild zur Orientierung eingeblendet sein, aber es sind auch in diesem Hintergrund zusätzliche Visualisierungen möglich. (Dann via ActiceX in z.B. MS Visio eingebunden). Hab´s auch schonmal auf Kundenwunsch mit Powerpoint als Hintergrund versucht, bin aber daran gescheitert, das sich der Powerpointviewer je nach Office Version nicht zuverlässig in VB einbinden läßt.

Der Vorteil von solchen Lösungen im Gegensatz zu "richtiger, großer" Leitsystem Software von Siemens, Emmerson oder Honywell ist eben die Einfachheit des Konzepts, die große Unabhängigkeit von der Hardware sowie auch vom Hardwarehersteller und nicht zuletzt natürlich auch der Preis.

Aber das ist eine Diskusion, die nicht in dieses Forum gehört...:-)

Gruß, Stefan

Leutz, das liest sich nun alles endschieden angenehmer für mich. Danke!

Bin halt vor vielen Jahren bei VB6 hängen geblieben, MUSS nun (aber WILL mittlerweile auch) auf VB2010 umsteigen, weil es tatsächlich noch einige Jahre bis zur Rente sind und ich mittlerweile auch wieder Spaß am Programmieren gefunden habe.

Aber das geht halt alles recht langsam, da diese Themen nur vielleicht 20% meines Jobs ausmachen. OK, nochmal 20% hole ich dann noch von meiner Privatzeit dazu. Habe in den letzten Monaten schon wieder viel gelernt und einige Dinge erfolgreich portiert und auch deutlich weiterentwickelt. (Vor allem in Sachen Multithreading)

Da werden aber mit Sicherheit noch ganz viele Dinge von euch kommen, von denen ich im Leben noch nix gehört habe! (Ich bitte also um Nachsicht!)

Ich komme aus der Industrie, wo die Wechselzyklen tatsächlich sehr viel langsamer stattfinden und Sprüche wie: "Never change a running system" sehr wohl ihre Berechtigung haben.

Daher geht es mir momentan hauptsächlich auch garnicht darum, auf Biegen und Brechen die neuesten Techniken einzubringen, sondern vorrangig um die Funktion und das Interface zum späteren Benutzer. Das muß 100% passen, und der Bediener muß auch immer ein wenig sein "altes" System wiedererkennen, sonst habe ich meinen Auftrag verfehlt.

Ihr würdet euch wundern, welche Systeme von den Bedienern als "Highlights" angesehen werden! Nämlich eben NICHT die Schönsten, Modernsten, Komfortabelsten usw...Sondern die seit mehr als 10 Jahren STABIL und absolut ZUVERLÄSSIG laufenden Dinger, egal wie altbacken und krude sie auch aussehen mögen....

Aso...noch ein Kommentar zum Trennen von Daten und Oberfläche: Das IST auch bei meinen Systemen tatsächlich so. Vielleicht haben wir da nur eine unterschiedliche Auffassung, was Daten sind, und was nicht..:-))

Man liest sich! (Sicherlich...denn so einige Dinge, die ihr mir genannt habt, sind einfach ZU interessant, als das man es nicht ausprobieren müßte)

Gruß, Stefan