[WD75 203m] encore un bug dans les tables en saisie !!! (interrupteur)
2 réponses
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ême=Faux 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é)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
R&B
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...
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...
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
Fabrice Burghgraeve wrote:
salut.
"R&B" a écrit dans le message de 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é.
@+
Fabrice Burghgraeve wrote:
salut.
"R&B" <info@rbesset.net> a écrit dans le message de
news:bj4csa$k4g$1@s1.read.news.oleane.net...
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é.
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é.
