Office: (Office 2007) Deaktivieren der access Spezialtasten mittels Code

Du kannst auch mittels VB-Skript AllowSpecialKeys von außen setzen.
Ich verstehe allerdings das Problem immer noch nicht. Was ist so schlimm daran, wenn man kurz vor Auslieferung die Werte per Skript einstellt? Warum sollte das bei jedem Anwendungsstart gemacht werden, obwohl dann immer nur die gleiche Einstellung getroffen wird?

Wenn es dir nur darum geht, dass in bestimmten Formularen die Tasten nicht wirken sollen, in anderen sollen sie aber verfügbar sein, dann ist das Ändern der Eigenschaft AllowSpecialKeys meiner Ansicht nach die falsche Herangehensweise.

 

Hallo,

die Startparameter heißen IMO so, weil sie beim Start von Access, also noch
vor dem Start der Anwendung durch AutoExec oder Startformular gesetzt werden.
Wenn diese durch AutoExec oder ein Startformular "nachträglich" gesetzt werden,
ist ja die Startphase schon vorbei
(also irgendwie so wie bei Münchhausen, dem Sumpf, dem Pferd und dem Zopf).

D.h. IMO, dass die per VBA gesetzten Startparameter erst beim nächsten Male greifen,
wie in #14 und in #10 bereits angemerkt.

Also beim ersten Setzen gilt
Eatur quo deorum ostenta et inimicorum iniquitas vocat
Iacta alea est
Aber beim nächsten Würfeln, klappt's wie gewünscht *tongue.gif*

 

\@Josef,

Du hast natürlich Recht, die Optionen müssen ja nur einmal gesetzt werden.
Was mich jedoch dazu bewogen hat, dies so wie beschrieben umzusetzen, ist
die Möglichkeit beim Kunden (also OP am offenen Herzen) "schnell" die
Startparameter wieder zurücknehmen zu können, um in den DB-Entwurf zu gelangen.
Einen versteckten Knopf in der Anwendung wollte ich nicht einbauen, wg. der
vielleicht vorhandenen vielen Augen, welche bei der OP interessiert zuschauen.
Eine ini-Datei erstellen und ein paar kryptische Parameter setzen sieht halt
mehr nach Profi aus *tongue.gif* - ist aber sicherlich eine Geschmackssache.

 

Bezüglich "Mal schnell öffnen":
Das könnte man auch so machen:
D:\ein\vbscript\db-im-entwurf-oeffnen.vbs D:\eine\Anwendung.mde
Dann muss die Anwendung nicht neu gestartet werden.
Sieht das dann noch "professioneller" aus? *biggrin.gif*

 

Sagen wir mal so, ich setze das komplette Verbot aller möglichen Keys inklusive AllowByPass, bei jeder Beendigung meiner DB. Beendigung ist auch nur über meinen Close-Button zu schliessen (natürlich auch über den Affengriff ^^).

Einfach um rumspielende Wissende ein wenig zu ärgern/den Spaß am ausspionieren zu erschweren. ^^

Hilft sicherlich nur was in Kombination mit vielen weiteren Vorsichtsmaßnahmen. Aber zumindest könnte man hoffen das der Rumspielende nach dem er das 3te Mal von aussen den AllowByPasKey wieder ausschalten musste die Laune vergeht.

Gruß

Rainer

 

Hallo miteinander,
„iacta alea est.“ Cäsar hat recht: Der Würfel ist gefallen, wenn das Programm erst an viele Kunden ausgeliefert ist. Darum auch die erfreuliche Diskussion mit Euch vor Auslieferung. Noch mal zur Sache:

Mein Ziel war es, die möglichen „Sicherheitsparameter“ im Programm unterzubringen und nicht erst durch Einstellungen vor Auslieferung. Ihr wisst ja, was schief gehen kann, geht auch schief. Damit ich mich nicht selbst aussperre, habe ich eine Konstante vorgesehen, die als letzte Aktion auf Kundenmodus umgestellt wird. Es ist auch nicht vorgesehen, ins Programminnere in ein ausgeliefertes Programm bei einem Kunden vorzudringen.

Die Idee mit einem Skript ist sicher auch eine Lösung (die ich auch erst erschaffen müsste). Die IMO Lösung, die vor Start von Autoexec greifen soll, ist vielleicht auch grundsätzlich geeignet, dass ein Wissender die Parameter mit böser Absicht aufheben kann.
Rainers Verfahren, die Parameter am Schluss zu setzen, könnte überhaupt der Cloe sein. Mit dem „Close“ könnte das schwierig sein. Wie kann man den Abgang über Schließen der Datenbankanwendung in der Kopfzeile abfangen? Ich zitiere nachfolgend Minthorst/ Grundlagenbuch:

Mit dem nachfolgend beschriebenen Verfahren wäre dann das Setzen der Parameter für den Folgestart gesichert. Was haltet ihr davon?
Gruß vom Lateiener

 

Wie in dem Buch schon gesagt wurde, ein wenig Fantasie ist nötig.

Ich habe ein Startformular das duch das Autoexec-Makro (neben anderen Dingen) als Anmeldeformular beim Öffnen der DB mit als Erstes geladen wird.

War die Anmeldung erfolgreich, schliesse ich das Formular nicht, sondern mache es nur unsichtbar über die Visible-Eigenschaft.

Da es das erste geladene Formular ist, versucht Access beim Schliessen der Anwendung (egal von woher der Befehl dafür kommt, Ausnahme natürlich über Affengriff / Task-Manager) dieses Startformular als erstes zu schliessen.

Die erste Prüfung beim Form_Unload-Ereignis dieses Startformulares ist dann ob einen globale Variable einen bestimmten Wert hat, hat diese globale Variabele den Wert nicht wird das Unload-Ereignis mit Cancel = True abgebrochen. Durch den Abbruch des Schliessen des Formulares wird auch der gesamt Beendigungs Prozess von Access gestoppt/verhindert.

Die globale Variable hat nur den richtigen Wert wenn die Anwendung über den von mir eingebauten Button geschlossen wird, da ich dort vor dem Schliessen eben die Variable zuerst mit dem richtigen Wert bestücke.

Da ich mit Access 2007 arbeite, habe ich den wirklich genialen Vorteil der TempVars. Somit kann ich auch dauerhaft Variabelen abspeichern (TempVars in eine txt-Datei schreiben bei Beendigung und beim nächsten Load zuerst diese txt einlesen und die TempVars bestücken, damit stehen Werte der letzten Sitzung bei der neuen Sitzung zur Verfügung ... echt genial damit Anwendungseinstellung etc. zu speichern). Hier speichere ich z.B. auch Werte ab ob die letzte Sitzung korrekt geschlossen wurde.

Wurde z.B. eine Anwendung mehr als 3 mal unkorrekt beendet, wird sie beim nächsten Start von Haus auf per Automatismus korrekt geschlossen.

Gruß

Rainer

 

Hallo Rainer,
vielen herzlichen Dank für deine Mühe, den Ablauf ausführlich und verständlich darzustellen. Eine große Hilfe! Das Verfahren entspricht so ganz meinen Vorstellungen, zumal ich ebenfalls access 2007 einsetze.
Glückauf aus Bochum
Lateiner

 

Nachtrag
Das Beenden der Anwendung ausschließlich über eine eigene Schaltfläche führt dazu, dass die Erstellung der accde-Version abgeblockt ist. Hilfreich ist nun eine Schaltfläche, die nur im Test-Modus sichtbar ist. Diese Schaltfläche ermöglicht dann auf gleiche Weise einen Eintrag in die Variable (TempVars), die nach Quit den Unload des Formulars ermöglicht, das zur Überwachung des Schließens verwendet wird.
Lateiner

 

Du als Entwickler der DB kannst diese ja mit der Shift-Taste starten, dann alle Parameter setzen und dann in die Accde kompilieren. Da durch Shift-Start ja das Startfomular nicht geöffnet wird (oder noch einfacher Du schliesst das Start-Formular einfach bevor Du komplilierst durch eine kleine Hilfsroutine die dann zuvor die Variable auf den Wert für Schliessen zulässig setzt). *wink.gif*

Gruß

Rainer

 

Hallo Rainer,
vielen Dank auch für deinen ergänzenden Hinweis. Durch die Diskussion zum Thema habe ich einiges dazugelernt, was mir nun selbstverständlich erscheint.

In diesem Zusammenhang habe ich noch eine Zusatzfrage. Nach der Kompilierung steht die Originaldatei mit Typ accdb und die kompilierte mit accde zur Verfügung. Der Typ wird bei Aufruf der Datenbank nicht geprüft. Die gültigen Typen z.B. mdb, accdb, accde und accdr werden auch bei Änderung akzeptiert. Es müsste eigentlich per VBA auf einfache Weise im Programm selbst feststellbar sein, ob es sich um eine kompilierte oder nicht kompilierte Version handelt. Kennst du eine Lösung?
Gruß Lateiner