[WD7.5] Problème de migration...

"JPN" <jpn@abtel.fr.nospam> a écrit:

Bonjour à tous,

Je débute la migration d'un projet de WD55 vers WD75.

Aïe aïe aïe...:-)

J'ai du mal à comprendre la raison pour laquelle pcsoft a changé la portée
des variables globales (ou alors je n'ai pas tout compris...).

Il y a des petites différences (notion de collections) mais la portée
des globales du projet reste la même...globale au projet.

Apparemment, il faut reprendre toutes les déclarations de variables globales
du projet pour les remonter dans le code d'initialisation du projet ou de la
fenêtre (mais dans ce dernier cas, ces variable ne seront pas accessibles
des autres fenêtres).
Le travail est énorme et va tripler le temps nécessaire à la migration,
dommage, et pour quelle raison, si qq sait, ca m'interesse.

Bizarre, je viens de faire le test (WD7.5 205s), les globales du projet
en WD55 sont automatiquement transférées en globales du projet WD75
migré. Fausse manip de ta part ?

Pour le moment, j'aimerai savoir s'il existe un moyen de transférer
automatiquement toutes les procédures locales d'une fenêtre dans une
collection (les variables globales déclarées dans le code d'initialisation
d'une collection semblent accessible par tout le projet).

Pourquoi veux-tu transférer les procédures locales ?
(pour cela, j'ai bien peur qu'il faille les copier-coller une par
une...)
Pour ce qui est des globales déclarées dans le code d'initialisation
d'une collection, elles ne sont pas accessibles dans tout le projet
_directement_ (sauf dans les procédures de la collection elle-même) :
comme pour tout "objet" WD7.5 (fenetre, classe, collection, etat...) il
faut les manipuler en précisant le nom de l'objet parent (exemple :
MaCollection.MaGlobale).


A+

--
Romain Petit

Merci de tes réponses...

Quelques précisions :

Le gros changement (apparemment) est qu'en WD55, tu pouvais déclarer une
variable globale à n'importe quel moment et que celle-ci avait alors une
portée globale pour tout le code appelé en aval de la déclaration...
Maintenant ce n'est plus possible. J'utilise une fenêtre qui contient toutes
les procédures de l'appli et je fais un chargeprocedurede la fenetre en
début de projet. Tu imagines... Toutes les déclaration globales des
procédures contenues dans la fenetre se retrouvent maintenant dans le code
d'initialisation de la fenêtre qui en plus n'est jamais executée en
elle-même... C'est pour cette raison que je veux transférer ces procédures
(locales pour la fenetre) dans une collection, solution plus 'propre en
WD7).

JeanPhi

"Romain Petit" <rompetit@invalidifrance.com> a écrit dans le message de
news: dehslvcekltj9vivm0qpi3usv2vr0tsu4d@4ax.com...

"JPN" <jpn@abtel.fr.nospam> a écrit:

> Bonjour à tous,
>
> Je débute la migration d'un projet de WD55 vers WD75.

Aïe aïe aïe...:-)

> J'ai du mal à comprendre la raison pour laquelle pcsoft a changé la

portée

