Discussion :

[Papy Turbo]

Je commence par une remarque sur le rythme de déroulement de ces "cours" :
- c'est le même rythme que les questions/réponses sur le forum, à savoir : réponse rarement le même jour, généralement le lendemain voire plus tard, si l'un de nous est occupé.
C'est, pour moi, le rythme idéal, à savoir totalement souple, sans contrainte ni obligation, selon la disponibilité du moment.
Merci à chacun d'indiquer ce que vous en pensez : si c'est trop lent (on vit dans une civilisation du vite fait/tout prêt/à jeter/surtout si c'est gratuit, donc il peut y en avoir que cela énerve), ou autre ?

Quant au contenu, je n'en sais, au départ, pas beaucoup plus que vous : on part sur une question précise, on ne sait pas où on arrivera.
Il y a d'autres cours, correctement structurés, sur ce forum : il est indispensable de les étudier à fond, quitte à refaire ces cours avec la base de Serge57 à titre d'exercice !

Enfin, je profite de cette étape entre 2 cours pour remercier Serge57 qui a d'autres occupations professionnelles et qui a consacré beaucoup de temps à ses réponses et questions diverses

[philben]

Bonjour Papy Turbo,

S'il y avait 10 lois du programmeur Access qu'elles seraient les tiennes ?

(J'en connais, je pense, déjà 2 ou 3...)

Amicalement,

Philippe

[Papy Turbo]

Olla, Philippe,

question kolossale !

(J'en connais, je pense, déjà 2 ou 3...)

Déjà, j'aimerais bien savoir ce que tu as retenu, ou ce qui t'as paru le plus important ?

J'aime pas trop les lois ni les règlements rigides, donc, de toute façon, je préfère toujours parler de conseils : je ferais comme ça...
Ce qui sera valable pour un grand nombre de cas ne le sera jamais pour tous les cas et, de fait, la seule << LOI >> que j'ai fait graver dans le marbre au dessus du fronton de mon PC d'albâtre (çui là est pas portable) dit :

Il existe une loi et une seule qui s'applique systématiquement toujours et partout.
Et cette loi est :

Il n'existe aucune loi qui s'applique systématiquement toujours et partout.

En dehors du bon vieux cliché ("toute loi supporte des exceptions"), il y a eu des mois de perdus en développements inutiles parce qu'un chef de projet s'est acharné avec des principes immuables appris à l'école ou ailleurs.
Style: "Tout projet doit obligatoirement être découpé en trois tiers (ou 3 couches) : Interface + objets Métier + Accès aux données."
Même avec Access, cette "loi" reste très valable, du moins pour une application complète, mais surtout pas oligatoire.
Et l'accès aux données reste essentiellement... dans l'interface ! avec le binding aux formulaires et aux contrôles.
Et, précisément dans Access qui est le seul logiciel de développement que je connaisse avec un binding "qui marche", ça pose des problèmes très spéciaux...

Enfin, le plus important, je pense, est de comprendre le pourquoi de toute règle (ou loi, ou conseil, ou...).
Un développeur qui a compris pourquoi on fait généralement plutôt comme ça que comme ci, sera à même
- de choisir parmi plusieurs solutions,
- d'adapter chaque cas au contexte,
- d'éviter les pièges,
- d'affiner ces règles avec chacune de ses expériences,
etc.
Celui qui applique les règles "by the book" comme disent les anglos, réussira peut être un peu plus vite mais risque de se planter grave et n'ira jamais très loin.

[philben]

Re bonjour,

Mon ami Papy Turbo a écrit :
Déjà, j'aimerais bien savoir ce que tu as retenu, ou ce qui t'as paru le plus important ?

J'ai retenu ça de tes cours :

1) Analyser le problème dans sa globalité et localement avant de partir tête baissée dans la programmation.
2) Décomposer pour obtenir des unités simples de programmation
2) Avancer étape par étape, analyser l'étape, programmer
3) Tester, vérifier l'étape avant de passer à la suivante
5) Penser futur et non présent : lisibilité du code, documentation, convention de nommage, pour ne pas se perdre a posteriori
6) tu as des habitudes de programmation qui te servent de cadre, et donc de lois...

