Warte / Wait / Sleep / DoEvents Funktion zum Anhalten des Programmes für eine bestimmte Zeit

Artentus · 26. September 2013, 18:10

dive26 schrieb:

Der Ablauf über ein Startmodul sollte in etwas so ablaufen:

Da hast du dein Problem, es gibt bei sowas nämlich keinen festen Ablauf.
Du hast eine Aufgabe (z.B. lade Stammdaten) und weißt nicht, wie lange diese dauert. Anstatt jetzt aber zu warten, bis sie abgeschlossen ist, kannst du auch einfach ein Event nach dem Abschluss feuern und dann dort weitermachen. In deinem Fall wäre das dann auch noch mit THreading zu kombinieren, also die Arbeit findet in einem anderen Thread statt und aus diesem Thread heraus feuerst du dann Events, die angeben, wie weit der Fortschritt gerade ist bzw. ob alles erledigt ist. Der Hauptthread kann dann auf diese Events reagieren und entsprechend z.B. den User über den Fortschritt informieren.

dive26 · 26. September 2013, 18:19

Da stellt sich mir zum gleichen Thema eine weitere Frage.

Lies man in VB6 eine Schleife mit sehr CPU-lastigen Aufgaben durchlaufen und zeigte man in der Schleife auf einem Label oder Textfeld den Fortschritt an, dann wurde das nur dann korrekt und flüssig angezeigt, wenn man DoEvents() in die Schleife packte. Fehlte das DoEvents(), dann sah man im besten Fall gerade den ersten und letzten Wert der Schleife.

Wie sieht das in VB2012 aus, wenn hier "DoEvents" verpönt ist ? Oder passiert das "stocken" hier nicht?

Artentus · 26. September 2013, 18:20

Sowas ist alles ein Fall für Multithreading.

dive26 · 26. September 2013, 18:23

Artentus schrieb:

Anstatt jetzt aber zu warten, bis sie abgeschlossen ist, kannst du auch einfach ein Event nach dem Abschluss feuern und dann dort weitermachen.

wo "dort weitermachen"?
Ich warte ja nicht bis es abgeschlossen ist, sondern die Wartezeit ergibt sich ja automatisch, wenn ich die "Stammdaten-Leseroutine" aufrufe.

Ich habe keinen Plan wie Du das meinst.
Ein praktischer Quellcode wäre hier interessant, vielleicht kappiere ich es dann.

nafets3646 · 26. September 2013, 18:24

Ich habe mal was gebastelt, vielleicht hilft dir das ja weiter:

VB.NET-Quellcode

Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
FirstAction()
End Sub
Dim WantedDuration As New TimeSpan(0, 0, 5)
Private Sub FirstAction()
'Startzeit speichern
Dim StartTime As Date = Now
'Langer Vorgang
For X As Integer = 1 To 100000
Next
'Zeitspanne berechnen
Dim Duration As TimeSpan = Now - StartTime
'Prüfen, ob Warten nötig
If Duration < WantedDuration Then
'Benötigte Zeit warten
Dim timer As New System.Windows.Forms.Timer With {.Interval = CInt((WantedDuration - Duration).TotalMilliseconds)}
AddHandler timer.Tick, Sub()
'Timer wieder stoppen
timer.Stop()
'Weitermachen mit dem nächsten Vorgang
SecondAction()
End Sub
timer.Start()
Else
'Direkt nächsten Vorgang starten
SecondAction()
End If
End Sub
Private Sub SecondAction()
MessageBox.Show("Fertig!")
End Sub

Artentus · 26. September 2013, 18:27

dive26 schrieb:

Ich warte ja nicht bis es abgeschlossen ist, sondern die Wartezeit ergibt sich ja automatisch, wenn ich die "Stammdaten-Leseroutine" aufrufe.

Nur, solange du sie direkt aufrufst. Du du ja aber den Fortschritt anzeigen möchtest ist dies keine Option, du musst den Aufruf in einen Thread auslagern. Und um zu wissen, wann der Thread seine Arbeit erledigt hat, löst du dort ein Event aus.
Quellcode ist nicht mal so schnell erstellt, du musst dich ein wenig gedulden.

dive26 · 26. September 2013, 18:31

Danke für die Mühe nafets...,

Dim timer As New System.Windows.Forms.Timer With {.Interval = CInt((WantedDuration - Duration).TotalMilliseconds)}
AddHandler timer.Tick, Sub()
'Timer wieder stoppen
timer.Stop()

