Grundsätzliche Frage zur Programmstruktur

[ts-soft]

Vielleicht guckt sich mal einer den Source von Edel an?
Dann könntet ihr euch so manchen blöden Kommentar sparen.
Die eigentliche Schleife ist nicht in der Prodecure, ausserdem hat sie einen
optionalen Parameter für Timeout.

Irgendwelche Gadget mit Daten füllen oder dynamsisch erstellen muß man
auch während des Programmablaufs, das geht in Threads überhaupt nicht,
es sei denn das Hauptfenster wurde auch in diesem Thread erstellt.

Hab aber keine Lust mehr darauf einzugehen, ist mir Bockwurscht ob ihr das
schnallt oder nicht, ich finde die Lösung Genial, sicher ist das aber
auch Situationsabhängig.

[ZeHa]

Das mit dem "Datenbefüllen", da gebe ich Dir Recht, ist aber meiner Meinung nach eher eine Art Sonderfall (weil's nicht in 'nem Thread funktioniert - wie Du schreibst. Wußte ich zwar nicht aber wenn's so ist, okay). Vor allem auch weil es sich hier tatsächlich auch um eine Schleife handelt, bei der man das so bequem einbauen kann.

Dennoch gibt es zig andere Dinge, bei denen so etwas nicht empfehlenswert ist (wenn im Hintergrund irgendwelche komplexen Berechnungen oder Grafikarbeiten erledigt werden), und in Deinem letzten Beitrag kam es leider so rüber als wäre das generell eine gute Idee.

Daher muß sowas schon eher als Sonderfall gekennzeichnet werden (bei dem für Anfänger zusätzlich Vorsicht geboten ist!*), und nicht als allgemeingültige Lösung.


* stellt euch vor einer macht trotzdem was in einem Thread, und ruft dort parallel zur Hauptschleife den EventLoop auf, weil er denkt, daß das cool ist - ziemlich ungemütlich. Daher muß das dann auch anfängertauglich beschrieben werden

[Kaeru Gaman]

dazu kommt noch - wie stuft man die abhängigkeiten?

also, wenn ich zig funktionen von meinem eventhandling* aus ansteuere,
- wie eigentlich üblich, denn dort frage ich ja alle gadgets ab,
wie steuere ich die von dieser Proc aus an?
(*Handling, denn es ist ja ausdrücklich KEIN Loop)

zig aufrufe von anderen Procs?
dann existiert der "mal eben schnell events checken"-vorteil aber nicht mehr,
weil ich dann ja doch wieder ewig brauche, bis ich IN die handling-proc zurückkehre,
und dann AUS ihr zurückkehre...

oder außerhalb, um den vorteil der proc zu erhalten?
dann brauche ich aber nen sehr kryptischen Rückgabewert,
den ich dann WIEDER mit nem ellenlangen Select-Case aufarbeiten muss.

[ts-soft]

Anfänger sollten IMHO keine Threads verwenden. Für das sinnvolle und
sichere Anwenden eines Threads hab ich hier im Board wirklich nur sehr
selten ein gutes Beispiel gesehen, ich glaub ein Posting von HeXor und
vielleicht noch 2 weitere, der Rest war nur murks, bzw. einfach nur unsicher
und unnötig.

Threads werden als Job für etwas genutzt, haben im allgemeinen keine
Schleife drumrum, sind kein Timerersatz usw.
Die führen etwas aus und beenden sich.
Sicher gibts auch andere Einsatzzwecke, aber ist immer mit Vorsicht zu
genießen, ist nunmal Fehlerquelle Nr. 1.

// edit
Kaeru du schreibst unlogischen Murks
Vielleicht mal den Code endlich getestet und verstanden, so schwer ist
das nicht

[Kaeru Gaman]

also den ersten Fall mal angenommen...
> zig aufrufe von anderen Procs?
jetzt reagiere ich auf ein Gadget, indem ich ein befüllen eines anderen Gadgets starte,
und in dieser routine rufe ich wieder mehrfach mein Eventhandling auf...

yo, dann muss ich aber echt aufpassen und wissen was ich tu, um nicht in einer paradoxen rekursivität zu landen.


*nochmal auf die Überschrift des Subforums deutet*
also, wie ZeHa sagte, nur bedingt Anfängertauglich,
gewiss nur mit sehr genauer Beschreibung überhaupt für Anfänger begreifbar,
und keinesfalls einfach nur hingeworfen und "wer's anders macht is doof"

[Little John]

ist mir Bockwurscht

Aber ich bin das Schaschlik!

aber ist immer mit Vorsicht zu genießen, ist nunmal Fehlerquelle Nr. 1.

Es gibt sogar Programmiersprachen, die aus Sicherheitsgründen überhaupt keine Threads unterstützen. Ich finde auch, dass es keine allgemeine Lösung für Anfänger oder etwas Fortgeschrittenere ist zu sagen: "Dann verlagere dies und das in einen Thread."

Gruß, Little John

[ts-soft]

> yo, dann muss ich aber echt aufpassen und wissen was ich tu, um nicht in einer paradoxen rekursivität zu landen.
Bei einem sauber programmiertem Fenster garnicht möglich. Es sollten
natürlich im Fenster nur die Dinge angeboten werden, die möglich, bzw.
einen Sinn haben. Das ist aber ein Grundsatz der Windows-Programmierung.

Leider halten sich da viele nicht dran, bieten einem das Einfügen an, obwohl
die Zwischenablage leer ist usw.

Aber macht was ihr möchtet, ich mache es auch so, wie ich es möchte.
Ich kann mich bei Edel für den Tipp nur bedanken, war der beste seit
Monaten, den ich hier lesen durfte.

[HeX0R]

Ich kann mich bei Edel für den Tipp nur bedanken, war der beste seit
Monaten, den ich hier lesen durfte.

+1

[mk-soft]

Ich komme ohne Threads bei meinen Applikationen gar nicht aus.
Wäre fatal wenn Windows meine Anwendung blokiert nur weil der User das Menu öffnet und es so stehen lasst.

Ist aber abhängig von der Anwendung.

[vomDorf]

Hallo,
diese 5 Seiten Diskussion zeigen meiner Meinung nach das ganze Dilemma einer fast rein internetbasierten Programmiersprache wie Purebasic.
Möchte das an einigen Bsp. Erklären:
Meine ersten Programmiererfahrungen erfuhr ich mit Visual Basic, speziell in Excel.
Kaufte mir damals ein Buch vom bekannten Autor B. H. und erfreute mich der tollen Ergebnisse. Mit Hilfe dieses Buches war es mir möglich recht schnell (relativ) eigene Problemstellungen umzusetzen.
Dann kam, wie bestimmt auch bei vielen hier, eine Microsoft Antihaltung bei mir auf. In vielen Diskussionen vertrat ich das Argument: es gibt doch Alternativen, wir müssen Microsoft nicht noch reicher machen. Es gibt als Betriebssystem Linux, es gibt OpenOffice; schimpft nicht auf Microsoft, sondern benutzt einfach die Alternativen.
Und so versuchte ich meine Programme in OpenOffice Basic zu realisieren.
Und da wird’s für einen Anfänger echt schwierig.
Und jetzt zurück zu Pure Basic. Mein Vorschlag ist, es müssten sich eine Handvoll PureBasic Profis und eine Handvoll Anfänger zusammentun und jesweils ein ca. 300 Seiten-Buch speziell für Spiele-Programmierung und ein Buch speziell für Fenster-Applikationen schreiben (auf deutsch) wo der grundsätzliche Programmaufbau und solche Aussagen wie hier erläutert werden. Die Kritik von Kaeru ist hier durchaus berechtigt
Der enorme Erfolg v. Microsoft u. Co. ist und wird durch die Rundumversorgung mit jeder Menge Literatur, VHS-Kursen, Business-Kursen usw. gefestigt denke ich.
Ich glaube an PureBasic ...