> des variables globales (ou alors je n'ai pas tout compris...).

Il y a des petites différences (notion de collections) mais la portée
des globales du projet reste la même...globale au projet.

> Apparemment, il faut reprendre toutes les déclarations de variables

globales

> du projet pour les remonter dans le code d'initialisation du projet ou

de la

> fenêtre (mais dans ce dernier cas, ces variable ne seront pas

accessibles

> des autres fenêtres).
> Le travail est énorme et va tripler le temps nécessaire à la migration,
> dommage, et pour quelle raison, si qq sait, ca m'interesse.

Bizarre, je viens de faire le test (WD7.5 205s), les globales du projet
en WD55 sont automatiquement transférées en globales du projet WD75
migré. Fausse manip de ta part ?

> Pour le moment, j'aimerai savoir s'il existe un moyen de transférer
> automatiquement toutes les procédures locales d'une fenêtre dans une
> collection (les variables globales déclarées dans le code

d'initialisation

> d'une collection semblent accessible par tout le projet).

Pourquoi veux-tu transférer les procédures locales ?
(pour cela, j'ai bien peur qu'il faille les copier-coller une par
une...)
Pour ce qui est des globales déclarées dans le code d'initialisation
d'une collection, elles ne sont pas accessibles dans tout le projet
_directement_ (sauf dans les procédures de la collection elle-même) :
comme pour tout "objet" WD7.5 (fenetre, classe, collection, etat...) il
faut les manipuler en précisant le nom de l'objet parent (exemple :
MaCollection.MaGlobale).


A+

--
Romain Petit

JPN a écrit :

Quelques précisions :

Le gros changement (apparemment) est qu'en WD55, tu pouvais déclarer
une variable globale à n'importe quel moment et que celle-ci avait
alors une portée globale pour tout le code appelé en aval de la
déclaration...

Comment fais-tu cela ??

Extrait de l'aide WD55 :

"Variable globale
Les variables globales déclarées dans le traitement d'initialisation d'un
projet peuvent être utilisées dans tous les traitements du projet.
Les variables globales déclarées dans le traitement d'ouverture d'une
fenêtre peuvent être utilisées dans tous les traitements de la fenêtre (et
des champs de la fenêtre).
Les variables globales déclarées dans un traitement peuvent être utilisées
dans tous les traitements appelés après le traitement dans lesquelles elles
ont été déclarées.
Les variables globales d'une fenêtre ne peuvent pas être utilisées par ses
fenêtres soeurs.
Les variables globales déclarées dans une fenêtre fille ne peuvent pas être
utilisées dans sa fenêtre mère.
Lorsque la fenêtre dans laquelle la variable a été déclarée est fermée, les
variables ne peuvent plus être utilisées.
Une variable est globale, si elle est précédée du mot clé Global (ou
Public).
Attention : Pour qu'une variable soit reconnue dans tous les traitements de
toutes les fenêtres et de tous les champs, la variable doit être déclarée
dans le traitement d'initialisation du projet. Pour qu'une variable soit
reconnue dans tous les traitements de la fenêtre et de tous les champs de la
fenêtre, la variable doit être déclarée dans le traitement d'ouverture de la
fenêtre.
Important : il ne faut pas déclarer deux variables avec le même nom
(notamment une déclarée globale et une autre déclarée locale)."

Maintenant ce n'est plus possible. J'utilise une
fenêtre qui contient toutes les procédures de l'appli et je fais un
chargeprocedurede la fenetre en début de projet.

J'ai du mal à comprendre pourquoi ce type de codage a été choisi...

Tu imagines...
Toutes les déclaration globales des procédures contenues dans la
fenetre se retrouvent maintenant dans le code d'initialisation de la
fenêtre qui en plus n'est jamais executée en elle-même... C'est pour
cette raison que je veux transférer ces procédures (locales pour la
fenetre) dans une collection, solution plus 'propre en WD7).

Tu aurais dû utiliser des classes en WD55...
Bon courage pour les CTRL+C et les CTRL+V.

--
Romain PETIT
(mailto:rompetit_chez_ifrance.com)

> Comment fais-tu cela ??

j'utilise :

Les variables globales déclarées dans un traitement peuvent être utilisées
dans tous les traitements appelés après le traitement dans lesquelles elles
ont été déclarées.

et çà c'est plus possible en WD7 (je trouve même que c'est une grosse
regression)...

J'ai du mal à comprendre pourquoi ce type de codage a été choisi...

je ne sais pas non plus, mais imposé par la société pour laquelle je
travaille...
je pense qu'au début du développement celà etait plus simple que de creer
des classes (le projet est en fait divisé en plusieurs petits projets qui
ont chacun leur fenetre de procédures spécifique)

merci en tous cas de tes conseils

JeanPhi

(mailto:rompetit_chez_ifrance.com)

