[WD75 203m] encore un bug dans les tables en saisie !!! (interrupteur)

Le
Fabrice Burghgraeve
Bonjour.

Je ne dirais jamais assez tout le mal que je pense de la gestion des tables
en saisie en windev.
C'est archi-truffé de bugs

Pourtant, je ne pense pas que ce soit quelque chose de particulierement
rarement utilisé.
Au contraire, je suis plutot tenté de croire que c'est tres utilisé,
je dirais meme que c'est une fonctionnalite de base.
donc je ne comprends pas pourquoi ces bugs persistent encore et toujours

bon la j'en ai trouve un nouveau, qui peut etre pas mal point de vue
consequences

j'ai une table qui a trois colonnes :
une colonne de type texte, puis deux de type interrupteur.

le but est de nettoyer des repertoires.
le programme commence par lister des repertoires dans la premieres colonne,
puis positionne l'interrupteur dans la 2ieme colonne pour savoir si le
repertoire est propre
apres ca, l'utilisateur coche ou non l'interrupteur de la troisieme colonne
pour dire si il veut nettoyer le repertoire en question, puis lance le
nettoyage.

donc, l'utilisateur ne peut modifier que la troisieme colonne en cliquant
dans l'interrupteur.

Pour arriver a ce but, j'ai donc mis une table en saisie, avec selection
simple.
les deux premieres colonnes ne sont pas en saisie, mais la troisieme si

Jusqu'ici, tout va bien. l'utilisateur clique dans la case, ca coche ou
decoche
il clique dans la 2ieme colonne, ca fait rien

par contre, la ou il y a un GROS BUG, c'est que quand la ligne est
selectionnee,
si on appuye sur <ESPACE>, la deuxieme colonne se coche ou se decoche
!!!!!!!!! (elle est en affichage !!!)
et pas la troisieme !!!

damned !!! vraiment de la saloperie ces tables en saisie

j'ai trouve deux contournements :
1er contournement : mettre la table "sans selection", mais ca ne va pas car
on ne voit pas bien sur quelle ligne on est, surtout quand on manipule
l'appli avec le clavier.

2ieme contournement (qui a l'air d'aller mieux):
mettre ce code la a chaque modif de l'interrupteur :
SI MoiMême=Vrai ALORS MoiMêmeux SINON MoiMême=Vrai

ooooooh c'est boooooooooo