Bedeutet dieser Quellcode, dass beim Aufruf der ersten Zeile "Dim timer As New System.Windows.Forms.Timer With ..." der Timer gestartet wird und mit der Programmausführung der nächsten Zeile erst dann fortgesetzt wird, wenn der Timer abgelaufen ist - und dann die zweite Anweisung mit "timer.stop()" aufgerufen wird?

ErfinderDesRades · 26. September 2013, 18:38

Ja.

Trotzdem ist das Thema für dich viel zu hoch, weil da gehts schon um anonyme Methoden, wo du noch nichtmal jemals was von Delegaten gehört hast, und auch noch nie ein Event implementiert.

Auch nützt nafets Code dir ühaupt nicht bei deim Problem, weil es findet kein MultiThreading darin statt.

Also du kannst dich jetzt mit den angerissenen Themen (Timer, Threads, Klassen, Delegates, Events, anonyme Methoden) völlig verrückt machen lassen, indem du versuchst, alles gleichzeitig zu verstehen.

Ichfürmeinteil empfehle eins nach dem anneren, nämlich dieses Buch lesen (hingegen das Galileio-Openbook ist Mist), und nicht alles annere gleichzeitig nebenher.

nafets3646 · 26. September 2013, 18:41

Bei dem 'Dim timer As New...' wird ein neuer Timer deklariert, welcher als Intervall die Differenz der von dir gewünschten Mindestdauer und der wirklichen Dauer hat. Beim 'AddHandler...' Sagen wir dem Programm, dass es das Timer.Tick-Event auf die direkt dahinter deklarierte Sub weiterleiten soll.
Im Grunde genommen ist es der folgende Code, nur halt kürzer:

VB.NET-Quellcode

Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
FirstAction()
End Sub
Dim WantedDuration As New TimeSpan(0, 0, 5)
Private Sub FirstAction()
'Startzeit speichern
Dim StartTime As Date = Now
'Langer Vorgang
For X As Integer = 1 To 100000
Next
'Zeitspanne berechnen
Dim Duration As TimeSpan = Now - StartTime
'Prüfen, ob Warten nötig
If Duration < WantedDuration Then
'Benötigte Zeit warten
Dim timer As New System.Windows.Forms.Timer With {.Interval = CInt((WantedDuration - Duration).TotalMilliseconds)}
AddHandler timer.Tick, AddressOf FirstAction2
timer.Start()
Else
'Direkt nächsten Vorgang starten
SecondAction()
End If
End Sub
Private Sub FirstAction2(sender As Object, e As EventArgs)
'Timer wieder stoppen
DirectCast(sender, System.Windows.Forms.Timer).Stop()
'Weitermachen mit dem nächsten Vorgang
SecondAction()
End Sub
Private Sub SecondAction()
MessageBox.Show("Fertig!")
End Sub

Hier musste ich allerdings, um es zum funktionieren zu bringen, bei der FirstAction2 Argumente hinzufügen, sodass ich dann in der ersten Zeile den Timer zuordnen und dann stoppen konnte.

Artentus · 26. September 2013, 18:42

Hier hast du mal den einfachsten Fall von Multithreading.
Du brauchst ne Form mit einem label und zwei Buttons, dann kannst du den Code einfach mal übernemen und ausprobieren, was passiert.

VB.NET-Quellcode

Imports System.Threading
Public Class Form1
Private Sub DoSomeWork1()
Thread.Sleep(5000)
End Sub
Private Sub DoSomeWork2()
Thread.Sleep(5000)
End Sub
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
DoSomeWork1()
Label1.Text = "Work 1 done."
Label1.Refresh()
DoSomeWork2()
Label1.Text = "Work 2 done."
End Sub
Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click
Dim t As New Thread(New ThreadStart(Sub()
DoSomeWork1()
BeginInvoke(Sub() Label1.Text = "Work 1 done.")
DoSomeWork2()
BeginInvoke(Sub() Label1.Text = "Work 2 done.")
End Sub))
t.Start()
End Sub
End Class

DoSomeWork1 und DoSomeWork2 stehen für zeitintensive Methoden, Thread.Sleep ist nur für Demonstrationszwecke da drin.

dive26 · 26. September 2013, 18:47