"JPN" <jpn@abtel.fr.nospam> a écrit:

j'utilise :
Les variables globales déclarées dans un traitement peuvent être utilisées
dans tous les traitements appelés après le traitement dans lesquelles elles
ont été déclarées.

Oui, mais concretement ?
Tu charges une fenetre invisible contenant ces variables et elles sont
directement accessibles ensuite dans tout le projet ?

et çà c'est plus possible en WD7 (je trouve même que c'est une grosse
regression)...

Pas moi.
L'optique plus "objet" de WD7 est d'une bien meilleure approche que les
bricolages de WD55, surtout pour la réutilisation d'un code existant.
Par contre tu peux toujours accéder aux variables de ta fenetre (chargée
au démarrage du projet, ou même il me semble que ce n'est pas
obligatoire de la charger explicitement) en utilisant à n'importe quel
endroit du projet:

SI MaFenetre.MaVariableBooléenne = vrai ALORS
MaFenetre.MavariableChaine = "toto"
FIN

> J'ai du mal à comprendre pourquoi ce type de codage a été choisi...

je ne sais pas non plus, mais imposé par la société pour laquelle je
travaille...
je pense qu'au début du développement celà etait plus simple que de creer
des classes (le projet est en fait divisé en plusieurs petits projets qui
ont chacun leur fenetre de procédures spécifique)

Oui, je vois :-)

Pour ton problème, une suggestion (attention, sauvegarde tes projets
avant de tenter ce qui suit, je ne sais pas si les dicos en WD7.5 sont
complêtement opérationnels même avec la 205s), as-tu essayé à partir du
projet WD55 de créer des dictionnaires puis de les migrer en WD75 ?

A+

--
Romain Petit

> Oui, mais concretement ?

Tu charges une fenetre invisible contenant ces variables et elles sont

directement accessibles ensuite dans tout le projet ?

J'utilise en effet une fenetre qui ne sert qu'a stocker des procedures en
rapport avec une partie du projet. Quant une fenetre a besoin d'utiliser ces
procedures, je fais un ChargeProcedure de la fenetre en question. Dans
certaines de ces procedures, j'utilise (enfin j'utilisais) des variables
globales, accessible uniquement dans cette procedure et les sous-procedure
qui lui sont liées).

> et çà c'est plus possible en WD7 (je trouve même que c'est une

> grosse regression)...

Pas moi.

L'optique plus "objet" de WD7 est d'une bien meilleure approche que

les bricolages de WD55, surtout pour la réutilisation d'un code

existant. Par contre tu peux toujours accéder aux variables de ta

fenetre (chargée au démarrage du projet, ou même il me semble que ce

n'est pas obligatoire de la charger explicitement) en utilisant à

n'importe quel endroit du projet:

SI MaFenetre.MaVariableBooléenne = vrai ALORS

MaFenetre.MavariableChaine = "toto"

FIN

Oui d'accord avec toi mais pourquoi ne pas laissé le choix au developpeur ?
Je ne connais pas beaucoup d'autres langages mais il me semble qu'on peut
pratiquement dans tous, a tout moment declarer une variable globale et pas
uniquement dans le code d'initialisation d'un projet ou d'une fenetre.

> > J'ai du mal à comprendre pourquoi ce type de codage a été

> > choisi...

> je ne sais pas non plus, mais imposé par la société pour laquelle je

> travaille... je pense qu'au début du développement celà etait plus

> simple que de creer des classes (le projet est en fait divisé en

> plusieurs petits projets qui ont chacun leur fenetre de procédures

> spécifique)

Oui, je vois :-)

Pour ton problème, une suggestion (attention, sauvegarde tes projets

avant de tenter ce qui suit, je ne sais pas si les dicos en WD7.5 sont

complêtement opérationnels même avec la 205s), as-tu essayé à partir

du projet WD55 de créer des dictionnaires puis de les migrer en WD75 ?

Je vais regarder çà

Merci

JeanPhi

--

Romain Petit

"