@Rolf
Zeigst Du mal einen Screenshot?
Sollen die Buttons im Hauptformular liegen und verschiedene Zustände (auch aus weiteren Formularen) anzeigen (ähnlich den Ribbons)?
Kreuzbezüge innerhalb der implementations-Abschnitte sind sicherlich kein Problem. Dafür sind sie ja u.a. gedacht.
Die Frage ist, ob man überhaupt irgendwann Button-Eigenschaften (oder andere Controleigenschaften wie Visible o.ä.) auswerten sollte.
if ButtonTest.Enabled ...
ist zwar machbar, aber eine Trennung von Daten und
GUI sollte man bestenfalls dort schon umsetzen.
Für kleine, schnelle Projekte ist das kein Problem, aber für größere Projekte sollte man Daten+Geschäftslogik von der
GUI ordentlich trennen (je nach weiteren Ansprüchen und Umgebung). Die
GUI präsentiert dann nur Daten und Zustände und schiebt Änderungen, Berechnungen, speichern, Laden usw. an. Die Daten- und Geschäftslogik greift aber nie auf Eigenschaften der
GUI zu.
Man könnte also mit einer Variablen bzw. Property "TestEnabled" arbeiten, diese irgendwo speichern und laden und bei jeder Wertänderung, die Darstellung des/der zugehörigen Buttons anpassen. Useraktionen ändern wiederum dann den Propertyinhalt (wie in einer DBCheckBox z.B.).
Um die Verbindung einfach zu gestalten, gibt es unterschiedliche Herangehensweisen. Vorhandene Controls müssen dazu quasi an eine Eigenschaft gebunden werden ->
Werbung für die Konkurenz 