none
Viele Controls auf einer Form - Visual Studio extrem langsam bei Änderungen RRS feed

  • Frage

  • Hallo zusammen,

    ich habe eine Anwendung mit einem Tabcontrol, darauf sind ca. 20 Tabpages und darauf verteilt gute 500 verschiedenste Controls. (Textboxe, Labels, Listviews, Datagridviews etc.)

    Mein Problem ist nun, dass die IDE extrem langsam ist, wenn ich bspw. den Namen eines Controls oder ein paar Eigenschaften ändere. Gibt es irgendwie eine Möglichkeit, meinetwegen die einzelnen Tabpages als separate Dateien inkl. der Programmlogik zu speichern und beim Programmstart dynamisch an das Tabcontrol zu binden?

    Die Änderung eines Controlnamens dauert z.B. mehr als 10 Sekunden. Ich habe noch diverse Extra-Forms, da dauern solche Änderungen zwar auch, aber bei weitem nicht so lange, wie auf dem Hauptformular. Und nun hoffe ich, dass ich das durch das Auslagern irgendwie beschleunigen kann.

    Grüße

    Eiko

    Freitag, 8. November 2019 10:57

Antworten

Alle Antworten

  • Hi Eiko,
    20 TabPages mit 500 Controls in einer (Designer-)Klasse ist schon heftig. Ich würde für jede TabPage ein UserControl erstellen und dann dynamisch laden. Das vereinfacht die Arbeit und vor allem auch die Tests.

    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks

    Freitag, 8. November 2019 21:29
  • Hallo Peter,

    also jede Tabpage inkl. Programmlogik auslagern und Tabcontainer beim Programmstart ein tabpage.add ausführen? Das muss ich mir mal in einer ruhigen Minute ansehen, das ist eine über Jahre gewachsene Anwendung mit unterschiedlichsten Stadien des guten oder schlechten Programmierstils. Ich habe da teilweise Aufrufe von bspw. Buttons aus einer Tabpage auf eine andere und da befürchte ich, dass mir das um die Ohren fliegt.

    Trotzdem danke erstmal für den Tipp.

    Dienstag, 12. November 2019 09:33
  • Hi Eiko,
    es ist recht schwer, eine über lange Zeit gewachsene Anwendung zu "entschlacken".

    Es ist ja nicht notwendig, sofort alle Details in UserControls auszulagern. Üblicherweise sollte jede TabPage einen separaten Teilprozess der gesamten Geschäftslogik bedienen. Das Verquicken unterschiedlicher Teilprozesse (auf unterschiedlichen TabPages) ist auch für den Anwender schwer zu durchschauen und birgt die Gefahr, dass er entweder bevormundet wird und deshalb die Akzeptanz sinkt oder er Fehler in der Arbeit macht, weil er vielleicht diese Verquickung nicht versteht.

    Alle TabPages würde ich im Hauptprogramm lassen und erst bei Bedarf (Auswahl/Aktivierung) das entsprechend UserControl nachladen. Das UserControl selbst ist verknüpft (gebunden) mit einem oder mehreren ViewModels, die die Geschäftslogik enthalten. Zusätzlich gibt es einen Manager, der den Wechsel zwischen den TabPeges verwaltet. Mit dieser Logik entfallen Aufrufe einer Seite auf Inhalte einer anderen. Die erste Seite legt Daten in einem ViewModel ab und gibt dann dem Seiten-Manager das Signal zum Aufruf einer anderen Seite. Die andere Seite holt sich dann die erforderlichen Daten (z.B. auch Zustände) und verarbeitet ihren Teilprozess der Geschäftslogik.

    Das hört sich erst einmal etwas kompliziert und aufwendig an. Diese Projekt-Technologie sollte definiert und festgeschrieben werden. Danach kann dann schrittweise an die Umsetzung gegangen werden, indem nach und nach einzelne Steuerelemente entwickelt werden und die TabPage dafür umgebaut bzw. hinzugefügt wird. 

    Beginnen kann man mit dem Auslagern des vorhanden Programmcodes in ein UserControl und dem Einbinden des UserControls in die TabPage. Zur Verhinderung von Verzögerungen können ViewModels vorher (asynchron) instanziiert werden, so dass bei Nutzung Daten bereits geladen wurden und zur Nutzung bereitstehen.


    --
    Best Regards / Viele Grüße
    Peter Fleischer (former MVP for Developer Technologies)
    Homepage, Tipps, Tricks





    Dienstag, 12. November 2019 10:10