Me trompes-je ?

Merci encore de partager ton expérience car ça permet aux néophytes de partir sur des bases saines et aux autres de réfléchir sur leurs méthodes...

@+

Philippe

[Papy Turbo]

tu as des habitudes de programmation qui te servent de cadre, et donc de lois...

De cadre, oui, bien sûr, sinon l'expérience ne servirait à rien.
De loi, plus ou moins, avec toujours les mêmes restrictions : la prochaine expérience va peut être tout chambouler

Surtout, je ne me considère pas en position pour énumérer un 'Guide des bonnes manières du parfait développeur', quelle que soit l'expérience.
Je laisse les bonnes manières à la baronne de Rotschild, et je laisse la mise en forme et la présentation des bonnes méthodes de programmation aux gens dont c'est le métier.

Voir, sur DVP, tout ce qui concerne la Conception et notamment, sur les méthodes agiles.
J'ai moi même découvert cet ensemble de méthodes il y a quelques années, avec la certitude d'en avoir déjà pratiqué la plus grande partie.
Surtout, avec l'impression qu'enfin, je ne tombais pas sur un ensemble de lois rigides et 'scolaires', mais sur de vraies règles de bon sens, manifestement basées sur l'expérience.
Il faut prendre toutes ces méthodes avec des pincettes :
- elles sont généralement formulées pour des équipes, alors que nous, sous Access, travaillons souvent seul, (dans ce cas là, le travail en binôme, ça se passe avec mon chat. )
- du fait de nos développements souvent courts et légers, les étapes se fondent + ou - les unes dans les autres,
- etc.
Mais j'aime bien les mises en garde faites par les gens qui ont rédigé et continuent à enseigner ces méthodes : elles doivent impérativement être adaptées à chaque cas, à chaque équipe de développement et aux personnes (y compris les clients/utilisateurs !) qui y participent...

Juste un bémol : cette méthode existe depuis des années, et a changé de nom pour se rebaptiser 'eXtreme Programming', comme par hasard peu après le lancement de Windows XP et Office XP. Joli coup de promotion, mais je continuerai à utiliser le terme d'origine ("agile methods", en anglais), qui me paraît beaucoup plus proche de l'esprit et du contenu de la méthode qu'un quelconque slogan publicitaire pour cône glacé.

[tonio-lille]

Bonjour à tous,

Je vais commencer par dire un grand merci à Papy Turbo pour le temps qu'il consacre à son cours sur les turbo-formulaires.

Je suis actuellement sur un nouveau projet et j'ai décidé d'utiliser les turbo formulaires. J'aurai une simple question (pas si simple en fait):
J'ai dans ce projet:
-mon formulaire principal (sans source de données)
-un 1er sous-formulaire
-un 2e sous-formulaire inclu dans le 1er

dans le 2e sous-formulaire, j'ai une combo box avec comme source de donnée une requête qui est filtré par un des champ du 2e formulaire

En mode formulaire continu pour le 1er sous-formulaire, la requête est bien mise à jour.

En mode feuille de donnée ça coince.
la requete n'est pas mise à jour quand je change l'enregistrement en cours.

Merci d'avance pour vos réponses et n'hésitez pas à m'indiquer si mon explication n'est pas clair.

PS: je me suis permis de poster ici, car je pense que ça peut être un point à voir dans les turbo-formulaire.

[Papy Turbo]

Bonjour, Tonio-lille,

Je suis actuellement sur un nouveau projet et j'ai décidé d'utiliser les turbo formulaires.

Bravo , en espérant que tu ne regrettes pas trop tôt ce choix .
Et surtout, bienvenue à toutes questions de cet ordre, parce qu'il y a des limites à ce qu'on peut faire en affichage "feuille de données".

