| 

.NET C# Java Javascript Exception

5
Servus zusammen!

Das was hier jetzt kommt ist eine simple und doch irgendwie interessante Frage (so denk ich zumindest :) )
In unserem Entwicklerteam gibt es mehrere Ansätze um Windows-Forms anzuzeigen bzw. diese darzustellen. Da Anwender ja immer wieder wollen, dass gewisse Einstellungen gespeichert werden bzw. beim erneuten Laden dargestellt werden, stellt sich uns die Frage, wann und wo das passieren sollte. So gibt es bei uns im Haus folgende drei Möglichkeiten:
1. Bereits im Konstruktor Fensterpositionen und Grunddaten zu laden
2. Diese Lade- und Positionierungsvorgänge im Form.Load oder
3. erst im Shown durchzuführen.

Meiner Meinung nach können/sollten "grafische Spielchen", wie Button-Positionierung, Größen und Fensterpositionsanpassungen im Load-Event behandelt werden, während reine Datendarstellung erst im Shown-Event beachten werden sollten.
Leider gibt es ja dabei immer wieder das Problem, dass bereits beim Darstellen von Schaltflächen bestimmte Daten geladen werden müssen (also darf der Anwender Export-Funktionalitäten nutzen, etc.)

Mit dieser "Mischerei" passiert es leider oft, dass die Fenster dann flackern.

Meine Frage dazu: Wie handelt ihr Fensterladeverhalten und kennt jemand von euch offizielle MS Aussagen, wann und wo am Besten solche Aktionen gesteuert werden?

Ich freu mich auf Eure Antworten!
News:
10.01.2012
daWastl 277 7
4 Antworten
2
Hi daWastl,

welches Event bzw. obs im Konstruktor gemacht werden soll, ist in meinen Augen etwas, auf das Ihr Euch im Team einigen solltet und es dann konsequent so umsetzen solltet. Shown hat wie Du ansprichst evtl. das Problem mit dem Flackern.
Da eine Windows Form keine Begin/EndUpdate Methode anbietet, die Controls wie z.B. eine ListBox vom ständigen Neuzeichnen abhält, hätte ich spontan drei Einfälle (untested):

  • Versuchs mal mit einer Form.Suspend/ResumeLayout Klammer
  • Pack Deine Controls alle in ein UserControl, dieses bietet Begin/EndUpdate und in die Form lediglich das UserControl.
  • Überschreibe Form.OnPaint und baue Begin/EndUpdate() Funktionalität in die Form ein (vlt. habt Ihr eh eine eigene Form-BaseClass?)

Vielleicht is ja was dabei, was Euch weiterhilft, wie gesagt, ich habs nicht ausprobiert.
Gruß
Florian
10.01.2012
ffordermaier 8,3k 2 9
Das "Flackern" tritt leider nicht nur mit Form.Shown auf sondern auch mit Load - deinen Tipp mit Suspend/ResumeLayout könnte funktionieren. Das teste ich jetzt direkt mal :)
daWastl 10.01.2012
In dem "schlimmsten" Projekt meines Kollegen mal versucht: es wird auf jeden Fall besser - Danke dir für deine Tipps!
daWastl 10.01.2012
2
Eventuell kannst Du Dir die "load vs. shown"-Überlegung auch sparen, denn Windows Forms bringt da schon eine Menge mit. Schau mal unter Eigenschaften -> Application Settings. Dort kannst Du eine große Anzahl von Eigenschaften Deines Forms bzw. Controls an Application Settings binden, wahlweise mit Application oder User Scope. Wenn Du letzteres wählst, mußt Du nur noch an geeigeneter Stelle (z.B. FormClosing-Event) ein
Settings.Default.Save();
einbauen, und schon ist die Form-Property user-spezifisch gespeichert und wird beim nächsten Laden des Forms wieder wie von Geisterhand angewendet.

Siehe dazu Anwendungseinstellungen für Windows Forms (MSDN).
10.01.2012
Matthias Hlawatsch 13,0k 3 9
das "funktioniert" leider nicht, soll heißen wir können leider diese tolle Funktion leider nicht nutzen, da die Infos beim Start nicht fix sind. Rechte, Lizenz-Informationen und Grunddaten können sich auch geändert haben. Unsere Applikation gibt es "leider" her, dass ein User an unterschiedlichen Arbeitsplätzen sitzt und jedes Mal die gleichen Einstellungen haben will, d.h. Lesen in Datenbanken...
daWastl 10.01.2012
Dann könntest Du noch überlegen, ob Du die User-scoped AppSettings in Deiner DB verwaltest. Prinzipiell sollte das mit einem eigenen SettingsProvider gehen - siehe dazu den Überblick in http://msdn.microsoft.com/en-us/library/8eyb2ct1.aspx Ich hab das aber leider selbst noch nicht gemacht und auf die Schnelle jetzt auch nichts richtig passendes bei Google dazu gefunden.
Matthias Hlawatsch 10.01.2012
1
Wir haben da eine relativ einfache "Philosophie".
Alles was schnell und ohne Verzögerung geladen werden kann, verfrachten wir in das Load()-Ereignis.

Müssen viele Daten geladen werden oder eine Abfrage dauert länger, dann zeigen wir erst das Formular an und laden im Shown()-Ereignis die Daten. Wir kombinieren das mit einer Progressbar o.ä., um dem Benutzer anzuzeigen, dass das Formular noch arbeitet.

Um das Flackern zu vermeiden, kannst Du auch noch das DoubleBuffering im Konstruktor aktivieren:
Me.SetStyle(System.Windows.Forms.ControlStyles.DoubleBuffer, True)
Me.SetStyle(System.Windows.Forms.ControlStyles.AllPaintingInWmPaint, True)
Me.SetStyle(System.Windows.Forms.ControlStyles.ResizeRedraw, True)
Me.SetStyle(System.Windows.Forms.ControlStyles.UserPaint, True)


LG, Micha
10.01.2012
mblaess 1,1k 8
1
was das Flackern betrifft, habe ich die Erfahrung gemacht, dass es teilweise durch das Befüllen von Steuerelementen im Form_Load-Event ausgelöst wird, und zwar meist, dann wenn hierduch das Steuerelement selbst wieder ein Event feuert, welches dazu führt, dass andere Steuerelemente auf dem Formular geändert werden. (z.B. wenn ich die CheckState-Property einer CheckBox ändere und das CheckStateChanged-Event implementiert habe, um in Abhängigkeit vom Status der Checkbox andere Steuerelemen im Formular ändere). Im ungünstigsten Fall bekommt man hierdurch eine ganze Kaskade von Events und im weiteren zu Flackern. SuspendLayout/ResumeLayout funktioniert ganz gut, ich bin aber in diesen Fällen dazu übergegangen, die Events nicht mehr im Designer, sondern manuell im Shown-Event des Formulars zu verdrahten. Die Initialisierung führe ich im Form_Load Event durch. Eine Alternative wäre eine boolsche Variable, die in jedem implementierten Event abgefragt wird. Hiervon rate ich aber ab, da das ganze schnell unübersichtlich werden kann.
11.01.2012
luedi 1,7k 1 9

Stelle deine .net-Frage jetzt!