[C#] Fenster neu zeichnen lassen?

[MES_K]

Guten Tag,

Ich hab das problem, dass in meiner andwendung eine relativ lange schleife ist. wenn ich nun das programm laufen lasse, und z.B. den Windows Explorer öffne und danach wieder zu meinem Programmfenster geh, ist dieses nur weis. Ich denke, dass es irgendwie daran liegt, dass er das fenster nicht neu zeichnet. leider finde ich keinen befehl, der dieses macht.

um hilfe dankbar...

[Bubble]

Guten Tag,

Ich hab das problem, dass in meiner andwendung eine relativ lange schleife ist. wenn ich nun das programm laufen lasse, und z.B. den Windows Explorer öffne und danach wieder zu meinem Programmfenster geh, ist dieses nur weis. Ich denke, dass es irgendwie daran liegt, dass er das fenster nicht neu zeichnet. leider finde ich keinen befehl, der dieses macht.

um hilfe dankbar...

Du musst die anstehenden Windows-Events (Nachrichten) verarbeiten. Oder alternativ die längere Verarbeitung in einen eigenen Thread auslagern.

[MES_K]

kannst du mir vielleicht ein beispiel zu den windows-events geben?

[geloescht_JesterDay]

Wenn du die Programmiersprache mit angegeben hättest

Bei Delphi z.B. mit:

Application.ProcessMessages;

[MES_K]

also, programiersprache ist c#.

bin immernoch über jede hilfe dankbar.

[DennyB]

Application.DoEvents();

Ich wuerde dir allerdings empfehlen intensive Rechenvorgaenge in einem eigenen Thread auszufuehren.

[geloescht_JesterDay]

Ich wuerde dir allerdings empfehlen intensive Rechenvorgaenge in einem eigenen Thread auszufuehren.

Aus welchem Grund würdest du das Empfehlen?

Also IMHO sollte er das nur tun, wenn das Programm während des Rechenvorgangs "benutzbar" bleiben soll. Wenn das Programm aber zu der Zeit eh nix anderes tut oder tun kann und z.B. nur der Repaint gemacht werden soll, ist die DoEvents()-Methode vorzuziehen, IMHO wie gesagt.

Threads sind schön und gut, aber erfordern auch mehr Aufwand beim Programmieren und der ist nicht immer nötig.

Es ist wie bei fast allem, man sollte sich überlegen, brauche ich einen Thread hier überhaupt, oder baue ich den nur ein, weil es "cool" ist.

DoEvents ist ja genau dazu da, damit die (Ereignisgesteuerte-)Programme auch bei langen Berechnugnen etc. noch auf Events reagieren und nich komplett blockiert sind (also sozusagen der kleine Bruder von Threads).

[DennyB]

Aus welchem Grund würdest du das Empfehlen?

...

(also sozusagen der kleine Bruder von Threads).

Nein, der alte Bruder. Es ist lediglich im Framework enthalten, weil es einfacher ist, diesen einen Aufruf zu machen, dabei kann es zu allen moeglichen Probleme wie zb. Endlosschleifen kommen. Threads sind hingegen sicherer und perfomanter.

Q: What is the reason for maintaining DoEvents in the .NET framework? Why was it not limited to an assembly in the Microsoft.VisualBasic namespace? What is the need for DoEvents when there is proper support for multi-threaded applications?

A: Jason (Microsoft) DoEvenets is a holdover from VB 5.x, but it is still useful in the .NET Framework world. If you have a loop that runs for a long time, it is often easier to call DoEvents than to refactor your loop to use true .NET threading.

Application.DoEvents() - The call of the devil.

DoEvents messes up the normal flow of your application. If I recall correctly, DoEvents is asynchronous which means it terminates before the application has actually processed any outstanding events, so if you're using it in a procedure with many sequential statements, calling DoEvents causes a huge disturbance whenever it's called. Basically, if you find yourself needing to call DoEvents anywhere, think about starting another thread instead, or using asynchronous delegates.

Imagine this if you will: You have a button on your form that, when clicked, does some complex processing. During the complex processing it also intermittently calls DoEvents to keep the application's user interface "responsive" -- not the best method, I would have used async delegates, but we're talking about a mediocre programmer here. Anyhow, the user sees the application still responding and no indication that there's some processing going on. So the user clicks that button again WHILE the processing is going on! The button responds to the event and starts another processing thread but it isn't actually a thread here, I hope you get what I'm saying. So, like I said earlier, DoEvents screws up the flow of the application too easily.

Wenn du mal weiter in Google suchst, wirst du noch jede Menge andere Sachen dazu finden.

Threading im .NET Framework ist hingegen so dermassen einfach geworden, dass es kaum mehr (Verwaltungs)arbeit ist.

[MES_K]

danke für die antwort. funktioniert einwandfrei.

[geloescht_JesterDay]

Nein, der alte Bruder. Es ist lediglich im Framework enthalten, weil es einfacher ist, diesen einen Aufruf zu machen, dabei kann es zu allen moeglichen Probleme wie zb. Endlosschleifen kommen. Threads sind hingegen sicherer und perfomanter.

Zu Endlosschleifen kann es immer kommen. Sicherer und performanter? Wenn dann geringfügig performanter und auch nur, wenn man (das Prog) wirklich ne Menge zu tun hat. Wenn es so eine große Aufgabe ist, mag das ja ok sein, es geht aber in der Frage um eine Berechnung. Das Programm ist vielleicht nur dafür da, diese Berechnung zu machen und das Erg. anzuzeigen, wieso brauch ich da dann einen Thread? Sicherer auch nur, weil ich sie von außen beenden kann, wann immer ich will.

Und das es einfacher ist diesen Aufruf zu machen ist ja genau das, was ich meinte. Manchmal braucht man eben nur etwas kleines, einfaches. Z.B. dass das UI neu gezeichnet wird.

A: Jason (Microsoft) DoEvenets is a holdover from VB 5.x, but it is still useful in the .NET Framework world. If you have a loop that runs for a long time, it is often easier to call DoEvents than to refactor your loop to use true .NET threading.

Meine Rede... trotz allem nützlich und ein Thread ist manchmal einfach zu aufwendig.