PureBoard

Vera hat geschrieben:@ ts-soft
Danke für den 1.Tip - aber 35bucks sind indiskutable

Dann die IconCache db suchen, löschen und Neustart, kostet nur Zeit

@Kai: Dir fehlen die Kommentare. Und was soll die Speicherverschwendung? Ich muss doch eine Variable nicht nochmal extra kopieren, damit ich sie abfragen kann. Und ich muss auch nicht EventWindow() bei jedem Schleifendurchlauf abfragen, sondern nur wenn es nötig ist.

Ich lass mal den Anfang weg, der passt so... @Mok: Hast du den PC jemals von innen sauber gemacht? Wenn der so ein Jahr alt ist, dürfte er schon ne schöne Staubschicht im CPU-Kühler haben. Ich empfehle Pfeifenreiniger um in die Lamellen reinzukommen. Und wenn das auch nicht hilft, gibt es z.B. von Zalman schöne CPU-Kühler, die leise und effizient sind. Ideal mit Arctic Ceramique.

@Kat
es ist immer eine beschissene Idee, den Rückgabewert direkt ins Select zu packen und nicht in eine Variable.
zum Beispiel musst du extrem auf die Reihenfolge achten, wenn du später EventGadget oder EventWindow abfragst.
wenn du diese von Anfang an in eine Variable packst, hast du keine Malesse irgendwo,
und auf die vier oder acht Byte scheißt doch der Hund.

Also mit Rückgabewert direkt im Select hatte ich noch keinerlei Probleme. Und zu der Zeit, als Programme noch mit 640k RAM auskommen mussten, war diese Art der Programmierung standard. Ich kann mir nicht vorstellen, dass sich seither was geändert haben soll..

In welchem Szenario kann es denn ein Problem geben, wenn ich diese Art der Programmierung verwende?

Vergiss es einfach, das ist weder eine beschissene Idee, noch sonst irgendwie gefährlich.

Nur weil es manche anders lieber haben, muss ja nicht jeder das genauso machen...

wenn man EventGadget erst später prüft, darf man vorher keine aktion vorgenommen haben die ein Event erzeugt.
hatten wir letztens hier ne Frage, warum das falsche Gadget zurückgeliefert wird, weil vorher ein SetGadgetText durchgeführt wurde.

wenn man ganz am Anfang alle Rückgabewerte in Dummies packt, kann sowas nicht passieren.

Kaeru Gaman hat geschrieben:wenn man EventGadget erst später prüft, darf man vorher keine aktion vorgenommen haben die ein Event erzeugt.
hatten wir letztens hier ne Frage, warum das falsche Gadget zurückgeliefert wird, weil vorher ein SetGadgetText durchgeführt wurde.

wenn man ganz am Anfang alle Rückgabewerte in Dummies packt, kann sowas nicht passieren.

Wenn man ein SetGadgetText während eines Events ausführt kann da nichts passieren. Nur wenn
SetGadgetText im Eventloop ohne Ereignis ausgeführt wird, dann trifft Deine Aussage zu, aber der
Code ist ja dann auch Fehlerhaft.
Wahrscheinlich beziehst Du Dich auf einem ehemaligen Bug in einer Beta, der sollte nicht mehr existieren.

Gruß
Thomas

Ich denke er meinte diesen Bug hier.
Das war im übrigen ein ganz eindeutiger Bug, das meiste was da so argumentiert wurde war ziemlich an den Haaren herbeigezogen und würde das ganze Event-handling von PB ad absurdum führen.

achja... danke fürs wiederfinden.

nadenn, wenn es ein Bug war und der gefixt wurde, dann ist es nur noch eine Frage des sauberen Stils.

trotzdem widerspreche ich leidenschaftlich dieser Aussage:

was soll die Speicherverschwendung? Ich muss doch eine Variable nicht nochmal extra kopieren, damit ich sie abfragen kann. Und ich muss auch nicht EventWindow() bei jedem Schleifendurchlauf abfragen, sondern nur wenn es nötig ist.

anständige Container zu benutzen ist keine Speicherverschwendung, das ist sauberes Coding.
man kann gerne der Meinung sein, dass man es selber nicht braucht, aber anleiten sollte man zu sauberem Coding.

ein Anfänger könnte zum Beispiel ein WaitWindowEvent() ins Select packen und eines ins Until,
dann steht er mit zwei Eventabfragen da und wundert sich warum es nicht sauber funktioniert.
wenn man ihm gleich beibringt, das Event in einen Container zu packen,
wird er genau diesen im Until abfragen und keinen zweites Event aus der Queue holen.

abgesehen davon dass heutzutage doch sowieso blockweise speicher zugewiesen wird, also vier byte zu sparen zu wollen geht überhaupt nicht.