Habe Deinen Code gerade ausprobiert.
Solange man eine solche Funktion aus einer Form heraus ausruft ist alles klar.
Danke deshalb für den Code - kann mir schon einige Einsatzzwecke dafür vorstellen.

In einem Modul mit zeitlich vorgegebenem Ablauf kann ich es aber nicht gebrauchen.

Denn wenn ich vor dem Laden der Stammdaten noch die Grundeinstellungen laden möchte und nach den Stammdaten andere Dateien (die aber unbedingt in dieser Reihenfolge geladen werden müssen), dann hilft diese Timer-Methode nix, weil ich sofort nach Aufruf und Ausführung der Methode "FirstAction" wieder in das Grundmodul zurückkomme und dort die Ausführung der nächsten Aufgabe weitergeht - dann im schlimmsten Fall parallel mit der noch laufenden Aktion - was nicht immer gewollt ist.

Für heute werd ich mal meinen Kopf freibekommen - grüble schon den ganzen Tag wegen dieser besch... Wartefunktion.

Quelle: codinghorror.com/blog/2004/12/is-doevents-evil.html

You've never truly debugged an app until you've struggled with an obscure threading issue. Threading is a manly approach for tough guys, and it will put hair on your chest-- but you may not have any left on your head when you're done.

I agree that DoEvents is not exactly great programming practice, but even Microsoft recommends using it in lieu of hard-core threading for simple problems. So it's something of a tradeoff.

Ich werde mich an das halten, denn Haare auf der Brust habe ich schon und am Kopf schon viel zu wenig

Gonger96 · 26. September 2013, 19:19

Das endet fieß. Lass die Module mal außen vor, die braucht man nämlich nur in einem Fall, der bei dir noch nicht eingetreten ist. Informier dich mal über Klassen und das Prinzip der Objektorientierten Programmierung. Danach kannst du dich mit Multithreading befassen und danach auf dein Problem eingehen.

Eistee · 27. September 2013, 15:44

dive26 schrieb:

Dies kann entweder 10 Millisekunden oder 20 Sekunden dauern (je nach Verbindungsgeschwindigkeit oder Datenbankgröße).
Wie lange ist nicht vorherzusehen.
Wird nach Abschluss der Funktion festgestellt, dass die Anzeigedauer unterhalb der Erkennungsschwelle lag, dann wird mit warte (x)
entsprechend noch ein wenig gewartet bis die nächste Anzeige gebracht wird.
Dauert die Aufgabe ohnehin länger, dann ist die Warte(x) Anweisung nicht notwendig.

Ich finde dies ist ein interessantes Problem, wie man das mit dem Benutzer informieren bewerkstelligt, wenn die Wartezeit variabel ist (z. B. aufgrund der aktuellen Datenbankgröße). Ich würde die Information für den Benutzer so gestallten, das bei einer längeren Wartezeit der Benutzer wirklich informiert wird und zugleich Benutzer welche eben nicht länger warten müssen, auch nicht von einem Aufblitzen irritiert werden.
Was ich auf keinen Fall machen würde, wäre eine künstliche Wartezeit zu entwickeln, nur um in dieser Zeit den Benutzer zu informieren was gerade passiert (ist). Denn im normalen Fall, erkennt der Benutzer ganz von allein was gerade passiert ist.

Benutzer startet Programm -> "Lade Datensätze" [5 Min. z. B. mit Fortschritsanzeige] -> Datensätze/Formular/Oberfläche wird angezeigt.
Benutzer startet Programm -> <keine anzeige oder nur 0,5 sekunden> -> Datensätze/Formular/Oberfläche wird angezeigt.

Ich kann mir nicht vorstellen, dass sich Jemand der nicht warten musste, sich gerade fragt warum aufeinmal das Formular angezeigt wird, mit welchem er arbeiten möchte.
Dadurch wäre das ganze für mich ehr eine Frage des Designs der Oberfläche. Die "Lade Daten" Anzeige sollte so intregriert werden, das es den Benutzer nicht stört bzw. irritiert wenn diese Info wirklich nur extrem kurz auftaucht (wenn die DB z. B. noch sehr klein ist), aber zugleich wartende Benutzer informiert.

SpaceyX · 27. September 2013, 15:52

@dive26:

Servus,

