Office: (Office 2010) Buttonrahmenfarbe

\@Maxel:

läßt sich aber leider nicht immer machen.

Form_Current wird ja nur dann ausgelöst, wenn sich der aktuelle DS ändert und zum anderen ist eine Prüfung, ob sich ein Zustand geändert hat und damit eine Aktualisierung überhaupt notwendig wird, nicht der Rede Wert. Solch eine Prüfungen setze ich allerdings mal voraus.

Mir ging es auch mehr um das Prinzip, daß man immer versuchen sollte, den IST-Zustand anzuzeigen, anstatt den SOLL(te)-Zustand. Im technischen Bereich kann dieser kleine, aber feine Unterschied, wichtig sein. Im Zweifelsfall rasselt man mit seinem schönen Design sonst durch die Qualitätsprüfung!

Einfache praktisches Beispiele:
Das Prinzip gilt auch beim Entwurf von elektronischen Baugruppen. Stell dir ein Netzteil vor, daß anstatt der IST-Ausgangsspannung die SOLL-Ausgangsspannung anzeigt - fatal und undenkbar!
Oder in der Logistik: es wird immer angezeigt, daß ein Container an dem Platz steht und nicht, daß er dort stehen sollte. Wenn der Container dort stehen sollte, aber nicht dort steht, wo ist er dann? Geht gar nicht!

Nur mal so ...

Da der Aufwand so minimal ist, warum nicht gleich richtig machen?

Gruß Ulrich

 

\@Ulrich: Verwende in Deiner Überlegung mal zusätzlich Unterformulare. Ich habe da ähnlich Maxel schon Feuerwerke an Current erlebt, die mich vor allem Zurückhaltung bei diesem Ereignis gelehrt haben. Wegen solcher einfachen Maßnahmen soll nicht ein Flipper entstehen, sondern eine schöne statische und erwartete Reaktion zeigen.

Man muss schon einen gesunden Kompromiss finden zwischen einer vollumfänglichen Prüfung, weil die Programmierung und der Benutzer nebenbei machen was sie wollen, und der Standardisierung von Bedingungen und Handlungen, der die Benutzerführung folgt.
Wenn die Benutzerführung in der programmierten Oberfläche so überzeugend ist, dass sie nicht verlassen wird, kann und wird man durchaus auf ein Maß an Prüfungen verzichten, das denkbar ist.

Auch ein Beispiel: Wenn ich in eine Kiste mit M10-Muttern greife, hallte ich dann nur ebensolche Muttern in der Hand, und M10 ist dann auch genau das genannte Gewinde und keine andere Größe oder eine Zollvariante.

 

\@Eberhard:
Natürlich wird das Current Ereignis sehr oft ausgelöst, aber wie gesagt, die Prüfung, ob sich an FilterOn und Filter = "" etwas verändert hat, ist minimal.

Dein Beispiel hingt ein bißchen:
Du greifst mit deiner Hand in die Kiste und erwartest, daß anschließend ein paar M10er in deiner Hand sind. Das ist der SOLL-Zustand. Ob du tatsächlich welche in der Hand hältst oder nicht, z.B.weil der Behälter schon leer war, dieses zeigt der IST-Zustand an.

Wie gesagt, in Steuersanlagen ist das unerlässlich, ob das hier auch so ist, kann ich nicht beurteilen. War ja auch nur einen Gelegenheit, auf diese Problematik mal hinzuweisen.

Gruß Ulrich

 

Primär erwarte ich, dass da NUR M10er drin sind, oder eben nichts.
Standardisierung schafft Vertrauen. Man müsste ja sonst bei einem Buttonklick auch überprüfen, ob der wirklich gedrückt wurde oder man nur einer optischen Täuschung unterliegt. Sprich, das Prüfen muss seine Grenzen haben, sonst kommt man nicht mehr zum Handeln.

Zum Thema: Jetzt sind es schon drei Buttons mit gegenseitigen Abhängigkeiten geworden. Da ist die Möglichkeit von unbeherrschter Komplexität und somit Fehlern schon zugrunde gelegt.
Man würde wohl besser eine Optionsgruppe verwenden, diese kann auch anderes als Radiobuttuns verwenden. Die OG gibt nur genau einen Wert zurück. Diesen kann man auswerten.
Daneben müsste man geeignet vermeiden/verhindern, dass die Filter auf einem zweiten Weg beeinflusst werden, z.B. weil einer parallel einen Menübetrieb verwenden.

 

\@Eberhard:

Doch, in Steuerungsanlagen wird immer zu 100% geprüft, sonst könnte erheblicher Schaden entstehen - mußte ich auch erst lernen. In deinem Beispiel würde einfach der IST-Zustand über eine Wägung ermittelt werden können und das wird auch so per Sensorabfrage gemacht.

Gruß Ulrich

 

Jetzt müsste man nur prüfen, ob man sich in einer Steuerungsanlage befindet oder in einem Einzelnutzer-FE in einem Formular, wo man schlicht filtert, um etwas zu erledigen, und sich dabei eine Visualisierung schafft, was man gerade veranlasst hat.

Wenn man einen Hühnerstall baut, muss man sicher nicht die Standards für Statik und Brandschutz für einen Flughafen anwenden, aber man könnte es.

 

Nun ihr Beiden, was sollte ich nun aus den letzten Beiträgen für mich herauslesen?
Sind die Codes aus #12 so nicht brauchbar?
Okay, im Prinzip kann man ja alles irgendwie vergolden, klar. Die besten Steaks kann man totgrillen.
Eigentlich, ganz ehrlich, es verunsichert den User mehr als es hilft wenn die Experten sich vertiefen.
-
Btw. wenn wir schon alles "Gold" haben möchten dann hätte ich doch noch eine Frage zum Thema:
Standard Schaltflächen haben ja von Haus aus einen Rahmen, der ist zwar kaum zu sehen aber doch vorhanden.
Was wäre denn anstelle Black, Red usw. die Farbe "transparent" ??
Oder besser gesagt die Standardfarbe?
Im Format steht ja nur Akzent1.
Dann würde ich das BLACK oder WHITE in den Codes noch ändern wollen.*Smilie