Il n'empeche que je trouve ca pas normal du tout que quand on veut utiliser
une table en saisie, on doive ecrire PLUS de code de contournement que de
code "utile"
(Mais ca je l'avais deja dit avec les autres bugs)

surtout pour une fonctionnalite "de base".

Pour un soit-disant L5G, on pourrait s'attendre a ce qu'il sache gerer
correctement une table
meme pas

voila c'est dit j'ai bien ralé je retourne contourner dix fois plus vite

--
Fabrice Burghgraeve
Computer & Services
f_pas_de_spam_burghgraeve@computeretservices.com
(enlevez le _pas_de_spam_ pour me répondre en privé)
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
R&B
Le #12928811
Salut Fabrice,

C'est donc bien la rentrée !


En plus de tes pb de curseur, n'as tu pas de problème de blocage ? c'est
parfait si non.
En effet tu peux entrer en modif d'un même enregistrement depuis deux
poste... et valider ! si la validation n'a lieu en même temps : ok,
message, sinon le dernier qui à écrit à raison (comme pour le RAD
d'ailleurs).
Cela ne choque jamais personne non plus ?
Je sais que la tentative de blocage avant d'entrer en modif met la base
en situation d'attente (qui est à éviter). mais c'est aussi une garantie
contre les collisions de modifs.

Les tables, c'est pour présenter les enregistrements en liste, pour
saisir les infos le mieux reste la fiche et en plus on limite la
diffusion des contôles dans le soft.

Donc si un conseil peut aider : éviter les tables fichiers en saisie.
En tout cas, sans critique, j'ai abandonné pour ces raisons.

@+ R&B



Fabrice Burghgraeve wrote:
Bonjour.

Je ne dirais jamais assez tout le mal que je pense de la gestion des tables
en saisie en windev.
C'est archi-truffé de bugs...

Pourtant, je ne pense pas que ce soit quelque chose de particulierement
rarement utilisé.
Au contraire, je suis plutot tenté de croire que c'est tres utilisé,
je dirais meme que c'est une fonctionnalite de base.
donc je ne comprends pas pourquoi ces bugs persistent encore et toujours...

bon la j'en ai trouve un nouveau, qui peut etre pas mal point de vue
consequences...

j'ai une table qui a trois colonnes :
une colonne de type texte, puis deux de type interrupteur.

le but est de nettoyer des repertoires.
le programme commence par lister des repertoires dans la premieres colonne,
puis positionne l'interrupteur dans la 2ieme colonne pour savoir si le
repertoire est propre...
apres ca, l'utilisateur coche ou non l'interrupteur de la troisieme colonne
pour dire si il veut nettoyer le repertoire en question, puis lance le
nettoyage.

donc, l'utilisateur ne peut modifier que la troisieme colonne en cliquant
dans l'interrupteur.

Pour arriver a ce but, j'ai donc mis une table en saisie, avec selection
simple.
les deux premieres colonnes ne sont pas en saisie, mais la troisieme si...

Jusqu'ici, tout va bien. l'utilisateur clique dans la case, ca coche ou
decoche...
il clique dans la 2ieme colonne, ca fait rien...

par contre, la ou il y a un GROS BUG, c'est que quand la ligne est
selectionnee,
si on appuye sur <ESPACE>, la deuxieme colonne se coche ou se decoche
!!!!!!!!! (elle est en affichage !!!)
et pas la troisieme !!!

damned !!! vraiment de la saloperie ces tables en saisie...

j'ai trouve deux contournements :
1er contournement : mettre la table "sans selection", mais ca ne va pas car
on ne voit pas bien sur quelle ligne on est, surtout quand on manipule
l'appli avec le clavier.

2ieme contournement (qui a l'air d'aller mieux):
mettre ce code la a chaque modif de l'interrupteur :
SI MoiMême=Vrai ALORS MoiMêmeúux SINON MoiMême=Vrai

ooooooh c'est boooooooooo...

Il n'empeche que je trouve ca pas normal du tout que quand on veut utiliser
une table en saisie, on doive ecrire PLUS de code de contournement que de
code "utile"...
(Mais ca je l'avais deja dit avec les autres bugs)

surtout pour une fonctionnalite "de base".

Pour un soit-disant L5G, on pourrait s'attendre a ce qu'il sache gerer
correctement une table...
meme pas...

voila c'est dit j'ai bien ralé je retourne contourner dix fois plus vite...



R&B
Le #12928791
Fabrice Burghgraeve wrote:
salut.

"R&B" news:bj4csa$k4g$

Salut Fabrice,

C'est donc bien la rentrée !


En plus de tes pb de curseur, n'as tu pas de problème de blocage ? c'est
parfait si non.




Non aucun probleme de blocage.
et ce pour une raison tres simple :
je n'utilise pas hyperfile !!!!

par contre, une fois en regardant un bug pour quelqu'un il me semble me
souvenir qu'il y a aussi des problemes avec les filtres quand on trie les
colonnes...




Autre vaste sujet...

[...]
autre exemple :
dans notre appli, on cree des dossiers medicaux, dans lequels se trouvent n
prescripteurs, n preleveurs, etc, et surtout n analyses.
il peut y avoir bcp d'analyses (de l'ordre d'une trentaine, c'est pas rare.
d'une vingtaine c'est tres courant)

Pour toutes ces saises : des tables...
ca perdrait un temps dingue d'aller entrer a chaque fois dans une fiche pour
ajouter les analyses...
(200 fois 20 fois 1 seconde = 1 heure de perdue par jour, rien que pour
rentrer les analyses, avec le patient qui tape du pied devant la secretaire,
et la queue qui s'allonge)

Voila, c'est pourquoi je considere que les tables sont un element de base
dans un logiciel.
je les utilise beaucoup, parce que c'est ca qu'il *faut* utiliser dans
certains cas, sous peine d'avoir une ergonomie toute pourrie, incompatible
avec les contraintes de rapidite de notre logiciel.



Effectivement !
Je suis en plein dans un outil de synchronisation avec des pb symilaire
je vais utiliser un fichier pour voir ce qui peut être fait pour les
coche dans deux colonnes mais je pense que tu devrai gérer des touches
d'appel pour ces colonnes (l'espace pose des pb).

je vais aussi devoir travailler sur des sélections multiples (pour
coches/décoches)

je te tiens au courant d'ici qqes jours
[...]

Mais j'ai abandonné hyperfile avant meme de l'avoir commencé pour le meme
genre de raisons :)
Comme ca je suis pas choque par sa gestion des blocages et sa lenteur en
reseau :)

D'ailleurs, je sais pas si t'as vu "en face", mais ils passeroent bientot au
client/serveur...
ils ont peut etre quand meme compris finalement...



Les fuites vers les autres bases sont peut être une motivation,
l'hébergement hors windows aussi et enfin ouvrir bien grand les accès
distant devient critique. C'est donc une nécessité.

@+
Poster une réponse
Anonyme