[WD7.5 203m] projet qui change de place en restant a la meme place
3 réponses
Fabrice Burghgraeve
Bonjour.
Alors la j'en tiens un reproductible.
Quand on deplace son projet, windev 7.5 le voit et propose une mise a
niveau...
5.5 ne le faisait pas.
C'est vraiment super, notament quand on deplace son projet sur un ordi
portable par exemple, on est pas obige de se retaper le nom des images dans
chaque fenetre parce que le nom du disque a change.
Mais je viens de remarquer que ca n'est pas tout net.
Ainsi, en windev 5.5 pour travailler en cooperation, il fallait partager un
repertoire, et monter ce repertoire en disque reseau sur tous les postes.
En 7.5, il faut toujours partager un repertoire, mais on n'est pas oblige de
monter un lecteur reseau.
C'est mieux.
Sauf que si on ouvre une fois le projet depuis le "disque", puis qu'on
l'ouvre ensuite depuis le repertoire reseau, windev dit qu'il a change de
place, et il recompile tout.
Alors qu'il n'a pas change de place.
Donc ca ressemble a un bug...
Ca a pas l'air dramatique, mais je me demande si la cause de toutes nos
emmerdes du jour
(classes et fenetre qui changent de nom etc) ne viendraient pas de la.
En tout cas, dans le doute, on a pris la decision de toujours ouvrir les
projets de la meme maniere.
Je vais maintenant (ou demain plutot parce que la j'en ai ma claque) essayer
d'ouvrir en meme temps le meme projet, sur 2 postes differents, en passant
par 2 les deux chemins differents.
On verra ce que ca donne.
--
Fabrice Burghgraeve
Computer & Services
suivez ce lien pour me repondre en prive :
http://cerbermail.com/?I3GMPRuXDD
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
Stéphane Demerville
D'une manière générale, lorsque l'on partage un projet à plusieurs développeurs il faut partager le dossier où se trouve le projet. On peut lui associer un nouveau lecteur mais un chemin du type UNC NomMachineRépertoireprojet suufiit. Il faut utiliser ce procédé même si l'un des postes contient le projet en local (ex C:RépertoireProjet). En effet Windev stocke le chemin du projet. Si pour les postes du réseau il trouve NomMachine.... pas de problème, par contre pour le poste en local il détecte un chemin en C:..... C'est pour cette raison que l'on obtient le fameux message indiquant que le projet a été déplacé.
Ce qu'il faut retenir : Tous les postes qui accèdent au projet doivent y accéder opar le même chemin.
"Fabrice Burghgraeve" a écrit dans le message de news: bn6d1q$v1o$
Bonjour.
Alors la j'en tiens un reproductible.
Quand on deplace son projet, windev 7.5 le voit et propose une mise a niveau... 5.5 ne le faisait pas. C'est vraiment super, notament quand on deplace son projet sur un ordi portable par exemple, on est pas obige de se retaper le nom des images
dans
chaque fenetre parce que le nom du disque a change.
Mais je viens de remarquer que ca n'est pas tout net. Ainsi, en windev 5.5 pour travailler en cooperation, il fallait partager
un
repertoire, et monter ce repertoire en disque reseau sur tous les postes. En 7.5, il faut toujours partager un repertoire, mais on n'est pas oblige
de
monter un lecteur reseau. C'est mieux.
Sauf que si on ouvre une fois le projet depuis le "disque", puis qu'on l'ouvre ensuite depuis le repertoire reseau, windev dit qu'il a change de place, et il recompile tout. Alors qu'il n'a pas change de place. Donc ca ressemble a un bug...
Ca a pas l'air dramatique, mais je me demande si la cause de toutes nos emmerdes du jour (classes et fenetre qui changent de nom etc) ne viendraient pas de la.
En tout cas, dans le doute, on a pris la decision de toujours ouvrir les projets de la meme maniere.
Je vais maintenant (ou demain plutot parce que la j'en ai ma claque)
essayer
d'ouvrir en meme temps le meme projet, sur 2 postes differents, en passant par 2 les deux chemins differents.
On verra ce que ca donne.
-- Fabrice Burghgraeve Computer & Services suivez ce lien pour me repondre en prive : http://cerbermail.com/?I3GMPRuXDD
D'une manière générale, lorsque l'on partage un projet à plusieurs
développeurs il faut partager le dossier où se trouve le projet. On peut lui
associer un nouveau lecteur mais un chemin du type UNC
\NomMachineRépertoireprojet suufiit. Il faut utiliser ce procédé même si
l'un des postes contient le projet en local (ex C:RépertoireProjet). En
effet Windev stocke le chemin du projet. Si pour les postes du réseau il
trouve \NomMachine.... pas de problème, par contre pour le poste en local
il détecte un chemin en C:..... C'est pour cette raison que l'on obtient le
fameux message indiquant que le projet a été déplacé.
Ce qu'il faut retenir : Tous les postes qui accèdent au projet doivent y
accéder opar le même chemin.
"Fabrice Burghgraeve" <regardez.ma.signature@cette.adresse.est.bidon.com> a
écrit dans le message de news: bn6d1q$v1o$1@news.nordnet.fr...
Bonjour.
Alors la j'en tiens un reproductible.
Quand on deplace son projet, windev 7.5 le voit et propose une mise a
niveau...
5.5 ne le faisait pas.
C'est vraiment super, notament quand on deplace son projet sur un ordi
portable par exemple, on est pas obige de se retaper le nom des images
dans
chaque fenetre parce que le nom du disque a change.
Mais je viens de remarquer que ca n'est pas tout net.
Ainsi, en windev 5.5 pour travailler en cooperation, il fallait partager
un
repertoire, et monter ce repertoire en disque reseau sur tous les postes.
En 7.5, il faut toujours partager un repertoire, mais on n'est pas oblige
de
monter un lecteur reseau.
C'est mieux.
Sauf que si on ouvre une fois le projet depuis le "disque", puis qu'on
l'ouvre ensuite depuis le repertoire reseau, windev dit qu'il a change de
place, et il recompile tout.
Alors qu'il n'a pas change de place.
Donc ca ressemble a un bug...
Ca a pas l'air dramatique, mais je me demande si la cause de toutes nos
emmerdes du jour
(classes et fenetre qui changent de nom etc) ne viendraient pas de la.
En tout cas, dans le doute, on a pris la decision de toujours ouvrir les
projets de la meme maniere.
Je vais maintenant (ou demain plutot parce que la j'en ai ma claque)
essayer
d'ouvrir en meme temps le meme projet, sur 2 postes differents, en passant
par 2 les deux chemins differents.
On verra ce que ca donne.
--
Fabrice Burghgraeve
Computer & Services
suivez ce lien pour me repondre en prive :
http://cerbermail.com/?I3GMPRuXDD
D'une manière générale, lorsque l'on partage un projet à plusieurs développeurs il faut partager le dossier où se trouve le projet. On peut lui associer un nouveau lecteur mais un chemin du type UNC NomMachineRépertoireprojet suufiit. Il faut utiliser ce procédé même si l'un des postes contient le projet en local (ex C:RépertoireProjet). En effet Windev stocke le chemin du projet. Si pour les postes du réseau il trouve NomMachine.... pas de problème, par contre pour le poste en local il détecte un chemin en C:..... C'est pour cette raison que l'on obtient le fameux message indiquant que le projet a été déplacé.
Ce qu'il faut retenir : Tous les postes qui accèdent au projet doivent y accéder opar le même chemin.
"Fabrice Burghgraeve" a écrit dans le message de news: bn6d1q$v1o$
Bonjour.
Alors la j'en tiens un reproductible.
Quand on deplace son projet, windev 7.5 le voit et propose une mise a niveau... 5.5 ne le faisait pas. C'est vraiment super, notament quand on deplace son projet sur un ordi portable par exemple, on est pas obige de se retaper le nom des images
dans
chaque fenetre parce que le nom du disque a change.
Mais je viens de remarquer que ca n'est pas tout net. Ainsi, en windev 5.5 pour travailler en cooperation, il fallait partager
un
repertoire, et monter ce repertoire en disque reseau sur tous les postes. En 7.5, il faut toujours partager un repertoire, mais on n'est pas oblige
de
monter un lecteur reseau. C'est mieux.
Sauf que si on ouvre une fois le projet depuis le "disque", puis qu'on l'ouvre ensuite depuis le repertoire reseau, windev dit qu'il a change de place, et il recompile tout. Alors qu'il n'a pas change de place. Donc ca ressemble a un bug...
Ca a pas l'air dramatique, mais je me demande si la cause de toutes nos emmerdes du jour (classes et fenetre qui changent de nom etc) ne viendraient pas de la.
En tout cas, dans le doute, on a pris la decision de toujours ouvrir les projets de la meme maniere.
Je vais maintenant (ou demain plutot parce que la j'en ai ma claque)
essayer
d'ouvrir en meme temps le meme projet, sur 2 postes differents, en passant par 2 les deux chemins differents.
On verra ce que ca donne.
-- Fabrice Burghgraeve Computer & Services suivez ce lien pour me repondre en prive : http://cerbermail.com/?I3GMPRuXDD
dcara
"Fabrice Burghgraeve" wrote in message news:<bn6d1q$v1o$...
Bonjour.
Alors la j'en tiens un reproductible.
Quand on deplace son projet, windev 7.5 le voit et propose une mise a niveau... 5.5 ne le faisait pas. C'est vraiment super, notament quand on deplace son projet sur un ordi portable par exemple, on est pas obige de se retaper le nom des images dans chaque fenetre parce que le nom du disque a change.
Mais je viens de remarquer que ca n'est pas tout net. Ainsi, en windev 5.5 pour travailler en cooperation, il fallait partager un repertoire, et monter ce repertoire en disque reseau sur tous les postes. En 7.5, il faut toujours partager un repertoire, mais on n'est pas oblige de monter un lecteur reseau. C'est mieux.
Sauf que si on ouvre une fois le projet depuis le "disque", puis qu'on l'ouvre ensuite depuis le repertoire reseau, windev dit qu'il a change de place, et il recompile tout. Alors qu'il n'a pas change de place. Donc ca ressemble a un bug...
Ca a pas l'air dramatique, mais je me demande si la cause de toutes nos emmerdes du jour (classes et fenetre qui changent de nom etc) ne viendraient pas de la.
En tout cas, dans le doute, on a pris la decision de toujours ouvrir les projets de la meme maniere.
Je vais maintenant (ou demain plutot parce que la j'en ai ma claque) essayer d'ouvrir en meme temps le meme projet, sur 2 postes differents, en passant par 2 les deux chemins differents.
On verra ce que ca donne.
Ne t'inquiete pas, ca ne vient pas du changement de répertoire le changement de nom des éléments d'un projet.... Nous on a des projets en réseau partager entre plusieurs dévelopeurs et de temps en temps il nous renome des fenetre ou classe selon son humeur (sans pour autant avoir déplacer le projet). Généralement ce qu'on fait pour revenir à l'origine, on supprime l'élément renommer dans la liste des éléments du projet. On quitte le projet, on renomme le répertoire <<MonProjet.cpl>>, on ouvre le projet, il nous recompile tout puis on réintegre les éléments que nous avions supprimé. Aprés si tout refonctionne correctement on supprime le répertoire <<MonProjet.cpl>> qu'on avait renommé.
"Fabrice Burghgraeve" <regardez.ma.signature@cette.adresse.est.bidon.com> wrote in message news:<bn6d1q$v1o$1@news.nordnet.fr>...
Bonjour.
Alors la j'en tiens un reproductible.
Quand on deplace son projet, windev 7.5 le voit et propose une mise a
niveau...
5.5 ne le faisait pas.
C'est vraiment super, notament quand on deplace son projet sur un ordi
portable par exemple, on est pas obige de se retaper le nom des images dans
chaque fenetre parce que le nom du disque a change.
Mais je viens de remarquer que ca n'est pas tout net.
Ainsi, en windev 5.5 pour travailler en cooperation, il fallait partager un
repertoire, et monter ce repertoire en disque reseau sur tous les postes.
En 7.5, il faut toujours partager un repertoire, mais on n'est pas oblige de
monter un lecteur reseau.
C'est mieux.
Sauf que si on ouvre une fois le projet depuis le "disque", puis qu'on
l'ouvre ensuite depuis le repertoire reseau, windev dit qu'il a change de
place, et il recompile tout.
Alors qu'il n'a pas change de place.
Donc ca ressemble a un bug...
Ca a pas l'air dramatique, mais je me demande si la cause de toutes nos
emmerdes du jour
(classes et fenetre qui changent de nom etc) ne viendraient pas de la.
En tout cas, dans le doute, on a pris la decision de toujours ouvrir les
projets de la meme maniere.
Je vais maintenant (ou demain plutot parce que la j'en ai ma claque) essayer
d'ouvrir en meme temps le meme projet, sur 2 postes differents, en passant
par 2 les deux chemins differents.
On verra ce que ca donne.
Ne t'inquiete pas, ca ne vient pas du changement de répertoire le
changement de nom des éléments d'un projet....
Nous on a des projets en réseau partager entre plusieurs dévelopeurs
et de temps en temps il nous renome des fenetre ou classe selon son
humeur (sans pour autant avoir déplacer le projet).
Généralement ce qu'on fait pour revenir à l'origine, on supprime
l'élément renommer dans la liste des éléments du projet. On quitte le
projet, on renomme le répertoire <<MonProjet.cpl>>, on ouvre le
projet, il nous recompile tout puis on réintegre les éléments que nous
avions supprimé.
Aprés si tout refonctionne correctement on supprime le répertoire
<<MonProjet.cpl>> qu'on avait renommé.
"Fabrice Burghgraeve" wrote in message news:<bn6d1q$v1o$...
Bonjour.
Alors la j'en tiens un reproductible.
Quand on deplace son projet, windev 7.5 le voit et propose une mise a niveau... 5.5 ne le faisait pas. C'est vraiment super, notament quand on deplace son projet sur un ordi portable par exemple, on est pas obige de se retaper le nom des images dans chaque fenetre parce que le nom du disque a change.
Mais je viens de remarquer que ca n'est pas tout net. Ainsi, en windev 5.5 pour travailler en cooperation, il fallait partager un repertoire, et monter ce repertoire en disque reseau sur tous les postes. En 7.5, il faut toujours partager un repertoire, mais on n'est pas oblige de monter un lecteur reseau. C'est mieux.
Sauf que si on ouvre une fois le projet depuis le "disque", puis qu'on l'ouvre ensuite depuis le repertoire reseau, windev dit qu'il a change de place, et il recompile tout. Alors qu'il n'a pas change de place. Donc ca ressemble a un bug...
Ca a pas l'air dramatique, mais je me demande si la cause de toutes nos emmerdes du jour (classes et fenetre qui changent de nom etc) ne viendraient pas de la.
En tout cas, dans le doute, on a pris la decision de toujours ouvrir les projets de la meme maniere.
Je vais maintenant (ou demain plutot parce que la j'en ai ma claque) essayer d'ouvrir en meme temps le meme projet, sur 2 postes differents, en passant par 2 les deux chemins differents.
On verra ce que ca donne.
Ne t'inquiete pas, ca ne vient pas du changement de répertoire le changement de nom des éléments d'un projet.... Nous on a des projets en réseau partager entre plusieurs dévelopeurs et de temps en temps il nous renome des fenetre ou classe selon son humeur (sans pour autant avoir déplacer le projet). Généralement ce qu'on fait pour revenir à l'origine, on supprime l'élément renommer dans la liste des éléments du projet. On quitte le projet, on renomme le répertoire <<MonProjet.cpl>>, on ouvre le projet, il nous recompile tout puis on réintegre les éléments que nous avions supprimé. Aprés si tout refonctionne correctement on supprime le répertoire <<MonProjet.cpl>> qu'on avait renommé.
Fabrice Burghgraeve
Bonjour, et merci de ta reponse....
"Didier" a écrit dans le message de news:
"Fabrice Burghgraeve"
wrote in message news:<bn6d1q$v1o$...
> Bonjour. > > Alors la j'en tiens un reproductible. >
(...)
> Sauf que si on ouvre une fois le projet depuis le "disque", puis qu'on > l'ouvre ensuite depuis le repertoire reseau, windev dit qu'il a change
de
> place, et il recompile tout. > Alors qu'il n'a pas change de place. > Donc ca ressemble a un bug... > > Ca a pas l'air dramatique, mais je me demande si la cause de toutes nos > emmerdes du jour > (classes et fenetre qui changent de nom etc) ne viendraient pas de la. >
(...)
Ne t'inquiete pas, ca ne vient pas du changement de répertoire le changement de nom des éléments d'un projet....
meurf faudra chercher ailleurs alors...
Nous on a des projets en réseau partager entre plusieurs dévelopeurs et de temps en temps il nous renome des fenetre ou classe selon son humeur (sans pour autant avoir déplacer le projet). Généralement ce qu'on fait pour revenir à l'origine, on supprime l'élément renommer dans la liste des éléments du projet. On quitte le projet, on renomme le répertoire <<MonProjet.cpl>>, on ouvre le projet, il nous recompile tout puis on réintegre les éléments que nous avions supprimé. Aprés si tout refonctionne correctement on supprime le répertoire <<MonProjet.cpl>> qu'on avait renommé.
Le ".CPL" contient les codes compiles. On peut le virer comme on veut, il le recree... Ca perd juste un peu de temps a l'ouverture. D'ailleurs, quand windev plante a l'ouverture d'un projet, il faut virer le CPL ca peut resoudre le probleme.
sinon, on a fait a peu ce que tu dis (je pense car on a fait pas mal de bidouilles) pour recuperer la merde, et tout est rentre dans l'ordre.
Mais je crois quand meme que le "faux changement de repertoire" est la cause de nos soucis. En effet, en en discutant le lendemain avec mes collegues, il y en a un qui ouvrait systematiquement depuis le disque L, et l'autre systematiquement depuis le repertoire reseau. (qui pointent en fait vers le meme endroit) Quand a moi, ca depend...
En plus des problemes de classes renommees, un de mes collegue avait un message de compilation a la con, disant qu'une procedure n'etait pas dans le projet, alors qu'elle y etait. Il avait beau recompiler, rien a faire. Il a ouvert le projet par le repertoire reseau plutot que par le disque, et l'erreur de compilation a disparu comme par enchantement.
Donc quand meme, dans le doute, on fait maintenant bien attention de toujours ouvrir le projet de la meme maniere, c'est a dire par "voisinnage reseau"
Tu n'as pas une idee de ce qui fait changer les noms des fenetres / classes ? Parce que des bugs windev, on en a vu plein, mais ca il ne nous l'avais jamais fait.(ou alors on s'en souvient plus)
Je ne peux pas croire que ce soit aleatoire. Il y a forcement un protocole de reproduction... D'autant plus que ca ne nous est jamais arrive,mais que en ce moment on est dans une periode particulier pour nous ou on utilise tres intensement windev par rapport a d'habitude, et je trouve que c'est une curieurse coincidence...
Est-ce que tu as deux moyens d'acceder a tes projets ? (est-ce que tu as monte un disque reseau pour metre tes projets ?)
En tout cas, au moins maintenant je sais qu'on est pas les seuls a avoir deja eu ce probleme...
-- Fabrice Burghgraeve Computer & Services suivez ce lien pour me repondre en prive : http://cerbermail.com/?I3GMPRuXDD
Bonjour,
et merci de ta reponse....
"Didier" <dcara@ifrance.com> a écrit dans le message de
news:de181e08.0310240632.7ba139e0@posting.google.com...
wrote in message news:<bn6d1q$v1o$1@news.nordnet.fr>...
> Bonjour.
>
> Alors la j'en tiens un reproductible.
>
(...)
> Sauf que si on ouvre une fois le projet depuis le "disque", puis qu'on
> l'ouvre ensuite depuis le repertoire reseau, windev dit qu'il a change
de
> place, et il recompile tout.
> Alors qu'il n'a pas change de place.
> Donc ca ressemble a un bug...
>
> Ca a pas l'air dramatique, mais je me demande si la cause de toutes nos
> emmerdes du jour
> (classes et fenetre qui changent de nom etc) ne viendraient pas de la.
>
(...)
Ne t'inquiete pas, ca ne vient pas du changement de répertoire le
changement de nom des éléments d'un projet....
meurf faudra chercher ailleurs alors...
Nous on a des projets en réseau partager entre plusieurs dévelopeurs
et de temps en temps il nous renome des fenetre ou classe selon son
humeur (sans pour autant avoir déplacer le projet).
Généralement ce qu'on fait pour revenir à l'origine, on supprime
l'élément renommer dans la liste des éléments du projet. On quitte le
projet, on renomme le répertoire <<MonProjet.cpl>>, on ouvre le
projet, il nous recompile tout puis on réintegre les éléments que nous
avions supprimé.
Aprés si tout refonctionne correctement on supprime le répertoire
<<MonProjet.cpl>> qu'on avait renommé.
Le ".CPL" contient les codes compiles.
On peut le virer comme on veut, il le recree... Ca perd juste un peu de
temps a l'ouverture.
D'ailleurs, quand windev plante a l'ouverture d'un projet, il faut virer le
CPL ca peut resoudre le probleme.
sinon, on a fait a peu ce que tu dis (je pense car on a fait pas mal de
bidouilles) pour recuperer la merde, et tout est rentre dans l'ordre.
Mais je crois quand meme que le "faux changement de repertoire" est la cause
de nos soucis.
En effet, en en discutant le lendemain avec mes collegues, il y en a un qui
ouvrait systematiquement depuis le disque L, et l'autre systematiquement
depuis le repertoire reseau.
(qui pointent en fait vers le meme endroit)
Quand a moi, ca depend...
En plus des problemes de classes renommees, un de mes collegue avait un
message de compilation a la con, disant qu'une procedure n'etait pas dans le
projet, alors qu'elle y etait.
Il avait beau recompiler, rien a faire.
Il a ouvert le projet par le repertoire reseau plutot que par le disque, et
l'erreur de compilation a disparu comme par enchantement.
Donc quand meme, dans le doute, on fait maintenant bien attention de
toujours ouvrir le projet de la meme maniere, c'est a dire par "voisinnage
reseau"
Tu n'as pas une idee de ce qui fait changer les noms des fenetres / classes
?
Parce que des bugs windev, on en a vu plein, mais ca il ne nous l'avais
jamais fait.(ou alors on s'en souvient plus)
Je ne peux pas croire que ce soit aleatoire. Il y a forcement un protocole
de reproduction...
D'autant plus que ca ne nous est jamais arrive,mais que en ce moment on est
dans une periode particulier pour nous ou on utilise tres intensement windev
par rapport a d'habitude,
et je trouve que c'est une curieurse coincidence...
Est-ce que tu as deux moyens d'acceder a tes projets ? (est-ce que tu as
monte un disque reseau pour metre tes projets ?)
En tout cas, au moins maintenant je sais qu'on est pas les seuls a avoir
deja eu ce probleme...
--
Fabrice Burghgraeve
Computer & Services
suivez ce lien pour me repondre en prive :
http://cerbermail.com/?I3GMPRuXDD
> Bonjour. > > Alors la j'en tiens un reproductible. >
(...)
> Sauf que si on ouvre une fois le projet depuis le "disque", puis qu'on > l'ouvre ensuite depuis le repertoire reseau, windev dit qu'il a change
de
> place, et il recompile tout. > Alors qu'il n'a pas change de place. > Donc ca ressemble a un bug... > > Ca a pas l'air dramatique, mais je me demande si la cause de toutes nos > emmerdes du jour > (classes et fenetre qui changent de nom etc) ne viendraient pas de la. >
(...)
Ne t'inquiete pas, ca ne vient pas du changement de répertoire le changement de nom des éléments d'un projet....
meurf faudra chercher ailleurs alors...
Nous on a des projets en réseau partager entre plusieurs dévelopeurs et de temps en temps il nous renome des fenetre ou classe selon son humeur (sans pour autant avoir déplacer le projet). Généralement ce qu'on fait pour revenir à l'origine, on supprime l'élément renommer dans la liste des éléments du projet. On quitte le projet, on renomme le répertoire <<MonProjet.cpl>>, on ouvre le projet, il nous recompile tout puis on réintegre les éléments que nous avions supprimé. Aprés si tout refonctionne correctement on supprime le répertoire <<MonProjet.cpl>> qu'on avait renommé.
Le ".CPL" contient les codes compiles. On peut le virer comme on veut, il le recree... Ca perd juste un peu de temps a l'ouverture. D'ailleurs, quand windev plante a l'ouverture d'un projet, il faut virer le CPL ca peut resoudre le probleme.
sinon, on a fait a peu ce que tu dis (je pense car on a fait pas mal de bidouilles) pour recuperer la merde, et tout est rentre dans l'ordre.
Mais je crois quand meme que le "faux changement de repertoire" est la cause de nos soucis. En effet, en en discutant le lendemain avec mes collegues, il y en a un qui ouvrait systematiquement depuis le disque L, et l'autre systematiquement depuis le repertoire reseau. (qui pointent en fait vers le meme endroit) Quand a moi, ca depend...
En plus des problemes de classes renommees, un de mes collegue avait un message de compilation a la con, disant qu'une procedure n'etait pas dans le projet, alors qu'elle y etait. Il avait beau recompiler, rien a faire. Il a ouvert le projet par le repertoire reseau plutot que par le disque, et l'erreur de compilation a disparu comme par enchantement.
Donc quand meme, dans le doute, on fait maintenant bien attention de toujours ouvrir le projet de la meme maniere, c'est a dire par "voisinnage reseau"
Tu n'as pas une idee de ce qui fait changer les noms des fenetres / classes ? Parce que des bugs windev, on en a vu plein, mais ca il ne nous l'avais jamais fait.(ou alors on s'en souvient plus)
Je ne peux pas croire que ce soit aleatoire. Il y a forcement un protocole de reproduction... D'autant plus que ca ne nous est jamais arrive,mais que en ce moment on est dans une periode particulier pour nous ou on utilise tres intensement windev par rapport a d'habitude, et je trouve que c'est une curieurse coincidence...
Est-ce que tu as deux moyens d'acceder a tes projets ? (est-ce que tu as monte un disque reseau pour metre tes projets ?)
En tout cas, au moins maintenant je sais qu'on est pas les seuls a avoir deja eu ce probleme...
-- Fabrice Burghgraeve Computer & Services suivez ce lien pour me repondre en prive : http://cerbermail.com/?I3GMPRuXDD
