Re moi
Avis aux développeurs/futurs développeurs d’applications Web Access:
Envoyé par Aide Access
Attention : la méthode utilisée dans la démo ci-après utilise une macro de données (macro nommée). Si la base est séparée en frontale/dorsale, la macro nommée est sur la dorsale et ne peut être appelée à partir d’un formulaire sur la frontale.Envoyé par Aide Access
Il semblerait que cette méthode soit donc réservée aux applications Web où l’emploi de VBA n’est pas possible (ou bien pour des bases que vous n’envisagez pas de splitter).
Prenons (au hasard) une gestion de stock (simplifiée):
Cette fois la quantité d’un article en stock sera calculée en sommant les [QtteMouvement] grâce à une requête "R_EtatStockArticle". Comme son nom l’indique [SeuilAlerte] doit permettre de prévenir l’utilisateur dès que le stock descend en-dessous de cette valeur.
Parmi les nouveautés, on peut noter l’action de données SetReturnVar (même pas francisée !) :
Un peu comme une variable renvoyée par une fonction VBA, quoi.Envoyé par Aide Access
On commence par saisir une macro de données (macro nommée) dans la table des Articles :
Considérons le bout de formulaire suivant (source: TblArticle):
La zone de texte [zdtQtteArticle] affiche la quantité en stock de l’article. Le bouton [btnCommander] est invisible par défaut.
Si le seuil d’alerte de l’article est atteint, on souhaite que la zone de texte [zdtQtteArticle] s’affiche sur un fond rouge et le bouton "commande" devienne visible (il est temps de regarnir le stock).
Nous rentrons donc la macro suivante sur activation du formulaire :
On exécute notre macro TblArticle.Alerte en passant l’identifiant de l’article en cours.
Les syntaxes [ReturnVars] ![QtteStock] et [ReturnVars] ![Alerte] permettent de récupérer les valeurs retournées par la macro TblArticle.Alerte.
Il ne reste plus qu'à définir les propriétés des contrôles du formulaire.
Résultat obtenu :
Voilà, ma première application Web compatible 100%macro, 0%VBA…
C’est c¤#, j’ai pas SharePoint 2010![]()
Partager