Nous avons un ensemble de projets (autout du même métier) assez conséquants
en WD55 : plus d'une centaine de fichiers HF, le même ordre de grandeur en
terme de fenêtres, et un sacré paquet de procédures globales (env. 100 à 150
à vue de nez) partagées via 3 dictionnaires.
Les dictionnaires sont partagés sur un poste dédié en W2k, qui sert aussi à
produire les version à mettre en exploitation, mais qui se tourne les pouces
le reste du temps. Le soucis est que depuis nos postes de développement (W2k
et XP-Pro), les temps d'accès aux dictionnaires sont catastrophiques lors
d'une sauvegarde ou de l'exécution en debug ! Et ce n'est pas un pb de
réseau, c'est du beau 100Mbits avec switches, ... et tout fonctionne très
bien à part les temps de réponses des dico (qui contiennent pas mal de monde
il faut l'admettre), pas de saturation de bande passante, par de pb de
trames perdues... il n'y a qu'avec les dicos qu'on a des soucis (et on a
déjà changé le pc).
La question est : est-ce qu'avec Windev 7.5 il y a une amélioration de la
gestion des dicos ? Je parle d'une changement radical en temps de réponse,
pas d'un léger mieux. Je sais que les dicos 75 et 55 ne sont pas compatibles
(et pas migrés automatiquements...), j'ai donc un maire espoir. La question
est d'importance, car si notre projet en WD55 sera migré en WD75, la
question d'utiliser un autre outil de dev pourrait se poser pour de nouveaux
projets. Mon propos à ce sujet s'arrêtera là, je ne veux pas être traité de
Troll :o)
Je précise aussi que la question porte sur des dicos et des projets de
taille "respectables", les temps de réponses augmentant très
significativement avec le volume des procédures partagées via des dicos.
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
Fabrice Burghgraeve
salut.
"Sam (au boulot)" a écrit dans le message de news:blrikk$b6d$
Bonjour,
en WD55 : plus d'une centaine de fichiers HF, le même ordre de grandeur en
(...)
Le soucis est que depuis nos postes de développement (W2k et XP-Pro), les temps d'accès aux dictionnaires sont catastrophiques lors d'une sauvegarde ou de l'exécution en debug ! Et ce n'est pas un pb de
(...) On avait le meme probleme, si ca peut vous rassurer. C'etait l'horreur a chaque ouverture de projet...
(...)
Alors les dico en 75 ? Mieux ou pas ?
Il y a peu, c'etait 10 fois pire, car on pouvait tres facilement arriver a des desynchronisations et a des regressions de code (le code qui revient a son etat d'il y a 6 mois... ca fait toujours plaisir...)
Je reteste ca en 203m, et je dis quoi ici...
A part ca, pour migrer le dictionnaire 5.5, avant de se rendre compte que celui de 7.5 etait encore pire, on a procede de la maniere suivante : on a crée en 5.5 un projet qui s'appelle "tout le dico". On y a incorpore toutes les classes et les procedures de notre dictionnaire 5.5 apres, on l'a migre. Apres, depuis le projet migre, on a tout remis dans un dictionnaire 7.5 Puis, pour chaque projet, on s'est amuse a enlever toutes ces classes et toutes ces procedures, puis a les reprendre du dictionnaire... (vachement drole comme jeu... Et on peut rejouer pour chaque projet c'est ca qui est bien)
A l'heure actuelle, on procede autrement en 7.5 et ca va bien quand meme, sauf pour les procedures, ou c'etait quand meme mieux avec le dictionnaire. A mon avis, le dictionnaire est une tres bonne idee, et le meilleur moyen de partager du code etc ... En theorie... mais en pratique...
Toutefois, les repertoires partages pour les clases et fenetres, ca va aussi bien qu'avec le dico, je dois dire. Mais pour les procedures, c'est moins bien, car il faut faire des collections... Du coup, on ne peut pas prendre uniquement les procedures qu'on veut, mais toutes celles de la collection. Du coup, pour pas avoir d'erreur de compil, on est oblige de mettre pour ainsi dire toutes les classes dans chaque projet.... On avait fait ca temporairement, mais ca commence a faire un moment que ca dure...
Donc je refais le test du dictionnaire en 7.5 203m, et je dis ce que j'ai trouve des fois qu'il y aurait eu des ameliorations depuis la derniere version ou je l'ai teste...
Merci d'avance. Sam.
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
salut.
"Sam (au boulot)" <s.gay@nospam.envergure-conseil.com> a écrit dans le
message de news:blrikk$b6d$1@s1.read.news.oleane.net...
Bonjour,
en WD55 : plus d'une centaine de fichiers HF, le même ordre de grandeur en
(...)
Le soucis est que depuis nos postes de développement (W2k
et XP-Pro), les temps d'accès aux dictionnaires sont catastrophiques lors
d'une sauvegarde ou de l'exécution en debug ! Et ce n'est pas un pb de
(...)
On avait le meme probleme, si ca peut vous rassurer.
C'etait l'horreur a chaque ouverture de projet...
(...)
Alors les dico en 75 ? Mieux ou pas ?
Il y a peu, c'etait 10 fois pire, car on pouvait tres facilement arriver a
des desynchronisations et a des regressions de code (le code qui revient a
son etat d'il y a 6 mois... ca fait toujours plaisir...)
Je reteste ca en 203m, et je dis quoi ici...
A part ca, pour migrer le dictionnaire 5.5, avant de se rendre compte que
celui de 7.5 etait encore pire, on a procede de la maniere suivante :
on a crée en 5.5 un projet qui s'appelle "tout le dico".
On y a incorpore toutes les classes et les procedures de notre dictionnaire
5.5
apres, on l'a migre.
Apres, depuis le projet migre, on a tout remis dans un dictionnaire 7.5
Puis, pour chaque projet, on s'est amuse a enlever toutes ces classes et
toutes ces procedures, puis a les reprendre du dictionnaire... (vachement
drole comme jeu... Et on peut rejouer pour chaque projet c'est ca qui est
bien)
A l'heure actuelle, on procede autrement en 7.5 et ca va bien quand meme,
sauf pour les procedures, ou c'etait quand meme mieux avec le dictionnaire.
A mon avis, le dictionnaire est une tres bonne idee, et le meilleur moyen de
partager du code etc ... En theorie...
mais en pratique...
Toutefois, les repertoires partages pour les clases et fenetres, ca va aussi
bien qu'avec le dico, je dois dire.
Mais pour les procedures, c'est moins bien, car il faut faire des
collections... Du coup, on ne peut pas prendre uniquement les procedures
qu'on veut, mais toutes celles de la collection.
Du coup, pour pas avoir d'erreur de compil, on est oblige de mettre pour
ainsi dire toutes les classes dans chaque projet....
On avait fait ca temporairement, mais ca commence a faire un moment que ca
dure...
Donc je refais le test du dictionnaire en 7.5 203m, et je dis ce que j'ai
trouve des fois qu'il y aurait eu des ameliorations depuis la derniere
version ou je l'ai teste...
Merci d'avance.
Sam.
--
Fabrice Burghgraeve
Computer & Services
f_pas_de_spam_burghgraeve@computeretservices.com
(enlevez le _pas_de_spam_ pour me répondre en privé)
"Sam (au boulot)" a écrit dans le message de news:blrikk$b6d$
Bonjour,
en WD55 : plus d'une centaine de fichiers HF, le même ordre de grandeur en
(...)
Le soucis est que depuis nos postes de développement (W2k et XP-Pro), les temps d'accès aux dictionnaires sont catastrophiques lors d'une sauvegarde ou de l'exécution en debug ! Et ce n'est pas un pb de
(...) On avait le meme probleme, si ca peut vous rassurer. C'etait l'horreur a chaque ouverture de projet...
(...)
Alors les dico en 75 ? Mieux ou pas ?
Il y a peu, c'etait 10 fois pire, car on pouvait tres facilement arriver a des desynchronisations et a des regressions de code (le code qui revient a son etat d'il y a 6 mois... ca fait toujours plaisir...)
Je reteste ca en 203m, et je dis quoi ici...
A part ca, pour migrer le dictionnaire 5.5, avant de se rendre compte que celui de 7.5 etait encore pire, on a procede de la maniere suivante : on a crée en 5.5 un projet qui s'appelle "tout le dico". On y a incorpore toutes les classes et les procedures de notre dictionnaire 5.5 apres, on l'a migre. Apres, depuis le projet migre, on a tout remis dans un dictionnaire 7.5 Puis, pour chaque projet, on s'est amuse a enlever toutes ces classes et toutes ces procedures, puis a les reprendre du dictionnaire... (vachement drole comme jeu... Et on peut rejouer pour chaque projet c'est ca qui est bien)
A l'heure actuelle, on procede autrement en 7.5 et ca va bien quand meme, sauf pour les procedures, ou c'etait quand meme mieux avec le dictionnaire. A mon avis, le dictionnaire est une tres bonne idee, et le meilleur moyen de partager du code etc ... En theorie... mais en pratique...
Toutefois, les repertoires partages pour les clases et fenetres, ca va aussi bien qu'avec le dico, je dois dire. Mais pour les procedures, c'est moins bien, car il faut faire des collections... Du coup, on ne peut pas prendre uniquement les procedures qu'on veut, mais toutes celles de la collection. Du coup, pour pas avoir d'erreur de compil, on est oblige de mettre pour ainsi dire toutes les classes dans chaque projet.... On avait fait ca temporairement, mais ca commence a faire un moment que ca dure...
Donc je refais le test du dictionnaire en 7.5 203m, et je dis ce que j'ai trouve des fois qu'il y aurait eu des ameliorations depuis la derniere version ou je l'ai teste...
Merci d'avance. Sam.
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
Sam \(au boulot\)
Merci pour ce message, assez peu encourageant je dois le dire. La question de changer d'outil de développement risque alors de se poser très sérieusement....
Sam.
"Fabrice Burghgraeve" a écrit dans le message de news:blrmc3$3hp$
Merci pour ce message, assez peu encourageant je dois le dire. La question
de changer d'outil de développement risque alors de se poser très
sérieusement....
Sam.
"Fabrice Burghgraeve" <f_pas_de_spam_burghgraeve@computeretservices.com> a
écrit dans le message de news:blrmc3$3hp$1@news.nordnet.fr...
Merci pour ce message, assez peu encourageant je dois le dire. La question de changer d'outil de développement risque alors de se poser très sérieusement....
Sam.
"Fabrice Burghgraeve" a écrit dans le message de news:blrmc3$3hp$
Fabrice Burghgraeve
salut.
"Sam (au boulot)" a écrit dans le message de news:blu7vr$17e$
Merci pour ce message, assez peu encourageant je dois le dire. La question de changer d'outil de développement risque alors de se poser très sérieusement....
Sam.
J'ai pas encore eu le temps de faire serieusempent les tests, mais j'ai bricolé 10 minutes et effectivement c'est toujours pas encourageant... Mais j'ai pas bien re-cerné le(s) probleme(s)... Je serai un peu plus precis dans un prochain message quand j'aurais teste tout ce qui deconnait que j'avais deja publie, pour voir si ca continue...
Cela dit, comme je le disais precedemment, pour le partage des fenetre et des classes, ca va bien avec le repertoire partage... aussi bien que le dico en 5.5 pour les classes, et comme les fenetres ca allait pas du tout en 5.5 avec le dico... C'est surtout pour les procedures que c'est tres chiant... Si on voulait avoir a peu pres le meme comportement qu'avec le dictionnaire, il faudrait creer, dans un repertoire partagé, N collections avec une seule procedure dedans... (ridicule)
Par contre, ce qui devrait te faire reflechir, a mon avis, plus que le dictionnaire, c'est la migration. Si tu veux migrer tes projets (que je crois gros) de 5.5 en 7.5, la c'est la vraie misere.... (crois-en mon experience, ne crois pas les commerciaux pc-softien)
Sinon, pour des nouveaux projets, je dirais a l'heure actuelle, autant les commencer en 7.5 c'est quand meme mieux que 5.5 surtout au niveau du look des applis generees, mais egalement de l'ergonomie de windev...
A+ pour plus d'elements sur le dico ...
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
salut.
"Sam (au boulot)" <s.gay@nospam.envergure-conseil.com> a écrit dans le
message de news:blu7vr$17e$1@s1.read.news.oleane.net...
Merci pour ce message, assez peu encourageant je dois le dire. La question
de changer d'outil de développement risque alors de se poser très
sérieusement....
Sam.
J'ai pas encore eu le temps de faire serieusempent les tests, mais j'ai
bricolé 10 minutes et effectivement c'est toujours pas encourageant... Mais
j'ai pas bien re-cerné le(s) probleme(s)...
Je serai un peu plus precis dans un prochain message quand j'aurais teste
tout ce qui deconnait que j'avais deja publie, pour voir si ca continue...
Cela dit, comme je le disais precedemment, pour le partage des fenetre et
des classes, ca va bien avec le repertoire partage...
aussi bien que le dico en 5.5 pour les classes, et comme les fenetres ca
allait pas du tout en 5.5 avec le dico...
C'est surtout pour les procedures que c'est tres chiant...
Si on voulait avoir a peu pres le meme comportement qu'avec le dictionnaire,
il faudrait creer, dans un repertoire partagé, N collections avec une seule
procedure dedans... (ridicule)
Par contre, ce qui devrait te faire reflechir, a mon avis, plus que le
dictionnaire, c'est la migration.
Si tu veux migrer tes projets (que je crois gros) de 5.5 en 7.5, la c'est la
vraie misere....
(crois-en mon experience, ne crois pas les commerciaux pc-softien)
Sinon, pour des nouveaux projets, je dirais a l'heure actuelle, autant les
commencer en 7.5 c'est quand meme mieux que 5.5 surtout au niveau du look
des applis generees, mais egalement de l'ergonomie de windev...
A+ pour plus d'elements sur le dico ...
--
Fabrice Burghgraeve
Computer & Services
f_pas_de_spam_burghgraeve@computeretservices.com
(enlevez le _pas_de_spam_ pour me répondre en privé)
"Sam (au boulot)" a écrit dans le message de news:blu7vr$17e$
Merci pour ce message, assez peu encourageant je dois le dire. La question de changer d'outil de développement risque alors de se poser très sérieusement....
Sam.
J'ai pas encore eu le temps de faire serieusempent les tests, mais j'ai bricolé 10 minutes et effectivement c'est toujours pas encourageant... Mais j'ai pas bien re-cerné le(s) probleme(s)... Je serai un peu plus precis dans un prochain message quand j'aurais teste tout ce qui deconnait que j'avais deja publie, pour voir si ca continue...
Cela dit, comme je le disais precedemment, pour le partage des fenetre et des classes, ca va bien avec le repertoire partage... aussi bien que le dico en 5.5 pour les classes, et comme les fenetres ca allait pas du tout en 5.5 avec le dico... C'est surtout pour les procedures que c'est tres chiant... Si on voulait avoir a peu pres le meme comportement qu'avec le dictionnaire, il faudrait creer, dans un repertoire partagé, N collections avec une seule procedure dedans... (ridicule)
Par contre, ce qui devrait te faire reflechir, a mon avis, plus que le dictionnaire, c'est la migration. Si tu veux migrer tes projets (que je crois gros) de 5.5 en 7.5, la c'est la vraie misere.... (crois-en mon experience, ne crois pas les commerciaux pc-softien)
Sinon, pour des nouveaux projets, je dirais a l'heure actuelle, autant les commencer en 7.5 c'est quand meme mieux que 5.5 surtout au niveau du look des applis generees, mais egalement de l'ergonomie de windev...
A+ pour plus d'elements sur le dico ...
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
Sam \(au boulot\)
Merci pour ces précisions, et j'attends les news avec impatience.
Concernant la migration j'ai déjà un apperçu, ayant étudié la question et migrés quelques bouts de codes et fenêtres pour évaluer le truc. Je pense que l'aspect "non rigoureux" de Windev 5.5 ne permet pas de faire une migration automatique très simple. Cela dis avoir un code propre au départ ça aide beaucoup... même s'il reste des choses à faire à la main...
Merci pour ces précisions, et j'attends les news avec impatience.
Concernant la migration j'ai déjà un apperçu, ayant étudié la question et
migrés quelques bouts de codes et fenêtres pour évaluer le truc. Je pense
que l'aspect "non rigoureux" de Windev 5.5 ne permet pas de faire une
migration automatique très simple. Cela dis avoir un code propre au départ
ça aide beaucoup... même s'il reste des choses à faire à la main...
Merci pour ces précisions, et j'attends les news avec impatience.
Concernant la migration j'ai déjà un apperçu, ayant étudié la question et migrés quelques bouts de codes et fenêtres pour évaluer le truc. Je pense que l'aspect "non rigoureux" de Windev 5.5 ne permet pas de faire une migration automatique très simple. Cela dis avoir un code propre au départ ça aide beaucoup... même s'il reste des choses à faire à la main...
Fabrice Burghgraeve
salut.
"Sam (au boulot)" a écrit dans le message de news:bm0vtp$n6i$
Merci pour ces précisions, et j'attends les news avec impatience.
Concernant la migration j'ai déjà un apperçu, ayant étudié la question et migrés quelques bouts de codes et fenêtres pour évaluer le truc. Je pense que l'aspect "non rigoureux" de Windev 5.5 ne permet pas de faire une
windev 7.5 n'est pas plus rigoureux.
migration automatique très simple. Cela dis avoir un code propre au départ ça aide beaucoup... même s'il reste des choses à faire à la main...
C'est vrai que ca aide... Mais ne crois pas que ca fait tout. Il reste beaucoup de choses a faire a la main, et enormement de changement de comportements qui font que en gros, t'es oblige de tout retester de A a Z (exemples : - toutes les tables memoire sont a reprendre pour contourner les nouveaux bugs de windev 7.5 - eventuelement, l'ordre d'init des champs/fenetre etc peut changer, et du coup boum ca deconne pour par exemple des combos alimentees en init de la fenetre, et initialisees en init de champs... - fonctions d'editions qui changent - appels aux APIs a restester dans tous les sens, en mode test ET en mode executable (j'ai eu le cas d'une routine qui fonctionnait en test et pas en exe))
Bref, la migration est rapide *grosso-modo* Mais (surtout si tu programmes pour des clients), il faut ensuite enormement de temps pour corriger les bugs/chagements de comportement qui n'apparaissent que dans quelques cas mais rendent le programme non utilisable completement...
Ainsi, pour un programme (bien ecrit bien sur ;-) ) de environ 1 an et demi-2ans de travail, compter 3 mois de boulot pour le migrer... (non productif. Juste pour refaire fonctionner ce qui fonctionnait deja)
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
salut.
"Sam (au boulot)" <s.gay@nospam.envergure-conseil.com> a écrit dans le
message de news:bm0vtp$n6i$1@s1.read.news.oleane.net...
Merci pour ces précisions, et j'attends les news avec impatience.
Concernant la migration j'ai déjà un apperçu, ayant étudié la question et
migrés quelques bouts de codes et fenêtres pour évaluer le truc. Je pense
que l'aspect "non rigoureux" de Windev 5.5 ne permet pas de faire une
windev 7.5 n'est pas plus rigoureux.
migration automatique très simple. Cela dis avoir un code propre au départ
ça aide beaucoup... même s'il reste des choses à faire à la main...
C'est vrai que ca aide...
Mais ne crois pas que ca fait tout.
Il reste beaucoup de choses a faire a la main, et enormement de changement
de comportements qui font que en gros, t'es oblige de tout retester de A a Z
(exemples :
- toutes les tables memoire sont a reprendre pour contourner les nouveaux
bugs de windev 7.5
- eventuelement, l'ordre d'init des champs/fenetre etc peut changer, et du
coup boum ca deconne pour par exemple des combos alimentees en init de la
fenetre, et initialisees en init de champs...
- fonctions d'editions qui changent
- appels aux APIs a restester dans tous les sens, en mode test ET en mode
executable (j'ai eu le cas d'une routine qui fonctionnait en test et pas en
exe))
Bref, la migration est rapide *grosso-modo*
Mais (surtout si tu programmes pour des clients), il faut ensuite enormement
de temps pour corriger les bugs/chagements de comportement qui
n'apparaissent que dans quelques cas mais rendent le programme non
utilisable completement...
Ainsi, pour un programme (bien ecrit bien sur ;-) ) de environ 1 an et
demi-2ans de travail, compter 3 mois de boulot pour le migrer... (non
productif. Juste pour refaire fonctionner ce qui fonctionnait deja)
--
Fabrice Burghgraeve
Computer & Services
f_pas_de_spam_burghgraeve@computeretservices.com
(enlevez le _pas_de_spam_ pour me répondre en privé)
"Sam (au boulot)" a écrit dans le message de news:bm0vtp$n6i$
Merci pour ces précisions, et j'attends les news avec impatience.
Concernant la migration j'ai déjà un apperçu, ayant étudié la question et migrés quelques bouts de codes et fenêtres pour évaluer le truc. Je pense que l'aspect "non rigoureux" de Windev 5.5 ne permet pas de faire une
windev 7.5 n'est pas plus rigoureux.
migration automatique très simple. Cela dis avoir un code propre au départ ça aide beaucoup... même s'il reste des choses à faire à la main...
C'est vrai que ca aide... Mais ne crois pas que ca fait tout. Il reste beaucoup de choses a faire a la main, et enormement de changement de comportements qui font que en gros, t'es oblige de tout retester de A a Z (exemples : - toutes les tables memoire sont a reprendre pour contourner les nouveaux bugs de windev 7.5 - eventuelement, l'ordre d'init des champs/fenetre etc peut changer, et du coup boum ca deconne pour par exemple des combos alimentees en init de la fenetre, et initialisees en init de champs... - fonctions d'editions qui changent - appels aux APIs a restester dans tous les sens, en mode test ET en mode executable (j'ai eu le cas d'une routine qui fonctionnait en test et pas en exe))
Bref, la migration est rapide *grosso-modo* Mais (surtout si tu programmes pour des clients), il faut ensuite enormement de temps pour corriger les bugs/chagements de comportement qui n'apparaissent que dans quelques cas mais rendent le programme non utilisable completement...
Ainsi, pour un programme (bien ecrit bien sur ;-) ) de environ 1 an et demi-2ans de travail, compter 3 mois de boulot pour le migrer... (non productif. Juste pour refaire fonctionner ce qui fonctionnait deja)
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
Fabrice Burghgraeve
salut.
"Sam (au boulot)" a écrit dans le message de news:bm0vtp$n6i$
Merci pour ces précisions, et j'attends les news avec impatience.
desole je suis un peu surbooke en ce moment, mais la j'ai quelques temps et je commence les tests.
deja, premier probleme, qui ne genere pas de desynchro, mais que personnelement je trouve bien chiant, et qui est redhibitoire a l'usage je pense :
le test de concordance entre le dico et le projet se fait au moment ou on ferme le projet ou le code en question, pas quand on l'ouvre.
j'explique : j'ai fait deux projets d'une fenetre avec un bouton qui fait "ferme()" j'ai cree une procedure dans la collections de procedures globales d'un projet. je l'ai mise dans le dico... re l'ai reprise dans l'autre projet. a chaque fois, je dis qu'il faut gerer les abonnements bien sur.
on est dans le projet 1 on fait une modification du code partage par le dico. on quitte : il propose de mettre a jour le dico. on le met a jour. on ouvre le projet 2, puis on ouvre le meme code.
il ne dit rien... (dans mon idee, il devrait faire apparaitre la fenetre d'abonnement a ce moment)
du coup, on modifie le code, puisque rien ne dit que le code qu'on modifie n'est plus a jour....... quand on ferme le code ou le projet, a ce moment la, il verifie l'abonnement. et HOP ! conflit... (forcement)
c'est tout con ce truc. J'ai trouve un contournement... il faut ouvrir un code, le refermer tout de suite (pour qu'il fasse l'abonnement), puis le re-ouvrir...
voila la premiere remarque... je fouille encore parce que ca c'est pas pratique, mais c'est pas non plus dramatique...
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
salut.
"Sam (au boulot)" <s.gay@nospam.envergure-conseil.com> a écrit dans le
message de news:bm0vtp$n6i$1@s1.read.news.oleane.net...
Merci pour ces précisions, et j'attends les news avec impatience.
desole je suis un peu surbooke en ce moment, mais la j'ai quelques temps et
je commence les tests.
deja, premier probleme, qui ne genere pas de desynchro, mais que
personnelement je trouve bien chiant, et qui est redhibitoire a l'usage je
pense :
le test de concordance entre le dico et le projet se fait au moment ou on
ferme le projet ou le code en question, pas quand on l'ouvre.
j'explique :
j'ai fait deux projets d'une fenetre avec un bouton qui fait "ferme()"
j'ai cree une procedure dans la collections de procedures globales d'un
projet.
je l'ai mise dans le dico...
re l'ai reprise dans l'autre projet.
a chaque fois, je dis qu'il faut gerer les abonnements bien sur.
on est dans le projet 1
on fait une modification du code partage par le dico.
on quitte : il propose de mettre a jour le dico.
on le met a jour.
on ouvre le projet 2, puis on ouvre le meme code.
il ne dit rien...
(dans mon idee, il devrait faire apparaitre la fenetre d'abonnement a ce
moment)
du coup, on modifie le code, puisque rien ne dit que le code qu'on modifie
n'est plus a jour.......
quand on ferme le code ou le projet,
a ce moment la, il verifie l'abonnement.
et HOP !
conflit... (forcement)
c'est tout con ce truc.
J'ai trouve un contournement...
il faut ouvrir un code, le refermer tout de suite (pour qu'il fasse
l'abonnement), puis le re-ouvrir...
voila la premiere remarque...
je fouille encore parce que ca c'est pas pratique, mais c'est pas non plus
dramatique...
--
Fabrice Burghgraeve
Computer & Services
f_pas_de_spam_burghgraeve@computeretservices.com
(enlevez le _pas_de_spam_ pour me répondre en privé)
"Sam (au boulot)" a écrit dans le message de news:bm0vtp$n6i$
Merci pour ces précisions, et j'attends les news avec impatience.
desole je suis un peu surbooke en ce moment, mais la j'ai quelques temps et je commence les tests.
deja, premier probleme, qui ne genere pas de desynchro, mais que personnelement je trouve bien chiant, et qui est redhibitoire a l'usage je pense :
le test de concordance entre le dico et le projet se fait au moment ou on ferme le projet ou le code en question, pas quand on l'ouvre.
j'explique : j'ai fait deux projets d'une fenetre avec un bouton qui fait "ferme()" j'ai cree une procedure dans la collections de procedures globales d'un projet. je l'ai mise dans le dico... re l'ai reprise dans l'autre projet. a chaque fois, je dis qu'il faut gerer les abonnements bien sur.
on est dans le projet 1 on fait une modification du code partage par le dico. on quitte : il propose de mettre a jour le dico. on le met a jour. on ouvre le projet 2, puis on ouvre le meme code.
il ne dit rien... (dans mon idee, il devrait faire apparaitre la fenetre d'abonnement a ce moment)
du coup, on modifie le code, puisque rien ne dit que le code qu'on modifie n'est plus a jour....... quand on ferme le code ou le projet, a ce moment la, il verifie l'abonnement. et HOP ! conflit... (forcement)
c'est tout con ce truc. J'ai trouve un contournement... il faut ouvrir un code, le refermer tout de suite (pour qu'il fasse l'abonnement), puis le re-ouvrir...
voila la premiere remarque... je fouille encore parce que ca c'est pas pratique, mais c'est pas non plus dramatique...
-- Fabrice Burghgraeve Computer & Services
(enlevez le _pas_de_spam_ pour me répondre en privé)