Ça ne veut pas dire qu'il ne faut pas l'utiliser, parce que je crois profondément à la valeur ajoutée, sur le plan ergonomique, pour tout ce qui touche aux recherches sur les données d'un formulaire.
Je le répète : je ne connais pas un utilisateur qui ait utilisé ce type de fonctionnement et qui accepte de "revenir en arrière", en perdant la vue d'ensemble que donne la feuille de données, sauf cas obligatoire comme le remplacement de la base Jet par une base Client/Serveur.

Ça veut dire qu'il ne faut s'en servir que pour ce qu'il sait faire : des recherches par Ctrl+F, filtrages, tris..., impressions d'états... mais, sauf exceptions, pas de saisie, réservée à l'affichage complet, en formulaire.

Pour répondre à ta question, je ne suis pas sûr d'avoir tout compris.
Peux-tu, pour l'exercice, reproduire le problème avec notre application test de SuiviAffaires, à savoir
- partir de la dernière version, copie zippée sur le cours 03, en bas de la réponse#26
- ajouter une liste déroulante sur un sous-(sous-)formulaire, au même niveau que dans ton application, avec un filtre identique, sur un champ du même niveau que le tien,
- vérifier que tu as le même problème en feuille de données,
- nous le passer en fichier zippé, pour qu'on trouve une solution, s'il y en a une.

Nous en profiterons pour développer les diverses limitations et pièges qu'offre l'affichage "feuille de données" ! Y en a quelquezunes

[tonio-lille]

Bonjour Papy Turbo,

J'ai ajouté le même système que moi sur votre application suiviAffaire et là... pas de problème sur celle-ci donc problème pour moi qui ne peux pas présenter mon problème .

Je vais essayer de présenter ça mieux:
Imaginons 4 tables (entre parenthèses les clés primaires)[entre crochets les clés étrangères]
Affaire(num_affaire, id_cli)[id_cli] identification relative
Client(id_cli)
fourniture(id_frn)[id_cli]
détail fourniture(num_affaire,id_cli,id_frn)[num_affaire,id_cli,id_frn]

la table détail fourniture est table faisant le lien entre affaire et fourniture.

-Dans mes formulaire j'ai donc un formulaire principal où se trouve le sous-formulaire Affaire.
-Dans Affaire, il y a sous-formulaire pour détail-fourniture lié par les champs num_affaire et id_cli
-Dans le sous-formulaire j'ai le champs combo box id_frn qui contient une requête du style "SELECT id_frn from fourniture where id_cli = form[....].id_cli"


quand je suis en mode feuille de données et que je passe d'un enregistrement à l'autre, il me garde toujouts les 'id_frn' correspondant à 'id_cli' du premier enregistrement.

Si ce n'est toujours pas clair, dites le moi

[tonio-lille]

J'ai trouvé un début de solution, en mettant un simple requery sur la combo box. Mais je ne comprends pourquoi sur votre appli suiviAffaire, ça fonctionnait sans l'aide du requery.

Je continue à poser quelque question sur les turbo Formulaire:

Papy Turbo:

Ça veut dire qu'il ne faut s'en servir que pour ce qu'il sait faire : des recherches par Ctrl+F, filtrages, tris..., impressions d'états... mais, sauf exceptions, pas de saisie, réservée à l'affichage complet, en formulaire.

Donc pour empêcher les saisies, on peut dans le bouton tglChangeVue selon le mode d'affichage, mettre à jour la propriété 'locked' des champs du formulaire.
Est ce une solution valable ou y a-t'il une option plus obscure qui permet de le faire automatiquement?

Papy Turbo:

Nous en profiterons pour développer les diverses limitations et pièges qu'offre l'affichage "feuille de données" ! Y en a quelquezunes

Sur point là, dans le cas d'une appli multi-utilisateur, si un utilisateur 1 et un utilisateur 2 travaille sur les mêmes données en mode en feuille de données, est ce que les modifications du 1 sont automatiquement mise à jour sur le poste de 2 ou faut-il attendre que 2 recharge son formulaire?(et inversement)

