Bonjour à tous,

Débutant dans le monde de WinDev, je tâtonne un peu pour mes premiers développements... et là justement, un petit souci que je n'arrive pas à endiguer m'amène à appeler au secours ! Je vais essayer d'être précis (en espérant ne pas être trop complexe non plus...)

Je développe une application reposant sur une BDD Hyper File (pour l'instant la base est locale), et j'ai commencé par un module permettant de gérer la liste des utilisateurs et leurs droits sur l'utilisation de l'application. Ma table Utilisateur est simple :

- IDUtilisateur (numéro automatique)
- Nom, Prenom, etc... (des champs chaîne)
- TypeUtilisateur (numérique sur 1 octet, définit les droits : 1=administrateur, 2=utilisateur type ...)
- login (chaîne mis en clé unique, car je ne veux pas de doublons et je fais des requêtes sur ce champ)
- pass (chaîne)

Une autre table RefTypeUtilisateur liée à la première associe TypeUtilisateur à sa dénomination réelle.

Le module administration est constitué d'une fenêtre principale, par laquelle on accède à la fenêtre de gestion des utilisateurs : c'est une fenêtre RAD de type Table. J'ai donc mes colonnes texte pour mes champs texte, et un combo pour choisir le type d'utilisateur (on choisit parmi "Administrateur", "Type 1",etc. et le code correspondant ("1", "2", etc.) est stocké dans la base).

Jusqu'ici, tout va bien ! Mais voilà le problème : je veux empêcher que l'administrateur courant puisse modifier son propre type. Pour cela, j'ai inséré au niveau de la colonne TypeUtilisateur de ma table, évènement "Sortie", le code suivant :



(UtilisateurX est un objet qui regroupe les infos de l'utilisateur courant, GetID() renvoie son identifiant dans la table)
En gros, je compare l'indice de la ligne de mon utilisateur à celui de la ligne dont on a modifié le type, si c'est le même ET que le type a été changé etn'est plus 1 (= "administrateur"), l'appli râle et on remet à 1.

Seulement tout cela marche bizarrement !

- si je modifie le type de l'utilisateur courant, ça marche, mais le "info() ne s'affiche pas

- si je modifie le type d'un autre utilisateur (on va dire User2, login=user2), c'est la grande panade ! Dès que je sors du combo modifié, j'ai d'abord une alerte doublon, qui me dit "attention, login 'user2' existe déjà, veuillez changer". Seulement, le seul endroit où j'ai 'user2', c'est au niveau de la ligne actuelle, celle dont je change le type...
On va dire que je change alors pour 'user2bis', et là, non seulement la ligne modifiée n'est pas modifiée, mais en plus, elle vient se copier sur la ligne de l'utilisateur courant ! (d'où le doublon de login, le nouveau login s'incrivant au niveau de l'utilisateur courant, et pas de la ligne modifiée).

Bref ça m'énervouille un peu ! je ne vois pas du tout d'où cela vient... Le RAD permet de faire de belles fenêtres très vite, mais si l'on ne peut facilement modifier leur contenu ensuite...

Voilà, j'espère avoir été le plus clair possible, merci d'avance pour votre aide !

Bonjour,

Une table fichier est directement relié à son enregistrements
toutes modification d'un de ses champs est enregistré lors du changement de ligne sauf si erreur doublon ou erreur intégrité.

Une table mémoire vous donne toute liberté puisque c'est à vous à reporter les modification apportées à la table vers le fichier.

Si vous utiliser le rad sur une table fichier il faut faudra utiliser le debugger pour comprendre ce qui se passe.

Pour une plus grande maitrise il est souvant plus simple d'utiliser les tables pour afficher et les formulaires pour toutes modifications.

Merci de votre réponse !

Effectivement, utiliser une table mémoire sera certainement bien plus propre (et puis je retrouve comme ça un mécanisme d'accès aux BDD plus proche de ce que je connais déjà par les autres langages de prog). Je vais m'y pencher !

Concernant le bug, j'ai déjà essayé de tracer le projet, sans succès ; les méthodes des classes créées par le RAD s'enchaînent sans que j'y comprenne grand-chose... Enfin si le problème de doublon fictif m'intrigue déjà, je suppose que la cause doit se dissimuler dans le micmac des méthodes de ces classes du RAD... Par contre, à y réfléchir, le fait que le info() de mon SI..ALORS ne passe pas (alors que la seconde ligne du SI est exécutée) m'étonne plus encore !

Enfin je crois que je vais laisser là le problème (tant pis pour ma curiosité, tant mieux pour mon mal de crâne), et passer par les tables mémoires - voire envisager de verrouiller les modifs sur les tables, et utiliser des formulaires comme vous l'avez suggéré.


Finalement, la question que je me pose après tout ça est : dois-je continuer à utiliser le RAD ? J'hésite, j'hésite...

- d'un côté, cela permet d'avoir (presque) ce que je veux très rapidement, et quand je vois l'ensemble des méthodes des classes créées (qui parlent de rafraichissement, utilisent des timers...), j'ai l'impression que de nombreux mécanismes auxquels je n'aurai jamais pensé sont implémentés de façon transparente...

- de l'autre, développer "à la main" me permet d'être souple, d'avoir pile ce que je veux, de comprendre plus facilement pourquoi ça marche... et donc, également, pourquoi ça ne marche pas ! (ça a des vertus éducatives !) Mais tant que je ne mesure pas la portée des mécanismes de rafraichissement et autres créés par le RAD, il est clair que je ne pourrai pas les implanter dans mes fenêtres.

Aussi, j'en appelle à votre expérience de WD : me conseillez-vous de continuer d'utiliser le RAD en modifiant ponctuellement mon code, ou de tout gérer manuellement (je penche maintenant vers cette solution) ? Toutes les méthodes créées par le RAD sont-elles réellement indispensables ?

Voilà, merci d'avance !

Bonjour,

RAD(Rapid Application Developpement)
Comme sont nom l'indique cela permet de créer rapidement une application à partir d'une description de base de données.
Je pense à mon avis que pour démarrer une application c'est très bien. Rien n'empêche ensuite de redévelopper ces fenêtres.

De plus depuis la version 9 de WinDev il est possible d'écrire son Propre RAD(a sa sauce)

Solution que j'utilise:
J'utilise les classes RAD fournis par PCSoft et je profite ainsi des evolutions futures des ces classes, Mais j'ai créé mes propres classes qui héritent des classes de PCSoft.
Ainsi, dans mes classes je créer des procédures virtuelles lorsque je veux détourner celle de pcsoft, et aussi, je rajoute des propriétées et des méthodes propres à mes classes.

Un dossier est disponile sur ce site pour cette pratique
Vous trouverez ce lien dans le dossier sur l'héritage de classe