Masquer la fenêtre d'accès lors de l'ouverture d'un formulaire
Ma base de données Access a une macro autoexec qui ouvre un menu principal (la Forme). Toutes les fonctions nécessaires sont menu (formulaire)-contrôlée, et je veux cacher la Fenêtre d'Accès de sorte que seuls les formulaires sont affichés. J'ai été référé à http://www.tek-tips.com/faqs.cfm?fid=2562 mais cela ne fonctionne pas avec les versions ultérieures. Est-il un extrait de ce qui va travailler pour l'Accès 2007-2013?
Je ne suis pas sûr de ce que cela fait, mais cela a fonctionné. merci
OriginalL'auteur Robert Kendall | 2016-04-10
Vous devez vous connecter pour publier un commentaire.
C'est le code que j'ai couru de ma Acc 2003 et 2007, les Applications, l'exécution en 2010 environnement:
Pour cacher le ruban en 2007 et l'augmentation de l'utilisation de cette ligne, j'ai trouvé ici:
Kendall j'ai ajouté la ligne de code pour la réponse
OriginalL'auteur marlan
C'est ce que j'utilise qui fonctionne à l'horizon 2016:
Pour Masquer la Fenêtre tout Simplement:
Call SixHatHideWindow(SW_SHOWMINIMIZED)
AUSSI REMARQUE: Selon la Version c'est à dire 32 bits ou 64 bits, vous devrez peut-être ajouter le PtrSafe attribut donc, Si vous rencontrez des problèmes avec ce Déclarer l'API de la Fonction comme ceci:
Private Declare PtrSafe Function apiShowWindow...
J'ai reçu cette erreur avec ce même module avant. Il en a toujours été ainsi, parce que des erreurs de compilation à un autre endroit. Ce faire; 1. En commentaire de ce module, vous venez d'ajouter... puis compiler et de corriger les erreurs qui peuvent apparaître ailleurs. Si vous ne trouvez pas d'erreurs supplémentaires d'autre où puis des nations Unies-commentaire sur le module et le compacter et réparer la base de données. Qui devrait résoudre le problème.
Notez également que vous devez Appeler la fonction sur le Cas de la forme qui se déclenche avant l'Événement Load
Quand vous dites que l'appel de la fonction, qui est le même que l'exécution d'une macro avec la ligne d'action: SixHatHideWindow(SW_SHOWMINIMIZED) ?
Dans un sens oui... j'ai l'habitude de ne pas utiliser de Macro plus moi-même, mais tout ce qu'ils font dans la fin est de produire du Code VBA pour vous. Je n'ai jamais déclenché cette fonction à partir d'une Macro AutoExec... mais il doit fonctionne toujours. Je pense que le problème que vous rencontrez peut être dû à l'autre Module que vous étiez en train d'utiliser dans le masquage de la Fenêtre... Si elle avait des questions comme vous l'avez dit, alors il peut ne pas compiler. Avez-vous compilez comme je l'ai suggéré?
OriginalL'auteur Anthony Griggs
Il semble que votre objectif est de limiter l'Accès de l'INTERFACE utilisateur des fonctionnalités qui sont disponibles pour l'utilisateur de votre base de données. Vous souhaitez limiter les options que vous fournissez par le biais de votre formulaire de démarrage.
Dans ce cas, prendre une copie de votre fichier ACCDB et de modifier son extension de fichier ACCDR. Ensuite, lorsque vous ouvrez le ACCDR partir de l'Explorateur Windows, l'Accès à l'ouvrir dans "mode d'exécution". Mode d'exécution supprime la plupart de l'INTERFACE standard options. Par exemple, le volet de Navigation ne s'affiche pas, et ne peut même pas être ouvert. Aussi il vous donne une très minime version du Ruban; la majorité de la norme Ruban options sont partis.
Mode d'exécution a d'autres conséquences que vous devriez étudier pour voir si c'est un bon ajustement pour répondre à vos besoins. Une question importante est de mode d'exécution sortez de l'application lorsqu'une erreur non gérée est rencontré.
Si ACCDR/mode d'exécution adapté à votre situation particulière, il est un moyen peu coûteux pour limiter la base de données fonctions de l'INTERFACE utilisateur. Cependant, méfiez-vous qu'un utilisateur pouvait faire une copie de la ACCDR et de changer l'extension du fichier retour à ACCDB, de sorte que cette seule approche ne peut pas satisfaire à vos exigences de sécurité.
OriginalL'auteur HansUp
Je cherche à atteindre cacher l'Accès à la fenêtre de l'application et de l'utilisation popup formes que je puisse l'exécuter à partir d'Outlook. Voilà comment j'ai couru à travers ce post. Mais j'ai trouvé qu'avec Outlook 2013 64 bits sur Windows 7 64 bits, on n'a même pas besoin de la SixHatHideWindow fonction. En utilisant le code suivant dans Outlook 2013 accomplit la même chose. (N'oubliez pas d'ajouter une référence à la bibliothèque d'objets en VBA.) Cette procédure enregistre la légende de la fenêtre Outlook, démarre une nouvelle instance masquée de l'Accès (la fenêtre de l'application n'est pas visible), ouvre l'Accès de base de données, exécute le formulaire prévu à cet effet (visible), sort de l'Accès de l'instance lorsque le formulaire est fermé, et ré-active l'origine Outlook fenêtre active. Je n'ai pas testé dans tout autre environnement, ni avec le runtime Access.
La grande chose au sujet de cette approche est qu'il ne nécessite pas que tout code spécial inséré dans la forme ouverte de l'événement dans la base de données Access. Tout le code nécessaire est contenue dans Outlook VBA. Ni la base de données du formulaire popup et propriétés modales besoin d'être réglé sur "Oui" dans la base de données.
La forme dans ce cas est une forme complexe, avec un onglet de contrôle et de plusieurs sous-formulaires. Tout semble fonctionner si le formulaire est ouvert à partir de l'Accès lui-même ou par l'intermédiaire de l'automatisation à partir d'Outlook.
Remarque: Le SetWindowPos api permet de définir l'emplacement et la taille de l'Accès de la fenêtre principale, même si l'Accès n'est pas visible. Lorsque l'Accès est fermé, la prochaine fois que l'utilisateur ouvre l'Accès, il sera ré-ouvert à la taille et à la position définie par l'api SetWindowPos. Cela pourrait être gênant pour les utilisateurs, de sorte que le SetWindowPos api définit l'Accès à la fenêtre de l'application en plein écran de la taille. La prochaine fois que l'utilisateur ouvre l'Accès, il sera agrandie sur leur écran. Il peut y avoir davantage de moyens sophistiqués pour gérer cela, mais cette approche est rapide et facile, et la plupart des utilisateurs de travailler avec Accès agrandie dans la plupart des cas, de toute façon.
Espère que cela aide quelqu'un à sortir.
OriginalL'auteur phillfri