[Papy Turbo]

Bonjour, Tonio,

J'ai trouvé un début de solution, en mettant un simple requery sur la combo box. Mais je ne comprends pourquoi sur votre appli suiviAffaire, ça fonctionnait sans l'aide du requery.

Il m'arrive aussi d'avoir à mettre un combo.requery dans l'évènement Form_Current()...
Sans avoir l'application sous les yeux, je ne saurais pas te répondre.

Donc pour empêcher les saisies, on peut dans le bouton tglChangeVue selon le mode d'affichage, mettre à jour la propriété 'locked' des champs du formulaire.
Est ce une solution valable ou y a-t'il une option plus obscure qui permet de le faire automatiquement?

1- il y a une solution beaucoup plus simple, c'est de mettre [formulaire].AllowEdits = False
Ça ne marche pas toujours, notamment lorsqu'il y a des boutons bascules ou autres composants qu'on en veut pas bloquer !
Lorsqu'on ne veut bloquer que les champs de données, et pas, par exemple, le bouton tglChangeVue, pour basculer l'affichage d'un sous-sous formulaire, il faut en passer par une boucle sur les Control.Locked = True.
2- je ne préconise pas de bloquer la saisie. Il reste 10 % de cas où la saisie est beaucoup plus pratique en affichage feuille de données (listes simples, séries de cases à cocher, etc.)
Ce que je veux dire : en feuille de données, il faut s'attendre à ne pas trouver toutes les infos. Certains contrôles, notamment les option Groups, devraient être masqués en feuille de données (ils affichent le n° de l'option choisie, pas son nom ).
Tous les sous-formulaires ne sont pas visibles en feuille de données :
- quand le sous-formulaire "principal" est en feuille de données,on peut cliquer sur le + pour afficher le contenu du 1er sous-sous-formulaire.
- les autres (2ème, 3ème... sous-sous-formulaires) ne seront visibles qu'en affichage formulaire.
Etc.

Sur point là, dans le cas d'une appli multi-utilisateur, si un utilisateur 1 et un utilisateur 2 travaille sur les mêmes données en mode en feuille de données, est ce que les modifications du 1 sont automatiquement mise à jour sur le poste de 2 ou faut-il attendre que 2 recharge son formulaire?(et inversement)

Je n'ai constaté aucune différence entre les 2 affichages, en ce qui concerne la saisie multi-utilisateurs. Les rafraîchissements sont les mêmes.
Le rafraîchissement, d'après mes observations, semble se passer au moment où la souris passe au dessus d'un enregistrement. Rien vu dans la doc d'Access sur ce sujet.

-------------------
Enfin, attention à un des plus gros pièges des sous-formulaires :
Ne t'avise pas de bloquer sans précaution l'ajout (par exemple avec [formulaire].AllowAdditions = False) dans un sous formulaire.
Le problème est le suivant :
- tant que AllowAdditions est vrai, il y a toujours un enregistrement vide, au moins, dans chaque sous-formulaire. Même s'il n'y a aucune donnée existante dans la table.
- si tu bloques les ajouts, il n'y a plus rien dans le formulaire.
- en affichage formulaire, on ne voit plus aucun contrôle (surface vide)
Dans ce cas, l'objet formulaire correspondant au sous-formulaire "vraiment vide" est détruit. Y en a plus du tout !
Toute référence à la propriété .Form du sous-formulaire renvoit une erreur 2455 : "La référence d'une expression à la propriété Form/Report n'est pas valide."
De même, toutes sortes d'erreurs si tu fais référence à son recordset, à un des contrôles, etc.
On peut gérer cela, mais ça m'a pris plus de 6 mois de déboguer une application complexe utilisant des turbo-formulaires protégés (aucune saisie sans cliquer sur un bouton Ajouter ou Modifier).
Donc, à éviter.

