vb@rchiv
VB Classic
VB.NET
ADO.NET
VBA
C#
Top-Preis! AP-Access-Tools-CD Volume 1  
 vb@rchiv Quick-Search: Suche startenErweiterte Suche starten   Impressum  | Datenschutz  | vb@rchiv CD Vol.6  | Shop Copyright ©2000-2024
 
zurück

 Sie sind aktuell nicht angemeldet.Funktionen: Einloggen  |  Neu registrieren  |  Suchen

VB & Windows API
Re: VBA Access Desktoplocking Programm 
Autor: Zupa
Datum: 10.01.12 17:04

Hallo Frank,

Entschuldige bitte, dass ich mich so missverständlich ausdrücke.

Sämtliche Implikationen von "der Anwender ist Laie" stellen sich für mich wie folgt und in diesem Satz dar: Alles, was zum Erreichen des gewünschten Zustandes zu leisten ist, muss das Programm übernehmen.

(Mit "explorer.exe beenden" meinte ich, das Programm beendet den Explorer (über WMI). Diesen Gendanken habe ich aber wieder verworfen. Grund: Möglichkeiten, ein Programm zu beenden, ein neues zu starten oder zwischen ihnen zu wechseln, die explorer.exe zur Verfügung stellt, wären zwar damit ausgeschaltet, jedoch beendet dies auch nützliche "Hintergrund"aktionen, wie Kopieren o.ä., die kurz vor dem Aktivieren des Kioskmodus vom Benutzer gestarten worden sein könnten und unbedingt ungestört weiterlaufen sollen.)

Der Anwender klickt auf eine Schaltfläche mit der Beschriftung "Kioskmodus starten" (o.ä.), schon geht's los und er oder sie muss sich keine Gedanken machen, dass jemand "einfach so" auf den Computer zugreifen kann. Durchaus bin ich mir bewusst, dass es höchstwahrscheinlich keinen Weg gibt, einen Computer inklusive Daten gleichzeitig existent und sicher zu halten. Wer es also darauf anlegt, kann selbstverständlich JEDEN (physikalischen und programmierten) Schutz umgehen, den sich andere Menschen ausdenken. Mein Programm soll lediglich verhindern, dass "mal eben so" auf persönliche Mails o.ä. zu gegriffen werden kann. Deshalb akzeptiere ich, dass ein Kaltstart von meiner Seite nicht zu verhindern ist, dass nur hoffentlich vorher für die Benutzeranmeldung ein sicheres Passwort eingerichtet wurde, dass jemand ein Bootfähiges Volume anschließt und sich Zugriff verschaffen kann. (Oder andere Maßnahmen, die Zeit und Überwindung kosten und vorraussetzen, dass jemand tatsächlich ein gewisses mindestmaß an krimineller Energie und Wissen mitbringt)

Vielen Dank für deine Gedanken zum Hintergrund der Benutzung also, aber selbstverständlich werde ich die Benutzer meines Programms über das (hoffentlich kleine) Restrisiko aufklären.

Danke auch, dass du mein Augenmerk darauf richtest, dass in besagtem Modus ein Formular zur Texteingabe geöffnet sein wird, die von der DB (intern) bearbeitet und aber vorher geprüft werden muss. Diese (dann hoffentlich einzig mögliche) Eingabe zu kontrollieren wird jedoch nicht mehr dieses Thema berühren.

Kurz noch zu den Anwendern. Es wird zwei Sorten geben: die einen (Moderatoren, Gruppenleiter) lassen das Programm auf ihrem PC laufen und möchten, dass die anderen (Teilnehmende) dort brav nur in das Programm Eingaben machen und dass das Zugreifen auf ihre(n) Computer/Dateien/Programme/Emails etc. verhindert wird. Eine moderne Möglichkeit, Seminar-/Freizeitbegleitende Spiele durchzuführen.

Ich möchte kurz zusammenfassen, was meine bisher erprobten Strategien sind:

1) -Eine Batchdatei wird erstellt und auf dem neu erstellten Desktop ausgeführt. (CreateProcess Api)
-Diese soll entweder die gegenwärtige DB beenden und wieder (auf dem neuen Desktop) öffnen oder eine temporäre DB auf dem neuen Desktop öffnen.

2) -Mit CreateProcess wird direkt eine temporäre Datenbank auf dem neuen Desktop geöffnet.

3) -Ein Thread (CreateThread Api) innerhalb von Access wird mit SetThreadDesktop auf den neuen Desktop
geschoben, der dort entweder ein Formular öffnet, oder ein schon geöffnetes dorthin verschiebt.

Diese drei Methoden werfen keinen Fehler auf sondern tun stattdessen einfach lieber gar nichts.

Ich hoffe, ich verstehe es richtig, dass es keine Funktion zum erstellen eines Fensters auf einem anderen Desktop gibt. Ich hoffe auch, dass es nicht nötig ist, den ProcessToken meiner DB zu manipulieren.



Liebe Grüße,

Zupa
alle Nachrichten anzeigenGesamtübersicht  |  Zum Thema  |  Suchen

 ThemaViews  AutorDatum
VBA Access Desktoplocking Programm4.283Zupa07.01.12 18:05
Re: VBA Access Desktoplocking Programm3.210Zupa07.01.12 18:06
Re: VBA Access Desktoplocking Programm2.518Zupa07.01.12 18:09
Re: VBA Access Desktoplocking Programm2.624Zupa07.01.12 18:10
Re: VBA Access Desktoplocking Programm2.577Zupa07.01.12 18:12
Re: VBA Access Desktoplocking Programm2.658Zupa07.01.12 18:12
Re: VBA Access Desktoplocking Programm2.567Franki08.01.12 20:22
Re: VBA Access Desktoplocking Programm2.478Zupa09.01.12 17:37
Re: VBA Access Desktoplocking Programm2.615Franki10.01.12 00:05
Re: VBA Access Desktoplocking Programm2.666Zupa10.01.12 17:04

Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.

Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  GesamtübersichtSuchen 

nach obenzurück
 
   

Copyright ©2000-2024 vb@rchiv Dieter Otter
Alle Rechte vorbehalten.
Microsoft, Windows und Visual Basic sind entweder eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern. Weitere auf dieser Homepage aufgeführten Produkt- und Firmennamen können geschützte Marken ihrer jeweiligen Inhaber sein.

Diese Seiten wurden optimiert für eine Bildschirmauflösung von mind. 1280x1024 Pixel