wie Du in Deinem anderen Thread ja gemerkt hast, bin ich absolut nicht einverstanden damit, wie Du meinst das lösen zu müssen. Auch Dein Kommentar (Zitat: unnötiger Kommentar) finde ich ehrlich gesagt ziemlich daneben. Etwas mit unnötig abzutun, nur weil es Dir nicht in den Kram passt. Naja. Niemand meint hier etwas wirklich böse. Aber: Wenn Dich Leute, die offensichtlich nicht erst seit gestern mit .NET arbeiten, auf etwas aufmerksam machen, dann sollte man dem schon Aufmerksamkeit schenken. Wenn Du das auf Deinem Profilfoto bist, dann schätze ich, Du bist ungefähr in meinem Alter. Ich erwarte von einem erwachsenen Menschen, dass er Kritik auch annimmt und nicht alles, was nicht in den Kram passt, einfach ignoriert. Auch wenn Du Dich jetzt angepisst fühlst, dann kannst Du Deinen Standpunkt auch gerne kundtun. Nichts ist für jemanden hier schlimmer, als uneinsichtige Menschen. Wir wollen Dir nur den richtigen Weg zeigen, nichts weiter. Ich musste Dir das jetzt mal sagen, sonst könnte ich nicht mehr in einem normalen Ton mit Dir reden/schreiben. Liegt jetzt bei Dir, Deinen Standpunkt darzulegen und ob Du meinen Ratschlägen noch folgen willst.

Zum Thema: Application.DoEvents gibt keineswegs irgendwelche Kontrollen an andere Prozesse ab. Das ist schlichtweg falsch. .DoEvents() arbeitet lediglich die Warteschlange an Meldungen ab. Der Loop, in dem Du wartest treibt die CPU-Auslastung unnötig nach oben. Das gesamte Pattern, dass Du hier verfolgst, ist falsch.

Mir erschließt sich der Gedanke hinter dem ganzen Vorhaben nicht wirklich. .NET ist eventgesteuert. Es "wartet" ohnehin auf Interaktion. Entweder durch den Benutzer oder programmgesteuert. Darauf solltest Du Deine Programmiertechniken auslegen. Bist Du nun wirklich gezwungen, künstlich einen Wartezustand herbeizuführen, dann bediene Dich bei Threads, Timern, asynchronen Techniken. Es gibt verschiedene Arten von Timern. Windows.Forms.Timer (laufen im selben Thread wie die GUI), System.Timers.Timer und System.Threading.Timer (soweit ich weiß). Die beiden letzt genannten laufen asynchron. Dies bedeutet, sie erzeugen einen eigenen Thread und blockieren dadurch den GUI-Thread nicht. Die GUI bleibt bedienbar. Deine Annahme, .DoEvents() würde nicht blockieren, stimmt auch nicht wirklich.

Nun ist es so, dass die Timer-Klassen Events absetzen, wenn sie ihr Intervall "abgesessen" haben. Hier sind wir wieder beim eventgesteuerten Ablauf. Ich habe hier (extra für Dich) ein Beispiel, was sich genau diesem Muster bedient. Es nutzt einen Timers.Timer, welcher in einem extra Thread läuft. Das ganze ist in einer Klasse gekapselt, um Dir auch das Prinzip (Klasse gegen Modul) aufzuzeigen. Leitet man den Wartezustand ein, so muss auch ein Funktionszeiger (Delegat) mit übergeben werden, welcher nach Ablauf der Wartezeit ausgeführt wird. Schau mal, ob Du das Grundprinzip verstehst. Wenn nicht, frag jederzeit.

VB.NET-Quellcode

Public Class ArtificialWait
Private WithEvents _t As New Timers.Timer()
Private _nextAction As Action
Private _isWating As Boolean = False
Public Event ArtificialWaitDone As EventHandler(Of ArtificialWaitDoneEventArgs)
Public Sub Wait(seconds As Integer, nextAction As Action)
If Not _isWating Then
_isWating = True
_nextAction = nextAction
_t.Interval = seconds * 1000
_t.Start()
End If
End Sub
Private Sub _t_Elapsed(sender As Object, e As Timers.ElapsedEventArgs) Handles _t.Elapsed
_t.Stop()
OnWaitDone()
End Sub
Protected Overridable Sub OnWaitDone()
_isWating = False
RaiseEvent ArtificialWaitDone(Me, New ArtificialWaitDoneEventArgs(_nextAction))
End Sub
End Class
Public Class ArtificialWaitDoneEventArgs : Inherits EventArgs
Public ReadOnly NextAction As Action
Public Sub New(nextAction As Action)
Me.NextAction = nextAction
End Sub
End Class