Il y a pire encore, en affichage "feuille de données": tant qu'un sous-formulaire n'a pas été "étendu" (en cliquant sur le + pour afficher les données hiérarchiques), il n'existe pas, et on retrouve une autre série d'erreurs 2455 ou similaires !!!
Là aussi, on peut s'en sortir, en ce qui concerne le premier sous-formulaire.
Exemple de solution, lorsque le parent fait référence à son sous-formulaire, qui n'est pas forcément vide :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
    [...]
    On error Goto Unexpanded
    ssfDemandes.Form.[...]
    On error Goto Catch
 
Unexpanded:
    '2455         La référence d'une expression à la propriété Form/Report n'est pas valide.
    'se produit lorsque SubForm est vide,ou, au démarrage, si le 1er n'a pas été 'expanded'.
    'Réussit à fonctionner après un Expand On/Off, uniquement pour le PREMIER sous formulaire,
    '   celui qui apparaît en mode subdatasheet.
    If Err = 2455 Then
        If FirstError = False Then
            Me.SubdatasheetExpanded = True
            Me.SubdatasheetExpanded = False
            FirstError = True
            Resume
        'sinon, tombe en dessous
        End If
    End If
Catch:
    'Traitement des erreurs non prévues...

Noter : Une variable FirstError est toujours utilisée avec un Resume, pour éviter une boucle san fin : si l'erreur se reproduit > même gestionnaire d'erreur > Resume encore une fois > même erreur...

[tonio-lille]

Bonjour PapyTurbo,

Merci pour ces réponses et les quelques "pièges à éviter". Je continue mon développement de turbos formulaires et je n'hésiterai pas à reposter si certains points sont à éclaicir.

Encore merci et à bientôt.

[tonio-lille]

Bonjour,

Je continue mon aventure avec les turbos formulaires et je tombe sur une satané erreur 2455. je fais donc une recherche sur le forum et je retombe sur notre conversation sur les pièges à éviter. J'ai donc essayé la solution proposé et ça fonctionne presque (en mode feuille de données, mon champs n'est pas mis à jour).

mon problème est simple, j ai un formulaire article, un ss-formulaire entrées-sorties-stocks. Dans mon formulaire article, j'ai un champs 'stock disponible' qui est la somme des entrées sorties du sous-form. Mon but est d'avoir ce champs correctement rempli en mode feuille de données.

J'ai essayé trois solution,

1 - un sous-formulaires contenant la requete faisant la somme et évidement le champs n'est pas affiché en mode feuille de donnée

2 -

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Dim firstError As Boolean
    On Error GoTo Unexpanded
 
    firstError = False
    Me.stock_reel = Me.art_stock_reserve
    With Me.ssf_es_articles.Form.RecordsetClone
        If .RecordCount = 0 Then
            Exit Sub    '=============================
        End If
        Do While Not .EOF
            'ajout de chaque entrées sorties de stocks
            Me.stock_reel = Me.stock_reel + Nz(!es_quantite, 0)
            .MoveNext
        Loop
    End With
Exit Sub
Unexpanded:
    '2455         La référence d'une expression à la propriété Form/Report n'est pas valide.
    'se produit lorsque SubForm est vide,ou, au démarrage, si le 1er n'a pas été 'expanded'.
    'Réussit à fonctionner après un Expand On/Off, uniquement pour le PREMIER sous formulaire,
    '   celui qui apparaît en mode subdatasheet.
    If err = 2455 Then
        If firstError = False Then
            Me.SubdatasheetExpanded = True
            Me.SubdatasheetExpanded = False
            firstError = True
            Resume
        'sinon, tombe en dessous
        End If
    End If

dans le form_Load

et le résultat est le même, en feuille de données le champs n'est pas correctement rempli.

3 - modifier la requête du form article pour qu'elle contienne la somme des entrées sorties. ça fonctionne mais la c'est la ligne d'ajout qui n'est pas disponible(normal mais embêtant)


Y a-t-il une solution à ce genre de problème ou est ce là une limite des turbo-formulaires

