Visual Studio GUI: Refresh der Windows Form Anzeige nervt

Hallo liebe Kollegen,

ich habe ein "Problem" was mich zunehmend nervt. Ich programmiere mit 3 Monitoren, damit ich alle wichtigen Fenster sofort im Blick habe: mehrere Quellcode Fenster, TotalCommander zum Dateien Kopieren, Datenbank Tabellen etc...

Wenn ich eine WinForms Anwendung schreibe, löse ich gerne das Form Fenster und schiebe es auf einen anderen Monitor. Dann kann ich auf einem Monitor programmieren und auf einem das Form editieren. Jetzt kommt mein "Problem": Ich editiere in der Form und gehe dann in irgendeinen Quelltext um etwas zu editieren. Klicke ich wieder auf das Fenster mit der Form, aktualisiert Visual Studio das Fenster erstmal - gerade bei komplexeren Forms dauert das. Das einmalige Refreshen stört mich nicht, aber wenn man öfter hin und her wechselt dann nervt das Verhalten doch ziemlich.

Es ist auch egal ob der Quellcode der editiert wurde überhaupt etwas mit dem Fenster zu tun hat. Es reicht schon ein Leerzeichen in einer Datei zu setzen die gar nichts mit der Form zu tun hat, damit der Effekt auftritt.

In den Optionen und mit Tante Google habe ich nichts gefunden. Gibt es da eine Einstellung, damit er das nur macht wenn ich den Quellcode vom Form bearbeitet habe ? (also wenn es wirklich notwendig ist - oder manuell ?)

Gruß

Meinst Du die Erkennung der Editor-Änderung?

VS erkennt, dass die Datei ausserhalb des Editors verändert wurde. Es fragt Dich, ob es die Änderungen übernehmen soll oder die aktuelle Fassung im Editor behalten soll.
Das Verhalten ist so korrekt und es ist "fahrlässig", dass automatisiert in irgendeine Richtung entscheiden zu lassen.

Mir ist keine Möglichkeit bekannt, dass dies unterbinden werden kann (und das finde ich wie gesagt auch gut so).

Hallo Charly,

ganz ehrlich: Gerade bei komplexen Views ist es hilfreich, den Designer komplett aus zu machen. Ich arbeite zwar mit WPF, habe aber sehr komplexe Views teilweise. Das erste, was ich da mache: Designer aus. Erstens versteht man dann den Code besser, zweitens lädt es schneller und drittens kann man dadurch auch schneller arbeiten.

Gruss

Coffeebean

Hallo Charly,

ich finde dieses Verhalten auch sehr nervig. Es wäre bei einem modernen Entwicklungssystem doch sicher möglich den Refresh im Hintergrund auszuführen.

Kleiner Trost : Vor VS2010 war das noch viel schlimmer.

Abhilfe : Erste alle Änderungen im Form vornehmen (Events einfügen etc), danach den Code Behind ändern.

Grüße Bernd

Vielen Dank für eure Meinungen.

Meist ist das bei mir so eine Situation, dass ich nochmal nachsehen will welchen genauen Namen eine Combobox o.ä. hat. Dann klicke ich auf das entsprechende Element und habe keine Verwechslungsgefahr. Das ist dann so ein Klick den man "mal ebend" machen will und genau dann nervt mich der Refresh.

Den Designer ganz ausschalten ? Ich frage mich wie das bei euch in Reallife aussieht wenn Ihr ohne Designer die Elemente positioniert. Das designen funktioniert ja auch ganz gut - nur das hin und her springen nicht.

Nagut, ich werde damit erstmal weiter leben. Es hätte ja sein können dass jemand einen Geheimtip hat 😃

Vielleicht sollte ich mir einfach auch mal einen schnelleren Prozessor gönnen 😉 Der Schuster hat ja meist die schlechtesten Latschen 😃

In Reallife sieht das so aus, dass so wenig wie möglich hin und her gewechselt wird und schon gar nicht Designer und Code gleichzeitig angezeigt wird. Würd ich auch bei meinen 2 Bildschirmen nicht machen, da nach dem groben Positionieren von den Elementen der Designer erst mal überflüssig ist. Hat man alles ordentlich benannt, kann ich mit dem Designdokument, das normal neben mir liegt, weiterarbeiten.

Kleiner Trost : Vor VS2010 war das noch viel schlimmer.

In VS 2003 (.Net 1.1) musste man sogar die Designer-Fenster explizit vor dem Build schliessen... da der Designer gerne die Fenster zerschossen hat wenn beim Build ein Fehler auftrat.

Ich frage mich wie das bei euch in Reallife aussieht wenn Ihr ohne Designer die Elemente positioniert

Im Real Live hat man niemals komplexe Layouts.
Sobald du mehr als nur ein paar Textboxen hast wird es Zeit über Usercontrols nachzudenken.

Und schon das du nachschauen musst wir ein Control heißt, zeigt das da noch Luft bei der Namensgebung ist.
Auch muss man eigentlich selten direkt auf Controls zugreifen, auch nicht in WindowsForms, denn auch hier ist Databinding gut zu gebrauchen.