XProfan

Du könntest die Menuitem-Struktur ( [...]

) auslesen aber das sollte im Normalfall
garnicht notwendig sein da Dein Prozess das Häkchen ja erst setzt und daher wissen
müsste ob es gesetzt ist oder nicht. Ich würde also empfehlen den Status einfach
in einer Variable zu speichern statt komplizierter das OS zu befragen ob ein Häkchen
gesetzt ist.

XProfan X2
Win7 Enterprise, SP1, Xeon X5670 @ 2.93GHz

Andreas
Koch

Bis jetzt bin ich auch immer deiner Empfehlung gefolgt und habe die Info in einer Variable gespeichert. Inzwischen bin ich nur auf dem Dampfer, Variablen nach Möglichkeit zwecks Übersichtlichkeit einzusparen und hatte auf eine einfache Lösung gehofft. Wenns die nicht gibt, muss ich wohl oder übel so weitermachen wie bisher.
Jedenfalls danke für die Hilfe.

Die Computer haben heutzutage so viel Speicher, dass Variableneinsparen dann
auf gar keinen Fall sinn macht, wenn es das Programm verlangsamen würde.
Oftmals ist sogar "doppelte Buchführung" sinnvoll nur um ein Fünkchen mehr
Geschwindigkeit zu erlangen. So verfährt man besonders auch bei Datenbanken
wenn sie dann doch etwas größer angedacht sind.

XProfan X2
Win7 Enterprise, SP1, Xeon X5670 @ 2.93GHz

Andreas
Koch

Mein Problem ist, dass ich den Quellcode möglichst lesbar und übersichtlich machen muss. Im Idealfall nachvollzieh und änderbar für jemanden der noch nie mit XProfan zu tun hatte.(in einem gewissen Rahmen) Gewisse Dinge kann man von außen über ini-Dateien und Excel steuern, aber eben nicht alles. Deshalb so wenig Variablen wie geht.

Ich wäre nicht sicher, ob "gute Lesbarkeit" gleichzusetzen ist mit "möglichst wenig
Variablen nutzen". Wenn der Code gut verständlich sein soll dann sind aussagekräftige
Variablennamen oft hilfreicher als das Fehlen von Variablen.

XProfan X2
Win7 Enterprise, SP1, Xeon X5670 @ 2.93GHz

Andreas
Koch

Das ist korrekt. Oberstes Gebot für Variablen sind sprechende Namen. Problematisch wirds, wenn man mehrere Dutzend verschiedene Hilfsarrays, Variablen etc. hat und nach einem Monat selbst nicht mehr weiß, was jetzt genau die Funktion davon war. Manchmal würde ich am liebsten alles noch mal neu schreiben und vernünftig aufbauen. Das ist eben das Problem, wenn man beim Programm schreiben ständig dazulernt.
Das mit dem Menü wäre eben gutes Einsparpotential gewesen, ein Befehl Getcheckmenustate oder so wäre mindestens genauso gut wie jede Variable gewesen. Muss aber nicht unbedingt sein, ich habe noch genug andere Sachen zum Verbessern.

Das mit Getcheckmenustate kann wiederum auch ein gutes "Gegenbeispiel" liefern.

Wenn es beispielsweise eine Option im Programm gibt namens option.noConfirmOnExit&
dann ist es vermutlich lesbarer wenn man if option.noConfirmOnExit& schreibt als
if Getcheckmenustate(300). Primär ist es ja das Flag option.noConfirmOnExit& nach
dem der Programmablauf sich richtet und dieses Flag setzt das Häkchen.

Natürlich könnte man auch eine Konstante menuItems.options.noConfirmOnExit& mit
z.B. 300 füllen und dann Getcheckmenustate(menuItems.options.noConfirmOnExit&)
abfragen aber dies wäre langsamer als if option.noConfirmOnExit&.