Merci d'avance pour vos réponses

PS: j'ai présenté une première version de mon appli avec turbo-formulaires et le client était ravi du résultat.

[Papy Turbo]

Bonjour, Tonio,

suis très charette en ce moment, mais la première solution qui vient à l'esprit :
- tu peux utiliser ton code à Form_Load, en le basant sur une requête indépendante du sous-formulaire (à la place du recordsetclone).
Genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT * FROM [tableStock] WHERE Numero_Article = MonFormulaire!NumeroArticle

Cet exemple n'est que du pseudo-code, à adapter.
Disons que tu peux toujours utiliser la même requête qui sert de source au sous-formulaire concerné, avec en plus une condition sur le champ clé ( = le champ père-fils de la liaison formulaire <-> sous-formulaire).

Y a-t-il une solution à ce genre de problème ou est ce là une limite des turbo-formulaires

Il n'y a aucune limite aux turbo-formulaires
Peut être à l'affichage feuille de données trouvera-t'on quelques limites de ce type, faciles à contourner.
Non, je rigole. S'il n'y avait aucun problème, où serait le fun ?

En tout cas, bon courage.

Pour info, j'ai moi aussi créé la semaine dernière une petite appli (7 tables, 1 turbo-formulaire + 6 listes simples), à partir du même exemple déposé sur le forum, en moins de 2,5 jours (20,44 heures précisément, y compris rédaction d'un manuel d'utilisation de 18 pages).
Elle est installée, elle tourne.
Le client en question est furax contre moi, parce qu'il espérait ne commencer qu'en janvier

P.S. : es-tu sûr d'avoir bien étudié ton application ?
Il ne me paraît pas normal de devoir faire ce genre de somme autrement que par une requête SUM() (beaucoup plus rapide).
Surtout à Form_Load : ça ne fera le total que pour le premier article ?... À approfondir
Le temps d'écrire tout ça, et je me dis qu'une bonne requête Mise à jour (UPDATE), lancée à Form_Load, va directement faire la somme des stocks pour chaque article, et coller chaque somme dans le champ correspondant de l'article.
Mais, en matière de stock, on essaye surtout de garder le "stock disponible" sans aucun recalcul, en y ajoutant/retranchant chaque mouvement, au fur et à mesure qu'ils se produisent...

[tonio-lille]

Merci pour la réponse

P.S. : es-tu sûr d'avoir bien étudié ton application ?
Il ne me paraît pas normal de devoir faire ce genre de somme autrement que par une requête SUM() (beaucoup plus rapide).
Surtout à Form_Load : ça ne fera le total que pour le premier article ?... À approfondir

A la base j'étais parti là dessus une requête reliant les deux tables
et faisant la somme du champs 'nb_entreees_sorties' et à l'affichage parfait mais je perdais la ligne qui permettait l'ajout.
Mais à priori le turbo formulaire n'est pas fait pour faire des insertions de données

Ça veut dire qu'il ne faut s'en servir que pour ce qu'il sait faire : des recherches par Ctrl+F, filtrages, tris..., impressions d'états... mais, sauf exceptions, pas de saisie, réservée à l'affichage complet, en formulaire.

Le temps d'écrire tout ça, et je me dis qu'une bonne requête Mise à jour (UPDATE), lancée à Form_Load, va directement faire la somme des stocks pour chaque article, et coller chaque somme dans le champ correspondant de l'article.

Mais, en matière de stock, on essaye surtout de garder le "stock disponible" sans aucun recalcul, en y ajoutant/retranchant chaque mouvement, au fur et à mesure qu'ils se produisent...

Là, ta remarque m'interpelle, si j'ai bien compris il me faudrait un champs 'stockdisponible' dans ma table articles qui serait mis à jour à chaque ajout, suppression ou modification dans la table entrees_sorties_stock.
Une des premières règle que l'on m'ait apprise, est qu'aucun champ d'une base de données ne doit être calculable à partir d'autres champs.
Mais je sais que la règle d'or de papyTurbo est :