Aber.....so wie es jetzt ist, ist es schon mal sehr gut.
Und....das ich zum AUS oder EIN nicht das Ribbon verwende versteht sich von selbst.

 

Hallo,

natürlich funktioniert der Code aus #12. Es ging in der Diskussion nur darum, ob ein anderes Event für die Visualisierung des Filterzustandes nicht besser geeignet wäre.

Wenn du für deine Buttons "Design verwenden" auf ja stehen hast, kannst du im Formularentwurfstool->Format die Buttons entsprechend deinen Wünschen designen. Die "Farbe" Transparenz bewirkt, daß der Rahmen nicht sichtbar ist. Die Farbe "Akzent1" ist eine Designfarbe und weist auf einen Eintrag in den Designeinstellungen hin.

Siehe: https://access-basics.de/index.php/D...relemente.html

Ulrich

 

Hallo Ulrich,
meine Buttons stehen in der Tat auf "Design ja".
Setze ich unter den Formateinstellungen den "AT" Rahmen auf transparent, wird der Code
ausser Kraft gesetzt. Der Rahmen wird nicht mehr "grün".
Was ich meinte ist aber klar oder?
Mit Hilfe der o.g. Codes werden die Rahmen der Buttons "AT" und "DEU" beim anklicken grün.
Das ist gewollt.
Anstelle BorderColor =vbBlack hatte ich White eingesetzt. Das bewirkt, wenn die beiden
Button off geklickt werden sind die Rahmen danach weiß und somit anders als alle übrigen die ich
sonst noch verwende. Die haben nicht wirklich einen Rahmen, standardmäßig.
Anscheinend sind diese "Transparent" ??
Oder wie nennt sich dieser "Zustand" ??
Darüber konnte ich nichts finden. Alle möglichen Farbcodes fand ich ja.
Ich hoffe ich konnte erklären was ich meine, ohne Screens zu posten.
Gruss

 

Anstelle von vbBlack wie in #12 teste mal, die Farbe des Bereichs zu setzen, in dem sich der Button befindet. Dann sollte der Transparent-Effekt vorgetäuscht werden können.

 

Ok,
dazu müsste ich aber den Codenamen der Farbe vom Bereich wissen.
Habe auch versucht die Zeilen mit vbWhite komplett aus dem
Code zu nehmen.
Result= Löse ich die Filter auf sind die Borderfarben schwarz.

Ebenso hab ich versucht mit dem Namen vblightblue, geht nicht, wird auch schwarz.
vbLightblue wird nicht erkannt.
Quelle ist hier:

PHP:

         https://www.farb-tabelle.de/de/farbtabelle.htm


 

Nichts leichter als das, nämlich den festzustellen.

In welchem Bereich des Formulars liegen die Buttons - Formularkopf, Detailbereich, Formularfuß?

Die Farbe des Bereichs lässt sich beispielsweise so ermitteln:

A) Im Direktbereich eines Moduls Deines Formulars:
Code:

B) Im Ereignis Beim Laden Deines Formulars:
Code:

C) Als Steuerelement eines Textfeldes Deines Formulars:
Code:

In jedem Fall wirst Du eine Zahl wie z. B. -2147483633 (hier: Standard-Grau) als Ergebnis erhalten.

Diesen Wert weist Du im Code #12 anstelle von vbBlack zu.

 

Hallo,

Wenn der Rahmen auf transparent gesetzt ist, kannst du die Farbe einstellen wie du möchtest, der Rahmen bleibt transparent.

Also die Idee mit dem Transparent war, die Rahmenfarbe im Designer einmalig z.B. auf grün oder was auch immer, einzustellen. Dann "tooglest" du nur noch mit der Rahmenart zwischen transparant (unsichtbar) = 0 und durchgezogen = 1. So brauchst du dir über den Formularhintergrund keine Gedanken mehr machen.
Siehe auch mal in der Hilfe unter Commandbutton.Borderstyle nach.

Der Code bräuchte dann keine Farbinformationen mehr: (Air Code)
Code:

Die Grundeinstellungen bei Form_Open habe ich mir jetzt gespart.

Gruß Ulrich

 

Die Codes habe ich nun wie #28 ersetzt.
Ergebnis:
Beim Start sind beide Rahmen (DEU+AT) grün.
Aktiviere ich DEU, bleibt der grün, AT ist transparent.
Aktiviere ich AT, wird er grün, DEU wird transparent.
Erst das drücken des LÖSCH Button (FilterAus) bewirkt das beide Rahmen transparent werden.
Es kommt ein Debug Fehler "SetFilter fltAt" Function nicht bekannt.

Nun, das die Rahmen jetzt BEIDE beim Start schön grün sind ist ja auch nicht richtig.
Die Rahmen sollen nur grün sein wenn der Filter aktiv ist.

Das war dann aber vorher besser, sorry. Oder was könnte mein Fehler sein?

Btw./OT. Sehr nett das ihr euch solche Arbeit macht.
Ich habe inzwischen einiges lernen können aus euren Hinweisen.

 

Hallo Prof.Adv,

sorry, setFilter ist ein Überbleibsel und kann entfernt werden.

In Form_Open gehört natürlich noch eine Initialisierungsroutine, welche alle Button mit der gewünschten Voreinstellung einrichtet. Hatte ich aber darauf hingewiesen und das Prinzip ist ja jetzt bekannt.

Ulrich