Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Hilfe: Tabs im Menüband einblenden

Begonnen von KrummiTill, November 11, 2024, 21:51:10

⏪ vorheriges - nächstes ⏩

Knobbi38

#15
Führt denn der Aufruf von "gobjRibbon.Invalidate" dazu, daß die Callback Routine "GetVisible" neu aufgerufen wird? Ich hätte jetzt erwartet, daß nur das bestimmte Control zurückgesetzt wird:
https://learn.microsoft.com/en-us/office/vba/api/office.iribbonui.invalidatecontrol

Wenn dem so ist, dann mußt du natürlich auch noch deine Routine "GetVisible" ein wenig umschreiben und die Fehler korrigieren. Deine Deklaration der Callback-Routine passt nicht, es ist keine Funktion sondern eine Sub und der Rückgabewert wird byref zurückgegeben, nicht als Returncode.

Siehe hier:
https://www.accessribbon.de/index.php?Access_-_Ribbons:Callbacks:getVisible

Bitsqueezer

Hallo,

wenn Du die Callback-Prozedur nun "GetVisible" nennst, muß sie natürlich auch in XML so genannt werden. Dort gibst Du ja mit "getVisible=" den Namen dieser Prozedur an.

Wenn Du "visible" als ByRef-Parameter in der Prozedur hast, hilft es Dir nicht, wenn Du "GetVisible = True" schreibst. Ribbon Callbacks sind keine Funktionen, sondern Prozeduren (Subs). Der Rückgabewert ist kein Rückgabewert der Funktion, Callbacks bekommen ihren Rückgabewert über den als "ByRef" definierten Parameter zurück, hier also "visible". Entsprechend mußt Du auch "visible = True" setzen, wenn etwas sichtbar werden soll.
Da Du den Wert nicht veränderst, bleibt visible = False und somit wird alles unsichtbar, was diese Prozedur verwendet (wenn es denn dann eine sein wird).

Du solltest Dich einfach an das halten, was Gunter Avenius in seinen Beispielen gezeigt hat, hier steht doch ein ganz simples Beispiel:
https://www.accessribbon.de/index.php?Access_-_Ribbons:Callbacks:getVisible

Invalidate aktualisiert das gesamte Ribbon, das heißt, es werden grundsätzlich ALLE Callbacks aufgerufen, die in Deinem XML definiert sind. Da Du hier den Namen in VBA, aber nicht in XML geändert hast, kommt es zu der Fehlermeldung.

InvalidateControl macht das für ein spezifisches Control, hatte ich in der Vergangenheit bisweilen Probleme mit, deswegen nehme ich nur noch Invalidate. Die Callbacks sollten dann natürlich keine stundenlangen Ausführungszeiten haben.

Statt mühsam das Recordset abzufragen, kannst Du auch einfach ein DCount verwenden auf Deine Tabelle "tbl_Benutzer" und dort die WHERE-Kriterien angeben.

Generell ist es aber eine schlechte Idee, SQL-Strings auf diese Weise zusammenzusetzen, weil sich darüber alle Hacker freuen, die hiermit SQL Injection betreiben können. Das geht bei Access nicht gar so einfach, weil Access grundsätzlich nur einen SQL-Befehl ausführen kann. Dennoch sollte man sich gleich angewöhnen, besonders bei wichtigen Abfragen wie einem Login, eine parametrisierte Abfrage zu erstellen, diese über eine QueryDef in VBA laden und per Parameters-Collection füllen.

tblBenutzer hält bestimmt praktischerweise auch die Kombi User/Password bereit, am besten im Klartext, damit sich der Admin alle Passwörter abschauen kann und mal anderswo "rumprobieren" kann. Und wer dann die Datenbankdatei mit Shift öffnet, schaut als User sicher auch gern, was andere so als Passwort verwenden...

Übrigens: Wenn Du personenbezogene Daten speicherst, solltest Du Deine Datenbank auch gegen die DSGVO prüfen.

Meine Empfehlung: Keine eigene Benutzerverwaltung verwenden. Die gibt es schon, die Windows-Anmeldung, und die ist i.d.R. sicher genug für die meisten DB-Anwendungen. Auch dann und besonders, wenn man als Backend SQL Server einsetzt, da man dann mit Windows Authentication arbeiten kann.
Der Benutzer wird von einem weiteren lästigen Login verschont und Du als Entwickler kannst einfach auf die Windows API zugreifen und den Benutzernamen auslesen.

Selbstverständlich befreit Dich das weiterhin nicht davon, die DSGVO zu beachten. Daten, die mit Personen in Verbindung gebracht werden können, können leicht missbräuchlich verwendet werden, z.B. um ein Profil zu erstellen, wann wer wieviel gearbeitet hat.

Das "#1" bezieht sich auf die Posting-Nummer in einem Thread im Forum, die Du rechts oben über jedem Beitrag siehst.

Gruß

Christian

KrummiTill

#17
Da die Datenbank für persönliche Zwecke innerhalb einer Einheit gilt, ist die DSGVO nicht in dem Sinne relevant und alle finden das in Ordnung.
Da die Datenbank eine lokale Datenbank auf einem Rechner ist, klappt es leider auch nicht bezüglich dem WindowsBenutzer. Daher die Variante mit den Login Daten innerhalb der Datenbank.


Bezüglich der Bennenung in der XML. Ja hatte ich bereits gemacht. Es gibt keinerlei Fehlermeldungen.

Ich schaue es mir nochmal an. Danke an alle bisher. Vielleicht blicke ich einfach grad nicht so da durch. Ich melde mich nochmal wenn ich nicht weiterkomme.

Knobbi38

Zitat von: KrummiTill am November 14, 2024, 00:11:16Da die Datenbank eine lokale Datenbank auf einem Rechner ist, klappt es leider auch nicht bezüglich dem WindowsBenutzer.
Das verstehe ich nicht. Weshalb sollte das nicht klappen?