Problème avec les variables et les unités
Résolu
christoufe
Messages postés
3
Date d'inscription
mercredi 21 décembre 2005
Statut
Membre
Dernière intervention
21 janvier 2006
-
21 janv. 2006 à 21:38
f0xi Messages postés 4205 Date d'inscription samedi 16 octobre 2004 Statut Modérateur Dernière intervention 12 mars 2022 - 22 janv. 2006 à 06:23
f0xi Messages postés 4205 Date d'inscription samedi 16 octobre 2004 Statut Modérateur Dernière intervention 12 mars 2022 - 22 janv. 2006 à 06:23
A voir également:
- "Php version 4.4.3" "build date" "server api" "php variables"
- "Php variables" "php version 4.4.3" "build date" "server api" - Meilleures réponses
- "Php variables" "server api" "php version 4.4.3" "build date" - Meilleures réponses
- API php pour Astérisk - Forum PHP
- "Php version 4.4.4" "build date" "server api" "php variables" - Forum PHP
- "Php version 4.4.5" "build date" "server api" "php variables" - Forum PHP
- Php version 4.4.6 build date server api php variables ✓ - Forum C# / .NET
- Api SetBitmapDimensionEx - Forum Visual Basic
6 réponses
jlen100
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
13
21 janv. 2006 à 22:01
21 janv. 2006 à 22:01
salut crée une unitté à part qui contiendra toutes tes variables que tu
déclareras dans la partie interface elles seront ainsi vues par toutes
les autres unités
@+
jlen
déclareras dans la partie interface elles seront ainsi vues par toutes
les autres unités
@+
jlen
cs_ManChesTer
Messages postés
374
Date d'inscription
vendredi 20 octobre 2000
Statut
Modérateur
Dernière intervention
15 janvier 2021
21 janv. 2006 à 21:50
21 janv. 2006 à 21:50
unit Unit1
....
var mavarglobale : integer;
implementation
....
end.
unit Unit2;
...
Implementation
Uses Unit1; <== permet d'utiliser le contenu de unit1 dans le code de unit2
....
end;
ou
unit Unit2;
...
Uses Unit1; <== permet d'utiliser le contenu de unit1 dans le code et les déclaration de unit2
....
Implementation
....
end;
Bon Coding ....
ManChesTer.
....
var mavarglobale : integer;
implementation
....
end.
unit Unit2;
...
Implementation
Uses Unit1; <== permet d'utiliser le contenu de unit1 dans le code de unit2
....
end;
ou
unit Unit2;
...
Uses Unit1; <== permet d'utiliser le contenu de unit1 dans le code et les déclaration de unit2
....
Implementation
....
end;
Bon Coding ....
ManChesTer.
christoufe
Messages postés
3
Date d'inscription
mercredi 21 décembre 2005
Statut
Membre
Dernière intervention
21 janvier 2006
21 janv. 2006 à 21:55
21 janv. 2006 à 21:55
En fait, ca répond pas complèment à ma question, car le corps du programme c'est pas une unit.
Je peux pas utiliser les variables du programmes dans mes units?
Je peux pas utiliser les variables du programmes dans mes units?
christoufe
Messages postés
3
Date d'inscription
mercredi 21 décembre 2005
Statut
Membre
Dernière intervention
21 janvier 2006
21 janv. 2006 à 22:03
21 janv. 2006 à 22:03
Merci, je pense que c'est une bonne idée ca :p
Merci beaucoup à vous
Merci beaucoup à vous
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
jlen100
Messages postés
1606
Date d'inscription
samedi 10 juillet 2004
Statut
Membre
Dernière intervention
25 juillet 2014
13
21 janv. 2006 à 22:09
21 janv. 2006 à 22:09
pas de quoi
bonne prog
@+
jlen
bonne prog
@+
jlen
f0xi
Messages postés
4205
Date d'inscription
samedi 16 octobre 2004
Statut
Modérateur
Dernière intervention
12 mars 2022
35
22 janv. 2006 à 06:23
22 janv. 2006 à 06:23
petite explication :
dans une unité, il figure deux partie Distincte : Interface et Implementation.
ces deux partie fonctionne un peu comme les zones Protected (ou private) et Published (ou public) d'une classe.
en gros :
tout les elements presents dans la zone Interface seront accessible aux autres unités. (publique)
tout les elements presents dans la zone Implementation ne seront accessible que dans cette zone uniquement. (privée)
parfois, certaines unités dispose d'un nom de variable faisant reference a une autre variable ou fonction ou autres dans une autre unité ... on appel cela "cacher" le nom, car selon la prioritée de selection l'elements serat sois la variable sois la fonction du meme nom ou autre element, ce qui ferat une belle erreur de compilation ou d'execution.
Donc on peu bien sur faire cela, mais il faudrat appeler l'identifiant completement avec le nom d'unitée :
Uses SysUtils, MonUnite;
...
MonUnite.Format (variable type string)
SysUtils.Format (fonction format de l'unité SysUtils)
il est d'ailleur preferable de toujours appeler les methodes ou variables externes a l'unité en cours comme cela, cela augmente la lisibilitée mais aussi le code malheureusement (mais evite des desagrement certains).
Il faut egalement penser a hierarchiser ses unités et programme et donner des nom probants aux unités puis donner une certaine discipline a ces dernieres.
exemple :
Main.pas (unité principale du programme)
Help.pas (unité qui regroupe l'aide du programme)
About.pas (unité qui permet de gerer la fenetre "a propos")
Shared.pas (unité qui regroupe tout les elements non-standard et partageable du programme (methodes, variables)
On peu egalement declarer le nom du programme (en raccourcis) devant le nom des unités :
MediaPlay.dpr (programme)
MPMain.pas
MPHelp.pas
MPAbout.pas
MPEngine.pas
MPShared.pas
DSShared.pas (unité partagée qui proviens d'un autre programme)
OGLEngine.pas (unité qui proviens d'un autre programme)
Voila, a partir de la, on peu jongler comme il faut d'une unité a l'autre car tout est bien decoupé.
Si on applique le meme principe a l'ecriture du code, on obtiendras trés vite des unités parfaitement compatible entre elles, facilement associable et surtout augmenteras le deployement des programmes.
<hr size="2" width="100%">La theorie c'est quand on sait tout, mais que rien ne fonctionne.
La pratique c'est quand tout fonctionne, mais que personne ne sait pourquoi.
<hr>
dans une unité, il figure deux partie Distincte : Interface et Implementation.
ces deux partie fonctionne un peu comme les zones Protected (ou private) et Published (ou public) d'une classe.
en gros :
tout les elements presents dans la zone Interface seront accessible aux autres unités. (publique)
tout les elements presents dans la zone Implementation ne seront accessible que dans cette zone uniquement. (privée)
parfois, certaines unités dispose d'un nom de variable faisant reference a une autre variable ou fonction ou autres dans une autre unité ... on appel cela "cacher" le nom, car selon la prioritée de selection l'elements serat sois la variable sois la fonction du meme nom ou autre element, ce qui ferat une belle erreur de compilation ou d'execution.
Donc on peu bien sur faire cela, mais il faudrat appeler l'identifiant completement avec le nom d'unitée :
Uses SysUtils, MonUnite;
...
MonUnite.Format (variable type string)
SysUtils.Format (fonction format de l'unité SysUtils)
il est d'ailleur preferable de toujours appeler les methodes ou variables externes a l'unité en cours comme cela, cela augmente la lisibilitée mais aussi le code malheureusement (mais evite des desagrement certains).
Il faut egalement penser a hierarchiser ses unités et programme et donner des nom probants aux unités puis donner une certaine discipline a ces dernieres.
exemple :
Main.pas (unité principale du programme)
Help.pas (unité qui regroupe l'aide du programme)
About.pas (unité qui permet de gerer la fenetre "a propos")
Shared.pas (unité qui regroupe tout les elements non-standard et partageable du programme (methodes, variables)
On peu egalement declarer le nom du programme (en raccourcis) devant le nom des unités :
MediaPlay.dpr (programme)
MPMain.pas
MPHelp.pas
MPAbout.pas
MPEngine.pas
MPShared.pas
DSShared.pas (unité partagée qui proviens d'un autre programme)
OGLEngine.pas (unité qui proviens d'un autre programme)
Voila, a partir de la, on peu jongler comme il faut d'une unité a l'autre car tout est bien decoupé.
Si on applique le meme principe a l'ecriture du code, on obtiendras trés vite des unités parfaitement compatible entre elles, facilement associable et surtout augmenteras le deployement des programmes.
<hr size="2" width="100%">La theorie c'est quand on sait tout, mais que rien ne fonctionne.
La pratique c'est quand tout fonctionne, mais que personne ne sait pourquoi.
<hr>
