|
| |
Visual-Basic Einsteiger| VB6: Steuerelemente werden plötzlich nicht mehr aktualisiert | |  | | Autor: vbidd | | Datum: 27.07.16 05:30 |
| Hallo,
ich habe ein Problem, welches mich schon seit Jahren bei VB6-Programmen stört:
Wenn ein Programm eine intensive Verarbeitung macht (z.B. Verzeichnisse durchsuchen, etc.), dann werden Steuerelemente wie Labels, etc. zunächst korrekt aktualisiert.
Nach einigen Sekunden klappt diese Aktualisierung jedoch nicht mehr. Das Programm wird zwar immer noch korrekt durchgeführt, aber man hat als Anwender den Eindruck, als wenn es sich aufgehängt hätte.
Wenn die Verarbeitung dann durch ist und das Programm auf neue Eingaben wartet, dann aktualisieren sich alle Steuerelemente wieder.
Ein mögliches Beispiel wäre ein Programm, welches das komplette Laufwerk C eines Rechners durchsucht und in einem Label den jeweiligen Dateinamen ausgibt. Mehrere Sekunden funktioniert das auch gut, aber irgendwann ist das Programm so beschäftigt, dass das Labelfeld auf einem Wert stehen bleibt, obwohl das Programm weiter läuft.
Kennt jemand diesen Effekt und gibt es eine Lösung, wie man VB6 dazu bringt, stets eine korrekte Ausgabe zu machen?
Gruß | |
| Re: VB6: Steuerelemente werden plötzlich nicht mehr aktualisiert | | | | Autor: visualfx | | Datum: 27.07.16 09:06 |
| Hallo vbidd,
Du mußt in Deine Schleife / Deine Schleifen welche ein Laufwerk bzw. Ordner durchsucht / durchsuchen ein paar DoEvents einstreuen.
Siehe hier: http://www.vbarchiv.net/commands/cmd_doevents.html
Durch das Aufrufen von DoEvents wird Deinen Steuerelementen die Gelegenheit gegeben sich zu aktualisieren 
Gruß, Stefan | |
| Re: VB6: Steuerelemente werden plötzlich nicht mehr aktualisiert | | | | Autor: visualfx | | Datum: 27.07.16 16:19 |
| Hallo,
ich gebe Dieter recht, daß für die Performance ein Label.Refresh gegenüber einem DoEvents günstiger sein kann.
Hat man aber auf seinem Formular z. B. noch einen Abbrechen-Button (um die laufende Schleife vorzeitig zu beenden), so wird dieser wahrscheinlich mit der Label.Refresh-Lösung eventuell nur sehr zäh bis garnicht reagieren. Mit der DoEvents-Lösung dagegen aber schon.
D. h. die DoEvents-Lösung gibt dem gesamten Programm an allen Stellen die Gelegenheit Dinge zu tun / zu verarbeiten / zu aktualisieren.
Gruß, Stefan | |
| Re: VB6: Steuerelemente werden plötzlich nicht mehr aktualisiert | | | | Autor: Blackbox | | Datum: 27.07.16 19:00 |
| Hallo,
wenn man Statements wie DoEvents braucht, wenn man sie überhaupt braucht, ist etwas am eigenen Code faul.
Ein so altes Programm wie VB 6.0, mit dessen Bordmitteln, würde ich nie und nimmer dafür einsetzen Ordnerstrukturen neuerer Betriebssysteme, sagen wir mal ab Win98/WinNT 4.0, durchsuchen zu lassen.
Die Bordmittel von VB6.0 dafür sind DOS-Routinen aus längst vergangenen Tagen. Dafür hat man doch die Shell. Die ist immer da und brauche die nicht mitliefern. Die VB6 Bordmittel tun Gutes, wenn gezielt etwas zu machen ist. Sie tun es aber nicht, wenn man etwas durchsucht, wenn man zB auch noch Dateiinhalte analysieren muss.
Beitrag wurde zuletzt am 27.07.16 um 19:30:55 editiert. | |
| Re: VB6: Steuerelemente werden plötzlich nicht mehr aktualisiert | | | | Autor: vbidd | | Datum: 27.07.16 20:20 |
| Hallo visualfx,
vielen Dank für den tollen Tipp. Das war genau das, was ich gesucht hatte.
Gruß Harald | |
| Re: VB6: Steuerelemente werden plötzlich nicht mehr aktualisiert | | | | Autor: vbidd | | Datum: 27.07.16 20:23 |
| Hallo Dieter,
mit Refresh hatte ich es früher schon mal versucht, aber wenn das Programm beschäftigt ist, reagiert es nicht mehr so richtig auf ein Refresh.
Aber vielen Dank für den Tipp.
Gruß Harald | |
| Re: VB6: Steuerelemente werden plötzlich nicht mehr aktualisiert | | | | Autor: vbidd | | Datum: 27.07.16 20:36 |
| Hallo,
es mag sein, dass ich etwas altmodisch bin, aber mir ist gerade die VB6-Entwicklungsumgebung viel lieber als die angeblich moderne, aber völlig überfrachtete von VB.net.
Ich nutze vb6 immer noch sehr gerne, um kleine. Microsoft ist meines Erachtens auch nicht sehr konsequent, denn immerhin lebt vb6 ja noch als "Makrosprache" innerhalb Office weiter. Und vb6 ist eine 32Bit-Sprache, die auch heute noch (unter Win 10) läuft.
Gruß Harald | |
| DoEvents-Funktion | | | | Autor: visualfx | | Datum: 27.07.16 21:24 |
| Hallo,
hier noch eine kleine Erläuterung zur DoEvents-Funktion:
Die DoEvents-Funktion übergibt die Steuerung an das Betriebssystem, damit es andere Ereignisse verarbeiten kann. Es werden hierbei aber definitiv NUR (!!!) anstehende Ereignisse des eigenen Programms verarbeitet und KEINE (!!!) Ereignisse anderer Programme.
D. h. die DoEvents-Funktion kehrt um so schneller zurück um so weniger Ereignisse im eigenen Programm zur Verarbeitung anstehen.
Die Verarbeitung von Ereignissen anderer Programme wird quasi simultan sowieso immer gemacht, denn Windows ist seit Windows 95 ein richtiges Multi-Tasking- (= Multi-Processing und Multi-Threading) -Betriebssystem. Dieser Mechanismus kann so ohne weiteres nicht verhindert werden und die Verhinderung macht auch absolut keinen Sinn.
Statt ein Programm mit einem Thread und an ein paar nötigen Stellen mit DoEvents-Aufrufen (Single-Threading) zu entwickeln, könnte man natürlich auch ein Programm mit zwei (oder mehr) Threads entwickeln (Multi-Threading): im einen Thread läuft die eigentliche Funktion (z. B. Schleife) ohne DoEvents, im anderen Thread läuft die Bedienoberfläche (Formulare mit Steuerelementen).
Rein technisch, funktional als auch optisch gesehen ist aber die 1te Lösung (Single-Threading mit DoEvents) und die 2te Lösung (Multi-Threading ohne DoEvents) absolut gleichwertig!
Somit ist auch der Aufruf der DoEvents-Funktion absolut legitim und keineswegs altmodisch
Gruß, Stefan
Beitrag wurde zuletzt am 27.07.16 um 21:30:44 editiert. | |
| Re: VB6: Steuerelemente werden plötzlich nicht mehr aktualisiert | | | | Autor: Blackbox | | Datum: 27.07.16 21:31 |
| Hallo vbidd
versehe ich - aber man sollte doch, weil VB6.0 objektorientierte Sprache ist, die modernen Objekte auch wirklich wahrnehmen und VB6.0 ist, im Gegensatz zu .NET, Spezialist für sowas ;) VB 6 ist etwas für den suchenden Geist, .NET für den der keinen Geist hat.
Diese Botschaft angekommen?
P.S.: Ich will damit keinen VB-classic versus VB.NET Diskus aufkommen lassen, sondern einen Hinweis darauf setzen dass der VB6.0-Progger sofern er es tut, einen Aufwand geben muss das richtige Objekt für die richtige Aufgabe zu finden. Einem echten Objektorientierten macht das aber echt Spass
Das meint ganz genau: Wenn ich heute VB6 Programme aufsetze muss ich die modernsten Objekte anziehen und, so um das es jetzt hier geht, auch manches Bordmittel nicht mehr verwenden.
Darunter fallen alle Funktionen die das Betriebssystem verwenden.
Beitrag wurde zuletzt am 27.07.16 um 21:47:11 editiert. | |
| Re: DoEvents-Funktion | | | | Autor: visualfx | | Datum: 27.07.16 23:49 |
| ... noch ein kleiner Nachtrag:
die DoEvents-Funktion von VB6 gibt es auch bei allen .Net-Sprachen (C#, C++, F#, VB.Net) - und zwar als DoEvents-Methode vom Application-Objekt: Application.DoEvents() !
Siehe hier: https://msdn.microsoft.com/de-de/library/system.windows.forms.application.doevents(v=vs.110).aspx
Somit ist die Notwendigkeit von DoEvents nicht davon abhängig ob man mit VB6 oder C#, C++, F#, VB.Net, etc. entwickelt.
Sondern: die Notwendigkeit von DoEvents ist es im Fall einer längeren rechenintensiven Funktion bzw. Methode allen anderen Programmteilen die Möglichkeit zum Arbeiten / Aktualisieren zu geben. Und dieser Fall ist vollkommen unabhängig von der verwendeten Programmiersprache.
Beitrag wurde zuletzt am 27.07.16 um 23:59:38 editiert. | |
| Re: DoEvents-Funktion | | | | Autor: Oggi | | Datum: 28.07.16 17:45 |
| Das mein ich doch auch. Es gilt zu unterscheiden ob der Code klemmt oder die Programmausführung. Oft weiß ich schon vorher, dass ich ein DoEvents benötigen werde. Das liegt aber nicht unbedingt an VB6 sondern an Windows. Alles was hier über das alte VB6 gesagt wird, trifft doch um so viel mehr auf Windows selbst zu. Das in vielen Systemteilen wohl noch kooperatives Multitasking (anstatt preemptiven Multitasking) verwendet bzw. benötigt, und genau das macht DoEvents.
Beitrag wurde zuletzt am 28.07.16 um 17:46:59 editiert. | |
| VB6 veraltet ? Wieso ??? | | | | Autor: visualfx | | Datum: 28.07.16 22:26 |
| Hallo Oggi,
ich finde Du hast es sehr gut, sowie kurz und bündig auf den Punkt gebracht!
VB6 ist auch meiner Meinung nach eine grundsätzlich absolut moderne Entwicklungsumgebung:
- VB6 als auch alle generierten Apps laufen absolut stabil unter allen modernen Windows-Versionen: Windows 7 / 8 / 8.1 / 10 und zwar sowohl unter den 32 Bit- als auch den 64 Bit-Windows-Versionen (OK, die IDE hat mit den Visual Styles 2, 3 kleinere Problemchen, die sind aber nicht unlösbar und somit nicht spielentscheidend)
- VB6 kann bis zu 2 GigaByte Arbeitsspeicher (RAM) verwalten
- VB6 kann Dateien bis zu einer Größe von jeweils 2 GigaByte verwalten
- VB6 sowie alle generierten Apps sind komplett und vollständig 32 Bit. Es gibt KEINE veralteten 16 Bit-DOS-Routinen!
- wenn VB6 bzw. die generierten Apps noch 16 Bit-Anteile hätten, ließen sie sich NICHT unter einer 64 Bit-Windows-Version starten!
- VB6 hat eine absolut einfache und komfortable Schnittstelle zu den Funktionen der Win32-Api und zu ActiveX-Controls - und da gibt es jeweils 100te, wenn nicht gar 1000de
- etc., etc., etc. ...
- die VB6-Runtime (Msvbvm60.dll) ist ca 1,32 MegaByte groß (im Gegensatz zu den vielen MegaBytes der .Net-Runtime, reichen da tutto kompletto in Summe überhaupt 100 MB ???)
- auch klar: VB6 gibt es nicht als 64 Bit-Version, aber was sollte die überhaupt bringen ??? ??? ???
Also meiner Meinung ist mit VB6 zur Zeit und auf lange Sicht alles im grünen Bereich
Gruß, Stefan
Beitrag wurde zuletzt am 28.07.16 um 22:47:12 editiert. | |
| oh oh ... nein so war das nicht gemeint | | | | Autor: Blackbox | | Datum: 29.07.16 19:32 |
| Hallo,
ich fürchte man hat mich falsch gelesen.
Ich bin nicht der Meinung das VB6.0 veraltet ist,
sondern habe klipp und klar gesagt: In VB6.0 sollte
man neuere Objektmodelle nutzen, wenn diese besser
und solider arbeiten als diejenige, auf das VB6.0 als
Standard setzt und:
Das erwarte ich von einem objektorientierten Programmierer,
dass er oder sie immer das neueste Objektmodel benutzt.
Ich habe mit dem neueren Model mit keinem einzigen Wort:
VB.NET erwähnt und garantiert auch nie gemeint, sondern im Fall der Dateisuche auf das
Objektmodell: Shell ...
hat man mich jetzt verstanden? | |
| keine Panik, alles easy | | | | Autor: visualfx | | Datum: 29.07.16 20:51 |
| Hallo Blackbox,
bitte keine Panik, alles easy
Aber Dein Statement "Die Bordmittel von VB6.0 dafür sind DOS-Routinen aus längst vergangenen Tagen" hat mich ein bißchen gekitzelt, da konnte ich mir meinen Kommentar "VB6 veraltet ? Wieso ???" nicht verkneifen.
Ich bin auch NICHT gegen z. B. VB.Net oder irgendeine andere Programmiersprache. Jeder soll die Programmierumgebung benutzen, die er mag. Jede hat ihre Stärken und Schwächen. Die eine ist per Definition nicht besser oder schlechter wie die andere - und umgekehrt.
Was mir nur generell ein bißchen aufstößt, ist die "Marketing-Maschine" von Microsoft, welche jedes Jahr wieder x neue Säue durchs Dorf treibt:
DDE - COM - DCOM - MFC - MVC - DAO - ADO - OLE - ODBC - OLEDB - SQL - Win32-API - ActiveX - C - C++ - Basic - Visual Basic 4 / 5 / 6 - .Net - Name Spaces - VB.Net - C# - WinForms - ADO.Net - WPF - Silverlight - Link - Azure - . . . (hab ich noch welche vergessen? mit Sicherheit!)
Und jedesmal ist natürlich die neuste Sau angeblich wieder VIEL besser wie die Sau davor. Und jeder der mit seiner "alten" Sau glücklich und zufrieden ist, wird so ein bißchen als veraltet und altmodisch und von gestern abgestempelt.
Und das was wir doch alle mehr oder minder wollen, ist es, ein kleines Progrämmchen - oder ein größeres Programm - zu entwickeln, mit dem man etwas "sinnvolles" tun kann - weil das alles einfach Spaß macht.
In diesem Sinne
Gruß, Stefan
Beitrag wurde zuletzt am 29.07.16 um 20:54:14 editiert. | |
| Re: keine Panik, alles easy | | | | Autor: Franki | | Datum: 30.07.16 03:48 |
| Hallo Stefan,
| Zitat: | |
Und jedesmal ist natürlich die neuste Sau angeblich
wieder VIEL besser wie die Sau davor. Und jeder
der mit seiner "alten" Sau glücklich und zufrieden
ist, wird so ein bißchen als veraltet und altmodisch und von
gestern abgestempelt.
| |
Tja das nennt man Marketing. Solche Aussagen sind aber bei allen Herstellern von irgendwelchen Produkten normal. Jede neue Version eines Waschmittels wäscht weißer als weiß und sauberer als sauber. Und wenn es nicht mehr weißer geht, dann ist es halt reiner als das vorheriger usw. usw. (An der Wäsche sieht man nicht wirklich einen Unterschied)
| Zitat: | |
Und das was wir doch alle mehr oder minder wollen, ist es,
ein kleines Progrämmchen - oder ein größeres Programm - zu
entwickeln, mit dem man etwas "sinnvolles" tun kann
- weil das alles einfach Spaß macht.
| |
Richtig, aber hier kann es schon Unterschiede geben, ob das Programmieren nur Spaß machen soll oder es betriebswirtschaftliche Gründe gibt welche Programmiersprache man verwendet. Ich verwende VB6 auch teilweise noch für kommerzielle (neue) Projekte, aber durchaus auch .NET weil das in gewissen Aufgabenstellungen zwar mit VB6 auch irgendwie machbar wäre, aber mit .NET deutlich schneller und somit kostengünstiger für den Kunden ist.
Und wenn es daran geht, Objektmodelle zu verwenden die es zu VB6 Zeiten noch gar nicht gab, dann tut man sich mit VB6 alleine schwer. Es steigen zunehmend Anforderungen, dass die Software auch eine Schnittstelle zu Smartphones hat Bluetooth unterstützt werden soll, GPS verwendet werden soll usw. usw. Aber da kann VB6 alleine nicht mithalten. Man kann zwar interdisziplinär arbeiten indem man auch aus VB6 heraus auf das Framework oder APIs zugreift, aber irgendwann stellt sich die Frage, ob das mit .NET nicht doch einfacher geht.
Und ja, mehr Spaß macht VB6 es hat meiner Meinung nach auch noch Zukunft so lange es unter aktuellen und zukünftigen Windows Versionen laufen wird.
Gruß
Frank | |
| Re: oh oh ... nein so war das nicht gemeint | | | | Autor: Oggi | | Datum: 30.07.16 10:00 |
| Doch, doch man darf sagen: "VB6 ist veraltet" und neue Programmierer sollen eine andere, am Besten keine Microsoft Programmiersprache wählen, weil diese, wie wir leidvoll erfahren mussten, nur eine kurze Halbwertzeit haben.
Dass VB6 dann eben doch nicht veraltet ist, erkennt man daran, dass diese Programmiersprache noch 'allover' ist und, dass Microsoft VB6 nicht als Open Source freigibt. Der Hype wäre danach einfach zu "bombastisch" | |
| VB6 als Open Source | | | | Autor: visualfx | | Datum: 30.07.16 12:03 |
| Hallo Oggi,
stimmt! So habe ich das ja noch garnicht gesehen:
wenn Microsoft VB6 als Open Source freigeben würde, gäbe es innerhalb kürzester Zeit viele neue Versionen von VB6 mit lauter schönen neuen Möglichkeiten:
- nahtlos integrierte SQL-Datenbank mit direkter Datenbindung ohne DAO / ADO / ODBC / OLEDB / etc.
- Generieren von Apps für Windows / Linux / Mac OS X
- Generieren von nativen Apps für Windows Phone / Android / iOS
- Generieren von universellen Web-Apps für jedes Device, z. B. Rasbperry Pi
- plus all die Funktionen, welche Microsoft bei seinen neuen Tools anpreist
Aber schon klar, daran hat Microsoft kein Interesse. Microsoft will natürlich wieder die nächste Sau durchs Dorf treiben und will möglichst die ganze Entwickler-Gemeinde dazu bringen dieser neuen Sau hinterherzulaufen. Wenn man dann diese Sau eingeholt hat (sprich: sie gekauft hat, sie installiert hat, sich in Berge von Dokumentationen und neuen Klassen eingearbeitet hat), muß man ernüchtert feststellen, daß Microsoft schon wieder die nächste Sau durchs Dorf treibt . . . und das ganze Spielchen geht wieder von vorne los.
Das ganze erinnert mich ein bißchen an den griechischen König Sisyphus: der muß als Strafe der Götter eine riesige Steinkugel den Berg hochrollen. Kurz vorm Gipfel entgleitet im die Steinkugel und rollt den Berg hinunter . . . und Sisyphus muß wieder von vorne beginnen (daher kommt auch der Begriff: Sisyphus-Arbeit).
Gruß, Stefan | |
| Jeder von uns ist ein bißchen wie Sisyphus | | | | Autor: visualfx | | Datum: 30.07.16 14:25 |
| Hallo,
mal wieder ein kleiner Nachtrag (nur zur Info) - ich für meinen Teil habe nämlich irgendwie keinen "Bock" mehr auf diese Sisyphus-Arbeit, weil ich die schon x-mal mitgemacht habe:
- Basic
- Fortran
- Turbo Pascal
- Assembler
- C
- C++
- Visual Basic
- ActiveX
- VBA
- Visual C / C++
- Visual Foxpro
- SQL
- .Net (ein bißchen)
Bei jedem Punkt in der Liste oben habe ich mit der Steinkugel unten im Tal begonnen (= Wissensstand Null), habe sie den Berg hochgerollt (= Wissensstand hoch und höher, um dann produktiv eine komplette App entwickeln zu können), um dann beim nächsten Punkt in der Liste quasi wieder unten im Tal zu beginnen . . .
==>> Deshalb wünsche ich allen viel Spaß und Erfolg mit VB6 - und der wird noch lange, sehr lange anhalten <<==
Gruß, Stefan
Beitrag wurde zuletzt am 30.07.16 um 14:53:32 editiert. | |
| Microsoft ist nicht schuld | | | | Autor: Blackbox | | Datum: 30.07.16 18:26 |
| Hallo Leute,
Ihr könnt das nicht Microsoft vorwerfen. Die machen Industrie und Wirtschaft und
das ist nun mal der Gang der Dinge, dass wenn Du ein Produkt erwirbst dieses Produkt
eigentlich schon veraltet ist - aus der Sicht der Industrie, die das Produkt entwickelt.
Klar ist, dass das bei Software natürlich eine rasante Entwicklung ist. Aber kaufe
Dir einen nagelneuen 5er BMW als Auto und steigst ein und da kannst Du sicher sein, dass
gerade eben ein Erlkönig für die nächste Generation
von deinem fungelnagelneuen Model an dir vorbeigefahren ist.
So funkt eben Wirtschaft. Wir alle können uns dem nicht entziehen.
Wohnst Du in der Nähe von Stuttgart passiert Dir das Gleiche mit Mercedes und Porsche.
Bei all dem seid mal ehrlich zu dem Ganzen: Eigentlich lernt man programmieren
wirklich nur 1 Mal! Man ändert nur die Schreibweisen und ja, andere Programmiersprachen
bringen andere Programmiertechniken - aber ändern die sich so gravierend, dass die Kugel
wieder vom Gipfel zurück rollt? Nein. Es bleibt immer ein Bodensatz stehen, der sich
kontinuierlich höher entwickelt.
VB6 ist so klug programmiert, es es ständig erweiterbar ist - war meine ursprüngliche Botschaft | |
| Re: Microsoft ist doch schuld! | | | | Autor: Oggi | | Datum: 30.07.16 18:55 |
| Howdy Blackbox,
Du hast da was vergessen. Ich bin seit VB-Dos und VB1 dabei, habe brav und für MS gewinnbringend alle neuen VB-Versionen gekauft. Da darf ich doch die Weiterentwicklung meiner Programmiersprache, oder aber die sanfte Migration nach VB.Net erwarten. Ansonsten, und das ist Stand der Dinge seit VB6, gibt es von mir keine Kohle mehr.
Beitrag wurde zuletzt am 30.07.16 um 18:58:20 editiert. | |
| Re: Microsoft ist doch schuld! | | | | Autor: Franki | | Datum: 31.07.16 02:13 |
| Hallo Oggi
| Zitat: | |
Ich bin seit VB-Dos und VB1 dabei,
habe brav und für MS gewinnbringend alle neuen VB-Versionen
gekauft. | |
Ich auch, aber ich muss für meinen Teil sagen, dass ich damit auch gewinnbringend arbeiten konnte, sprich mehr Umsatz gemacht habe als mich die jeweils neuen Versionen gekostet haben.
| Zitat: | |
Da darf ich doch die Weiterentwicklung meiner
Programmiersprache, oder aber die sanfte Migration nach
VB.Net erwarten.
| |
Die Migration nach .NET gibt es ja sanft, beide VB Versionen sind gleichzeitig über Jahre verfügbar und lauffähig bis hin zur aktuellen Windows Version. Man konnte und kann immer noch sanft umsteigen. Und sogar .NET Sachen in VB6 verwenden und umgekehrt.
Ich habe den sanften Umstieg gemacht aus betriebswirtschaftlichen Gründen, aber ich bin nicht komplett umgestiegen. Manchmal ist es sinnvoller noch ein VB6 Programm zu realisieren weil es einfach schneller geht und damit kostengünstiger für den Kunden ist.
| Zitat: | |
Ansonsten, und das ist Stand der Dinge seit
VB6, gibt es von mir keine Kohle mehr. | |
Na ja, ob es Geld kostet eine .NET Version zu verwenden hängt halt davon ab was du brauchst. Grundsätzlich ist .NET ja konstenlos im Gegensatz zu den damaligen Versionen von VB6
Gruß
Frank | |
| Was geht hier ab ??? | | | | Autor: Manfred X | | Datum: 31.07.16 11:35 |
| Hallo!
Sorry, Leute - aber ich habe selten so viel Unfug gelesen, wie er hier verbreitet wird.
VB6 ist eine restlos veraltete Programmiersprache, die den Stand von Windows 98
wiederspiegelt.
Die Anwendung von DoEvents ist eine schlechte "Notlösung" für das Handling
blockierter Oberflächen bei Single-Threading-Anwendungen.
Es ist ein Schuß ins Blaue, weil man - ausser in trivialen Fällen - kaum garantieren
kann, daß nach Ausführung der Codes der Ereignisverarbeitungsroutinen, der
unterbrochene Thread wieder korrekt weiterarbeiten kann.
Wer sich ernsthaft für Multi-Threading interessiert, findet im Net-Framework
recht weit entwickelte Instrumente für das Synchronisieren von Threads.
Ich erledige mit den Klassen, die das Framework bietet, innerhalb weniger
Stunden Aufgaben - bei denen müßte in unter VB6 mühsam und mit großem Aufwand
C++-Bibliotheken erstellen und einbinden.
Kritik an Microsoft ist in vieler Hinsicht berechtigt.
Andererseits verläuft die Entwicklung in der Informatik und der diversen
Anwendungsgebiete dermaßen rasant, daß auch ein großer Konzern nicht alles
"im Griff haben" und korrekt vorhersehen kann.
Beitrag wurde zuletzt am 31.07.16 um 11:36:31 editiert. | |
| Re: Was geht hier ab ??? | | | | Autor: Oggi | | Datum: 31.07.16 13:08 |
| Manfred X schrieb:
| Zitat: | |
Die Anwendung von DoEvents ist eine schlechte
Notlösung für das Handling
blockierter Oberflächen bei Single-Threading-Anwendungen.
Es ist ein Schuß ins Blaue, weil man - ausser in trivialen
Fällen - kaum garantieren
kann, daß nach Ausführung der Codes der
Ereignisverarbeitungsroutinen, der
unterbrochene Thread wieder korrekt weiterarbeiten kann. | |
Das klingt ja ganz schrecklich  , bloß gut, dass sich das in der Praxis nicht so auswirkt 
Nein im Ernst, über DoEvents sollte vor dessen Anwendung in der Hilfe nachgelesen werden und es muss einem bewußt sein, DoEvents kann ein Programm instabil machen und zu Seiteneffekten führen. Deshalb bei der Fehlersuche immer auch DoEvents im Auge behalten. In der VB-Hilfe steht über DoEvents folgendes:
Obwohl Zeitgeber-Ereignisse die beste Lösungsmöglichkeit für die _
Hintergrundverarbeitung darstellen - insbesondere für sehr langwierige _
Aufgaben - ist die DoEvents-Funktion eine geeignete Möglichkeit, um das _
Abbrechen einer Aufgabe zuzulassen.
DoEvents-Schalter steuern die Kernroutinen des Betriebssystems. Die Steuerung _
wird an Ihre Anwendung zurückgegeben, sobald alle anderen Anwendungen in der _
Umgebung auf anstehende Ereignisse reagieren konnten. Dies bewirkt nicht, daß _
die aktuelle Anwendung den Fokus abgibt, es ermöglicht jedoch die _
Verarbeitung von Ereignissen im Hintergrund.
Diese Vorgehensweise bringt möglicherweise nicht immer die erwarteten _
Ergebnisse.
Es kann völlig problemlos sein, eine Funktion erneut aufzurufen, während sie _
die Steuerung an DoEvents abgegeben hat. Das folgende Verfahren sucht _
beispielsweise nach Primzahlen und verwendet DoEvents, um anderen Anwendung _
periodisch die Verarbeitung von Ereignissen zu erlauben. | |
| Sorry, Manfred X | | | | Autor: visualfx | | Datum: 31.07.16 14:44 |
| Hallo,
es kommt bei mir nur sehr, sehr, sehr selten vor - aber wenn ich Deinen Kommentar lese, reißt mir der Geduldsfaden.
Ich begebe mich deshalb mal auch auf Dein "allumfassendes, allwissendes, postulierendes" Niveau:
"Sorry, Manfred X - aber ich habe selten so viel Unfug gelesen, wie Du in Deinem Kommentar verbreitest.
Und zwar von Deiner zweiten Zeile bis einschließlich zu Deiner letzten Zeile."
Und bitte, bitte NICHT persönlich nehmen, es ist alles gut und im grünen Bereich
Gruß, Stefan | |
| Re: Sorry, Manfred X | | | | Autor: Oggi | | Datum: 31.07.16 15:08 |
| Howdy visualfx,
Ich verwende DoEvents jetzt schon seit einem Vierteljahrhundert und lass mich deshalb von niemanden mehr belehren, schon gar nicht wenn dieser Herr wie ein Proll hier in die Diskussion einbricht. Theorie ist eben nicht Praxis. Für mich ist dieser Thread damit zu Ende.
bis die Tage
Beitrag wurde zuletzt am 31.07.16 um 15:11:39 editiert. | |
| --- dito --- | | | | Autor: visualfx | | Datum: 31.07.16 17:16 |
| | --- dito --- | |
| nichts hinzuzufügen | | | | Autor: Blackbox | | Datum: 31.07.16 18:22 |
| | df | |
 | Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
 Einloggen | Neu registrieren |
 |
|
sevISDN 1.0 
Überwachung aller eingehender Anrufe!
Die DLL erkennt alle über die CAPI-Schnittstelle eingehenden Anrufe und teilt Ihnen sogar mit, aus welchem Ortsbereich der Anruf stammt. Weitere Highlights: Online-Rufident, Erkennung der Anrufbehandlung u.v.m. Weitere InfosTipp des Monats Neu! sevEingabe 3.0 
Einfach stark!
Ein einziges Eingabe-Control für alle benötigten Eingabetypen und -formate, inkl. Kalender-, Taschenrechner und Floskelfunktion, mehrspaltige ComboBox mit DB-Anbindung, ImageComboBox u.v.m. Weitere Infos
|
Mai 2024
Sie sind aktuell nicht angemeldet.