"Il n'y a aucune règle qui s'applique systématiquement, toujours et partout." Vivent les exceptions.

Donc si vous me confirmez que souvent en stock, on ajoute un champ stockDisponible dans la table articles( ce qui m'éviterai bien des soucis), je le ferai

Encore merci et bon après-midi

[Papy Turbo]

Bonjour, Tonio,

Là, ta remarque m'interpelle, si j'ai bien compris il me faudrait un champs 'stockdisponible' dans ma table articles qui serait mis à jour à chaque ajout, suppression ou modification dans la table entrees_sorties_stock.
Une des premières règle que l'on m'ait apprise, est qu'aucun champ d'une base de données ne doit être calculable à partir d'autres champs.

Ça me paraît être une très bonne règle qu'on t'a apprise, même si je préconise l'inverse, en l'occurence.
Pour au moins une raison : il peut toujours y avoir une panne quelconque, voire un bug (non, quand même pas), qui fait que ton champ [stockdisponible] ne serait plus juste.
Mais je préfère utiliser ce champ quand même, parce que, sur le formulaire, c'est beaucoup plus rapide d'afficher le contenu d'un champ stocké que de recalculer le total.
Ce que je fais, pour concilier les deux :
1- exécution d'une requête qui recalcule tous les [stockdisponible]. Elle ne devrait pas prendre plus de quelques secondes, mais elle permet d'avoir toujours des totaux sûrs, même après une coupure de courant.
2- en complément, je maintiens interactivement chaque [stockdisponible], en fonction des entrées/sorties, ce qui fait qu'à l'écran, j'ai des résultats instantannés.
La question à régler est un vaste sujet : quand, combien de fois, exécuter la requête en 1- ?
Ça peut être
- à Form_Load (simple, mais ralentit chaque ouverture. Parfait au départ, si on ne perçoit pas ce temps mort..)
- une fois par ? jour ? semaine ?, en enregistrant la date de la dernière exécution,
- avant chaque lancement d'un état qui utilise ce champ,
- si on détecte qu'un seul des [stockdisponible] est faux, ou
- l'utilisateur soupçonne une erreur : il clique sur un bouton ou une commande de menu,
- etc.
Évidemment, c'est un luxe de faire cette "double" programmation. Ne faire que si tu détectes un ralentissement (très gros stock).

Ça nous éloigne beaucoup des turbo-formulaires, ça..., mais c'était de ma faute.

En tout cas, joyeuses fêtes, et plein de belles applications pour 2007.

[Tofalu]

Hello,

Juste une remarque :

Lorsqu'on ne veut bloquer que les champs de données, et pas, par exemple, le bouton tglChangeVue

Il est aussi possible de changer le type du recordset du formulaire à Instantanné.

[Papy Turbo]

Il est aussi possible de changer le type du recordset du formulaire à Instantanné.

Excellent
Méthode que je n'ai pas testée, donc, voir s'il y a des problèmes particuliers ?
Mais, a priori, ça me paraît une très bonne voie à explorer...

[Papy Turbo]

Aïe, aïe, aïe, hélas, ça pose un problème gênant du point de vue ergonomique : à chaque changement du (type de) recordset source, on va revenir sur le 1er enregistrement.
Bien sûr, on peut tout de suite derrière, refaire un FindFirst, pour revenir sur l'enregistrement qui était actif. Mais ça gêne l'utilisateur.
D'autant plus que, et je n'ai jamais compris pourquoi ???, dans ce genre d'exercice, on ne peut pas masquer les opérations :
La fonction Echo False ne marche pas. On voit toujours le 1er enregistrement s'afficher, puis, directement derrière, le FindFirst saute à nouveau. Très perturbant pour l'utilisateur.

Je peux me tromper, mais je me demande si, suite aux problèmes posés par (Docmd.)Echo False dans les anciennes versions, MS a peut être rétabli un Echo True à chaque changement d'enregistrement ???
Sous Access 97, avec un Echo False, on ne voyait plus rien, même dans les fenêtres de code en mode pas à pas , puisqu'elles étaient intégrées dans le même environnement que les formulaires.
Si c'est vrai, ce changement non documenté daterait d'Access 2000, quand DoCmd.Echo est devenu Application.Echo, et que le problème ne se posait plus , grâce au nouvel environnement VBA (l'IDE).

[Serge57]

Suite à tous ces cours délivrés par Papy-Turbo (que je remercie BEAUCOUP pour ses astuces et sa patience), je me suis lancé dans une nouvelle PETITE application (gestion documentaire). Bien sûr en utilisant le turbo-formulaire pour la création des l’enregistrements avec tout ce qui va bien et tout ce que j’ai appris sur ce site.
Mais voilà Problème …
Cette base est utilisée par plusieurs utilisateurs dans l’entreprise juste pour la visualisation des enregistrements.
Faut-il créer un nouveau formulaire spécifique pour la visu ?
Si OUI,
Cela implique une maintenance des 2 formulaires.
Sous quelle forme ?
Comment passer rapidement d’un formulaire de Visu à un formulaire de SAISIE ?

Si NON,
Petit Hic sur la liste de choix déroulante.
Je m’explique : La personne « Toto » a quitté l’entreprise, mais par contre elle a participé a la maintenance du document « sur la lune ». Comment faire pour voir (dans le formulaire) son nom sur la maintenance du document « sur la lune » et ne pas la trouver lors de la création d’un nouveau document sur le même formulaire ?.

Papy-Turbo va me faire la remarque qu’il ne faut pas courir plusieurs lièvres à la fois, mais ces interrogations m’emmer……. depuis longtemps.

[Papy Turbo]

Tiens, une question de Serge
Ça fait plaisir de voir que tu travailles un peu entre les cours. Non, je rigole.

Comment passer rapidement d’un formulaire de Visu à un formulaire de SAISIE ?

Question classique et assez simple : dans les propriétés du formulaire de saisie (sur un turbo-form, pas le conteneur principal !), onglet Données :
- Modif autorisée = non
- Suppression autorisée = Non
- Ajout autorisé = Non
- Entrée données = Non
Tu peux évidemment programmer tout ça, pour une + grande souplesse :
- ajoute un paramètre dans notre table de paramètres -> vrai si lecture seule, faux si saisie autorisée...
- à l'ouverture de chaque formulaire concerné, vérifie la valeur du paramètre et applique les propriétés AllowEdits, AllowAdditions, AllowDeletions et DataEntry
Tout ça paraît bien simple, et ça l'est.
Sauf si tu as, sur ce formulaire, la moindre case à cocher, bouton bascule (par exemple pour faire basculer un sous-formulaire entre les vues datasheet et form !) ou similaire : avec la méthode ci-dessus, tu ne peux plus faire basculer ton bouton !
Dans ce cas, pas d'autre solution que de bloquer tous les contrôles (Locked = True) dans une boucle.
Tu peux très facilement écrire une sub qui parcourt tous les contrôles et bloque/débloque tous les contrôles sauf ceux que tu veux garder actifs, avec un Select Case par nom de contrôle, ou par type de contrôle (tous sauf les toggle buttons, par exemple).

Je m’explique : La personne « Toto » a quitté l’entreprise, mais par contre elle a participé a la maintenance du document « sur la lune ». Comment faire pour voir (dans le formulaire) son nom sur la maintenance du document « sur la lune » et ne pas la trouver lors de la création d’un nouveau document sur le même formulaire ?

Si je comprends bien,
- "Toto" figure avec d'autres dans une table [Utilisateurs], [Employés] ou similaire
- il manque juste une indication de sortie : soit une simple case à cocher [Parti], soit une date de sortie (Nulle pour les actifs).
Tu peux alors faire, pour la saisie de nouveaux docs, une liste déroulante n'affichant que les actifs.