Nutzen könnte man es in dieser Art.

VB.NET-Quellcode

Public Class Form1
Private WithEvents _aW As New ArtificialWait()
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
_aW.Wait(5, AddressOf NextAction)
End Sub
Private Sub NextAction()
Me.Invoke(Sub()
Button1.Text = "First done"
End Sub)
_aW.Wait(2, AddressOf FinalAction)
End Sub
Private Sub FinalAction()
Me.Invoke(Sub()
Button1.Text = "All done"
End Sub)
End Sub
Private Sub _aW_ArtificialWaitDone(sender As Object, e As ArtificialWaitDoneEventArgs) Handles _aW.ArtificialWaitDone
e.NextAction.Invoke()
End Sub
End Class

Das kann man (fast) beliebig skalieren. Es ist sogar denkbar, einen gesamten Ablauf auf einmal zu übergeben. Also, ich hoffe, wir können für die Zukunft normal miteinander umgehen. Auch, wenn ich den Zustand selber herbeigeführt habe.

dive26 · 27. September 2013, 17:20

Hallo SpaceyX!

Wenn Du mein Statement so aufgefasst hast, dann tut es mir leid. Das war nicht meine Absicht.

Ich wollte im besagten Thread zu einem anderen Thema etwas wissen. Deine Antwort zum Warte-Thema dazu war deshalb für mich unnötig weil ich extra dazugeschrieben habe, dass Bemerkungen über die beispielhaft verwendete Warte-Funktion nicht sinnvoll sind und deshalb zu unterlassen sind. Ich war darüber schon angepisst, bin aber keinesfalls nachtragend. Mir ist ja bewußt, dass alle nur helfen möchten. Also alles ok.

Danke für Deinen Code. Werde mir das mal genauer ansehen.

Weist Du was mich bei dieser Event-Geschichte stört?! Dass ich für das was ich mit "konventioneller VB6 ähnlicher" Programmierung mit 5 Zeilen erledige, bauche ich in der eventgesteuerten Programmierung 2 Seiten.

Ich kann mich natürlich nun bei jeder Kleinigkeit mit EventTimer beschäftigen, jedoch habe ich dann (überspitzt gesagt) 20 Seiten super sauberen und "vorzeigbaren" Code für eine einzige Programmfunktion. Bei hunderten Funktionen ist dann erst alles wieder unüberschaubar für mich.

Ich bin auch kein Teamprogrammierer und die Software wird nie auf C oder was anderes umgeschrieben. Der Quellcode soll für mich die nächsten 10 Jahre verwaltbar bleiben - es reicht wenn ich mich duchblicke - danach gibt es ohnehin schon wieder ganz andere Tools und die ganze Rackerei geht von vorne los.

Meine Anwendungen sind nicht zeitkritisch, auch läuft meine Anwendung i.d.R. solo auf einem Kassenrechner (also nicht mit 20 anderen Programmen gleichzeitig). Auf die ms länger oder kürzer kommt es auch nicht drauf an. Auch nicht darauf ob die CPU einmal duch eine Schleife mehr Rechnen muss. Wichtig ist die Usability für den Anwender - dem ist egal was "drinnen" werkelt und wie eine Funktion zustandekommt.

Würde ich Euch meinen VB6 Quellcode vorlegen, es würde sich niemand zurechtfinden und Euch würden die Haare zu Berge stehen wenn Ihr den Programmierstil sehen würdet

. Trotzdem funktioniert alles und ich weis zu jeder Zeit in welchen Modulen !!! welche Funktionen liegen.
Auf VB2012 steige ich nicht wegen OOP um, sondern weil es wesentlich mehr Funktionen hat als VB6 und unter den aktuellen Betriebssystemen einfacher zu installieren ist (die damit erstellten Programme meine ich). Und wenn MS Funktionen eingebaut hat, die den Umsteigern von VB6 helfen bekanntes und gewohntes weiter zu praktizieren, warum soll man das dann nicht nutzen.

Natürlich versuche ich, wie von Euch immer wieder gepredigt, die Regeln von OOP einigermaßen einzuhalten und umzusetzen.
Was aber nicht bedeutet, dass ich das stringent machen werde können. Ich habe leider nur beschränkte ZeitRessourcen frei um die Software zu portieren - nebenbei muss ich noch mein Geschäft leiten, Einkauf machen, Buchhaltung, Werbung, Verkauf, Support, die alte Software pflegen ....

