Nutzt .NET!

Es gibt 77 Antworten in diesem Thema. Der letzte Beitrag () ist von Samus Aran.

    peterfido schrieb:

    Dieser besitzt selbst erstellte Benutzersteuerelemente, welche quasi autark arbeiten und sich per Events im Hauptteil melden.

    Wenn diese Controls nicht wirklich in einem anderen Thread arbeiten, ist es nicht multithreaded - auch nicht, wenn sie autark arbeiten.

    lg SeriTools
    | Keine Fragen per PN oder Skype.

    Die ganze Diskusion ist doch für die Katz.
    Ich selbst habe .net angefangen ,weil schon 8 Jährige eine .Net te Oberfläche basteln können.
    Sieht manches richtig professionell aus.
    Bloß laufen tun die Programme nicht richtig oder garnicht,da der Hirnschmalz nur für das aussehen reicht, nicht aber für die Funktionen.
    Ich würde heute noch meine Steuerungen mit DOS machen,bloß wer soll die
    Teile bedienen ,denken doch alle der PC ist kaputt. ;)

    Grüße an Alle

    Dann nenne es von mir aus 'Multitasking'. Einen wirklichen Unterschied sehe ich in der Definition nicht. Es können mehrere Streams gleichzeitig abgespielt sowie das Inhaltsverzeichnis aktualisiert werden. Wie genau das intern abläuft ist mir egal, solange es sich so verhält, wie ich es geplant habe. Und das macht es.

    Die Optik meiner Programme ist eher "funktional".
    Gruß
    Peterfido

    Keine Unterstützung per PN!

    peterfido schrieb:

    Anderes Multithreading habe ich bisher nicht benötigt.

    ok ...
    Tritt aber in der realen Welt doch recht häufig auf.
    Laden einer 50MB Textdatei von einem lahmen USB Stick? Laden und skalieren eines größeren Bildes? Zugriff auf eine "entfernte" (LAN, WLAN, WAN) Ressource? Interne Berechnung/Prüfung, die länger als 3 Sekunden dauert?

    Fakt ist jedenfalls, dass Hans, Franz, Hinz und Kunz eine Multicore CPU haben (und in spätestens 2 Jahren haben auch Uschi und Bääärbel einen QuadCore). Da ist es dann ne lustige Sache, wenn die Software das auch ausnutzt. Insbesondere wenn es SO simpel ist, wie in FW 4/4.5.

    peterfido schrieb:

    Dann nenne es von mir aus 'Multitasking'. Einen wirklichen Unterschied sehe ich in der Definition nicht.

    Dann weist du anscheinend nicht wirklich was der Unterschied ist.
    Ein Event arbeitet synchron.
    Event wird getriggert von KlasseA --> KlasseB aboniiert das Event und führt eine bearbeitung aus --> Nach der Bearbeitung des Events wird der Programmablauf DIREKT nach dem triggern des Events in KlasseA vortgesetzt.

    Dabei kann man nicht wirklich von Multithreadding reden.

    Wenn da ein Benutzersteuerelement Musik abspielt und kurz vor Ende die Order bekommt die Lautstärke langsam abzusenken und gleichzeit das nächste ein anderes Lied anfängt zu spielen und dabei langsam die Lautstärke "hochschraubt" und das alles, obwohl das Inhaltsverzeichnis mitten in der Aktualisierung steckt, sind das für mich mehrere Threads gleichzeitig. Das verstehe ich unter Multithreading. Würde ich sie mehrere Tasks gleichzeitig nennen, wäre es Multitasking.

    Wenn es jetzt darum geht, dass etwas Aufwändiges von mehreren CPU-Kernen erledigt werden soll und dies dann Multithreading bedeutet, dann würde ich den langsamen USB-Stick da eher nicht mit auslesen. Eine aufwändige Berechnung könnte man dann schon eher verteilen.

    Ich rede halt von Multithreading innerhalb eines Programmes und ihr von Multithreading innerhalb eines Prozesses. Interessanterweise nutzt Windows7 auch bei VB6 Programmen mit mehreren Benutzersteuerelementen mehrere CPU-Kerne.
    Gruß
    Peterfido

    Keine Unterstützung per PN!

    peterfido schrieb:

    Mein Anwendungszweck sind aber ganz klar Tools, welches Multithreading normal nicht benötigen.

    So lange deine "Tools" keine Aktionen ausführen, die länger als 200-500 ms dauern ist das ja auch ok. Aber MS empfiehlt zb den Einsatz von asynchronen Methoden bei allen Aktionen, die länger als 15 ms dauern KÖNNTEN. Und das sind halt per se dann schon recht viele.
    Bei deinen "Beispielen" (Sound) bist du halt auf die Async Funktionalitäten beschränkt, die bereits in der Klasse, DLL whatever eingebaut wurden. Wenn du selbst was "neues" brauchst, wirds halt etwas schwieriger.

    Für mich persönlich sind jedenfalls die neuen "async" Features im FW 4.5 (bzw im Async CTP) einer der größten Meilensteine in der VB Geschichte. Das wird auch dadurch untermauert, dass MS zum ersten Mal in der Lizenz eines CTP die Verwendung in realen (kommerziellen etc) Anwendungen erlaubt. Einfach weil so viele Leute geschrien haben: HABEN WOLLEN!!!!!!


    Edit:

    VB.NET-Quellcode

    1. Imports System.Threading.Tasks
    3. Public Class Form1
    5. Private Async Sub DoSomething(ByVal s As String)
    7. Static TaskListe As New List(Of String)
    8. If TaskListe.Contains(s) Then
    9. MessageBox.Show("Already processing")
    10. Exit Sub
    11. Else
    12. TaskListe.Add(s)
    13. End If
    15. ' simulate action
    16. ListBox1.Items.Add("Processing " & s)
    17. Await TaskEx.Delay(5000)
    18. ListBox1.Items.Add("Done with " & s)
    20. TaskListe.Remove(s)
    22. End Sub
    24. Private Sub Button2_Click(sender As System.Object, e As System.EventArgs) Handles Button2.Click
    26. If TextBox1.Text.Length > 0 Then
    27. DoSomething(TextBox1.Text)
    28. End If
    30. End Sub
    31. End Class


    Das macht doch einfach Spaß, so einen Code zu schreiben und zu sehen ...

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „picoflop“ ()

    Hallo,

    es ist doch wie Lama es anfangs geschrieben hat.

    Bestehende VB6 Projekte wird man nicht auf dotNet portieren, des zum Teil großen Aufwands wegen.
    Neues, sollte man dagegen in dotNet coden.

    Gruss

    mikeb69

    mikeb69 schrieb:

    Bestehende VB6 Projekte wird man nicht auf dotNet portieren, des zum Teil großen Aufwands wegen.

    a) hast du Recht und b) nicht zwangsläufig ;)
    WENN man in einem bestehenden Projekt an eine Grenze stößt, kann es sich durchaus anbieten, "kritische" Teile in eine COM kompatible VB.Net DLL auszulagern, wo man dann halt nur genau das "optimiert", was mit VB.classic ansonsten nicht oder nur schwer lösbar wäre.
    Außerdem sollte man nicht vergessen, dass viele Programme sich deutlich eindämpfen lassen, wenn man sie mit .Net neu schreibt. Man muss ja nur mal die vielen "VB (5/6) Tipps" (Codeschnipsel) anschauen, die hier so gerne als "Lösung" für ein Problem in .Net gepostet werden. Wie oft wird ein 10-15 Zeiler da zu nem Einzeiler ... Aber es ist schon richtig, dass das nur bis zu einer gewissen Komplexizität Sinn macht!

    Hallo picoflop,

    ein Zustimmung von dir ist mehr Wert als jeder Ritterschlag der englischen Königin.
    Ich fühl mich gerade so Leicht, fast als wenn ich auf meinem Stuhl schweben würde.

    Gruss

    mikeb69

    LOL

    Ich war "lange" (erst ab 2000) auch ein VB6 Adept und habe mich mit dem Wechsel anfangs schwer getan, weil es halt teilweise komplett andere Denkstrukturen voraussetzt und man im Kopf immer erstmal "übersetzen" muss. Vlt am besten vergleichbar mit der Euro-Einführung, wo man anfangs halt auch immer erstmal nach DM "rückübersetzt" hat.

    Hallo picoflop,

    ging mir ähnlich.
    Hab mit Basic auf dem C64 begonnen, dann Amiga 500 wieder Basic.
    Nach langer Pause dann VB5 und 6 und schliesslich VB.NET.

    Hier häng ich aber im Framework 2 fest, da mir das reintrichtern der jährlichen Neuerungen zu aufwändig ist.

    Gruss

    mikeb69

    Hey Zusammen,

    habe vor kurzem begonnen .Net zu verwenden.
    Mein einziges und wahrscheinlich immer bestehendes Problem wird sein,
    dass einige die FW´s nicht auf ihrem Desktop/Laptop etc. haben.

    Gestern neuen Laptop gekauft fürs Fraule und gleich mal einige Programme durchlaufen lassen wollen die ich geschrieben habe.
    Geht nichts... Internet bekommen wir leider erst nächten Woche in der neuen Wohnung und bis dahin heißt es wohl:
    Neuer Laptop muss warten :( so ein tolles Ding steht nu nur rum...

    Die FW werden uns auch in Zukunft zu schaffen machen.
    Und was den Meinungskrieg hier betrifft, bitte ich euch seit einfach nett zu einander. Der ein oder andere wird schon merken, wenn er umsteigen muss auf eine andere Sprache,
    das ist noch lang kein Grund hier einen Zickenterror zu veranstalten ;)

    Grüßle Marco

    mikeb69 schrieb:

    da mir das reintrichtern der jährlichen Neuerungen zu aufwändig ist.

    Ich schau immer in die "whats new" Seite zum jeweiligen FW rein und acker mich dann erstmal 1-2 Stunden durch, um die wichtigsten Änderungen mitzubekommen. Dann konzentrier ich mich auf die für mich interessanten Sachen und leg die anderen auf den "wenn mans mal braucht" Stapel, der nur geöffnet wird, wenn ein "war da nicht was neues??" durch den Schädel zischt.

    MarcoIT:
    Die FW werden uns auch in Zukunft zu schaffen machen.

    Warum? Ein per Microsoft Update (inkl. "opionaler" Updates) auf dem aktuellen Stand gehaltenes Windows, sollte bis runter zu XP keine Probleme machen. Und die Anzahl der W2K Nutzer liegt mW (zb Forrester Research) liegt derzeit bei < 0.5%.

    picoflop schrieb:


    Warum? Ein per Microsoft Update (inkl. "opionaler" Updates) auf dem aktuellen Stand gehaltenes Windows, sollte bis runter zu XP keine Probleme machen. Und die Anzahl der W2K Nutzer liegt mW (zb Forrester Research) liegt derzeit bei < 0.5%.


    Hast an sich ja Recht aber nehmen wir das Beispiel von gestern:

    Gestern wollte ich mein Zeiterfassungsprogramm bei meinem Kollegen auf seinem Laptop den er seit mindestens 3 Jahren hat mal testen.
    Fazit: Er hatte kein FW drauf :-/
    Nur weil sehr viele User Windows verwenden, heißt das noch lange nicht das sie die Updates machen. Wir als Fachinformatiker gehen davon eventuell immer aus! Aber damit rechnen, dass jemand mal kein FW hat müssen wir auch!

    Grüßle Marco

    MarcoIT schrieb:

    Fazit: Er hatte kein FW drauf :-/

    Und?

    Ich wollte mal ein programm auf nem PC testen und da war kein Windows drauf!
    Ich wollte auch mal eine Datenbankanwendung testen - da war der falsche MDAC drauf!
    Ich wollte auch mal eine externe DLL verwenden - die war nicht drauf!

    Übrigens kann man sich das .Net FW auch als Redistributable runterladen und auf CD brennen -> Problem gelöst!
    techdreams.org/microsoft/downl…oft-servers/1845-20090314

Facebook
Telefonspende