LG Roland

SpaceyX · 27. September 2013, 17:55

Huhu,

Klar, es ist Deine Entscheidung, auf welcher "Plattform" Du programmieren möchtest. Es geht ja auch nicht darum, Deine alten Programme auf Biegen und Brechen zu portieren. Ich würde, wäre ich an Deiner Stelle, meine alten Programme solange nutzen, bis es einen Grund zur Neuentwicklung gibt. Mir tut es einerseits leid, dass MS nicht endlich den alten VB6-Kram aus den neueren Versionen verbannt, andererseits verstehe ich auch die Intention dahinter. Nur herrscht durch diese, bestimmt nicht schlecht gemeinte Intention, eine stetige Unsicherheit. Was ist neu, was ist alt. Falls Du bei VB bleibst, dann entferne von vorne herein den Microsoft.VisualBasic-NameSpace aus Deinen Projekten. So kommst Du nicht in Versuchung, alte Funktionen zu verwenden. Alternativ steht natürlich auch der Wechsel zu C# frei.

Wie gesagt, portieren würde ich auch kein Stück Software, solange es läuft. Ich würde den Umbruch bei Neuentwicklungen angehen. Das hier mehr Code von Nöten ist, ist nicht richtig. Im Grunde braucht man für eine Wartefunktion 0 Code, weil ohnehin auf Interaktion gewartet wird.

Nur musst Du "uns" auch verstehen, dass wir Dir keine veralteten Funktionen anbieten, sondern das, was atm. aktuell ist. Stress Dich nicht mit Konvertierungen von Software, sondern steck die Zeit, die Du hast, in das Erlernen von neuen Techniken, Funktionen und vor allem Erleichterungen. Vielleicht ergibt sich dann der Schritt, alte Software Schritt für Schritt zu aktualisieren, ganz von alleine. Wer weiß?

In diesem Sinne...

dive26 · 27. September 2013, 18:46

Entschuldige, ich hab schon wieder einen falschen Ausdruck verwendet.

Ich portiere meine alte Software nicht, sondern schreibe eine "ähnliche" aber bessere von Grund auf neu.
Hat neben den bereits genannten Gründen auch noch den Grund, dass man wirklich alles neu gestalten kann, ohne auf die Datenstrukturen der alten Version rücksicht nehmen zu müssen. Man muss nicht mehr kompatible zu den alten Daten sein. Das ist ungemein erleichternd.

Ich würde, wäre ich an Deiner Stelle, meine alten Programme solange nutzen, bis es einen Grund zur Neuentwicklung gibt.

Den gibt es ja. Es müssen ganz neue Funktionalitäten her und Windows 7 und 8 müssen optimal unterstützt werden.

LG Roland
Vielleicht kann ein kleines lauffähiges Musterprogramm meinen Ablauf veranschaulichen: bonit.at/download/demo.zip
Mehr als das möchte ich ja gar nicht. Im Grunde genommen ist da auch keine Warte-Funktion notwendig - ausgenommen vielleicht beim der letzten Ausgabe, falls die abhängig von der Konfiguration einmal länger dauern könnte und einmal in wenigen ms fertig sein könnte. Damit der User sieht was das Programm als nächstes macht. Dann könnte der User im Falle eines Programmfehlers dem Support genau sagen welche Aufgabe vor dem Fehler als letztes angezeigt wurde (nur so als Beispiel).

Ich verabschiede mich ins Wochenende.
LG Roland

VB1963 · 27. September 2013, 19:39

Das was du willst, glaub ich, ist das...
EDIT:
Der Link funktioniert glaub ich nicht, wenn man die Suche verlinkt:
Gib in der Suchleiste in diesem Forum einfach Splash Screen ein...das meine ich

Warte / Wait / Sleep / DoEvents Funktion zum Anhalten des Programmes für eine bestimmte Zeit

dive26 schrieb:

Artentus schrieb:

VB.NET-Quellcode

dive26 schrieb:

VB.NET-Quellcode

VB.NET-Quellcode

dive26 schrieb:

VB.NET-Quellcode

VB.NET-Quellcode

Benutzer online 2

Ähnliche Themen

11 Benutzer haben hier geschrieben