Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Petite question !
En Powerbuilder lorsque l’on clique sur l’objet application on peut avoir accès ( et modifier l’organisation des libraires)
Par exemple :
C:\Documents and Settings\Bureau\convert\convert.pbl;
C:\Documents and Settings\Bureau\convert\pfcapsrv.pbl;
C:\Documents and Settings\Bureau\convert\pfcdwsrv.pbl;
C:\Documents and Settings\Bureau\convert\pfcmain.pbl;
C:\Documents and Settings\Bureau\convert\pfcutil.pbl;
C:\Documents and Settings\Bureau\convert\pfcwnsrv.pbl;
C:\Documents and Settings\Bureau\convert\pfeapsrv.pbl;
C:\Documents and Settings\Bureau\convert\pfedwsrv.pbl;
C:\Documents and Settings\Bureau\convert\pfemain.pbl;
C:\Documents and Settings\Bureau\convert\pfeutil.pbl;
C:\Documents and Settings\Bureau\convert\pfewnsrv.pbl;
J’aimeras savoir si cette organisation est importante ; j’entend par la est-ce que c’est important qu’une libraire soit placé avant une autre ou pas ???
merci
Hors ligne
Hello,
moi, par défaut, j'ai tendance à mettre les pfc/framework au début de la liblist.
par contre là où j'bosse en ce moment, c'est la première fois que je vois l'inverse
petit thread à lire : http://groups.google.fr/group/powersoft … ba18fe504d
Hors ligne
jdobosz a écrit:
petit thread à lire : http://groups.google.fr/group/powersoft … ba18fe504d
Bonjour,
Il semble donc d'après cette discussion que l'ordre des PBL n'ai un impact que pour les versions <= à Pb 5 ... ?
Merci de confirmer
Dernière modification par Jmix90 (05-09-2006 15:28:56)
Hors ligne
c'est ce que j'ai cru comprendre sur le newsgroup
Hors ligne
mais autant garder les bonnes habitudes et respecter cet ordre...quelque soit la version.
Hors ligne
Apparemment,
il faut mettre les PBL des objets génériques à la fin de la liste des librairies.
En effet, lorsque powerbuilder effectue sa compilation lors de la création de l'executable, la liste commencerait à partir de la fin.....
A VERIFIER
Hors ligne
Bon, effectivement, depuis quelques version de PowerBuilder, l'ordre des pbl/pbd dans la librarylist n'intervient plus significativement dans les performances du programme compilé...
Mais cet ordre a un aventage bcp plus important, dont je ne vois personne parler ici : le principe de la priorité par préséance!
Imaginons 2 objets de même nom, mais ayant des fonctionnalités légèrement différentes, et placés dans 2 pbl différentes. Lors de l'instanciation de cet objet, PB ira chercher le 1er des 2 qu'il va trouver EN SUIVANT L'ORDRE du librarylist...
L'intérêt? Il y en a plein!!!
Développement sûr en équipe, conception de plug-in, "patch de crise" sans recompilation,... et j'en passe!
Si ca intéresse quelqu'un, je peux développer mon propos, mais c'est un peu complexe...
Hors ligne
je veux bien que tu developpes tes propos !
ca m'interesse moi !!!!!
comme on dit, prems !!!!!!!
Hors ligne
Plexiglas a écrit:
L'intérêt? Il y en a plein!!!
Développement sûr en équipe, conception de plug-in, "patch de crise" sans recompilation,... et j'en passe!
Si ca intéresse quelqu'un, je peux développer mon propos, mais c'est un peu complexe...
Je vois tout à fait ce que tu veux dire.
Exemple :
les librairies de notre application sont :
lib1.pbl;
lib2.pbl;
lib3.pbl;
Comme lib-liste, moi j'utilise
0_travail_steve.pbl;
lib1.pbl;
lib2.pbl;
lib3.pbl;
Et dans 0_travail_steve.pbl se trouvent tous les objets sur lesquels je fais des modifs. Du coup, les modifs n'impactent pas l'exécution par les autres développeurs qui ont la lib-liste d'origine ou également une lib-liste avec leur propre librairie de travail.
Les objets modifiés sont réintégrés à leur place seulement quand la modif est validée définitivement.
Dernière modification par Steve (29-09-2006 15:30:25)
Hors ligne
Chouette, un publique!
Bon ben 1er cas, simple :
Disons que tu as une application qui se veut générique (ben tiens, quelle nouveauté!) mais que soudainement, tu n'as pas d'autres choix que de faire des routine ou plus fréquemment des rapports spécifiques pour l'un ou l'autre client. Evidemment, ce n'est pas toi qui a développé le monstre, et ton boss ne te permettra pas de tout retourner pour développer de jolis systèmes de switch en fonction du client. Tu sens le syndrome du "choose case" te gagner...
Que faire?
1/ demander à la facturation d'envoyer un devis bien copieux au client
2/ rajouter une pbl ("specifique.pbl" p.ex.) en tête du librarylist. Elle est vide.
3/ tu compile
4/ pour ton client, tu te crée une petite pbl (genre "boucherie_sanzot.pbl") dans laquelle du copie les rapports à spécificationner (je sais, ca se dit pas)
5/ tu lui modifie ca comme il le veux, avec sa police fétiche et la photo de son chien en arrière plan
6/ tu compile uniquement cette pbl (click droit -> "build runtime library")
7/ tu la renomme en "specifique.pbl", et tu l'enverra au client d'ici qques jours, histoire qu'il comprenne qu'il ne doit pas abuser... Elle devra remplacer l'ancienne, qui etait vide
8/ tu vas te fumer une cloppe, parce que maintenant tu as du temps
Et quand le joli client va lancer ton soft, et qu'il voudra afficher son rapport "d_exoneration_fiscale_avec_indice_de_retenue_majore", il n'aura pas droit au rapport générique, mais bien à son homonyme, que PB va trouver dans la première pbl de la liste.
C'est un peu pourri, mais ca sauve des vies!
J'appelle ca le "palliatif aux analystes foireux"...
Et comme ce forum est bien sympatoche, je posterai apres le week end un petit exemple d'applic PB supportant des plug-in...
Hors ligne
COOLLLLLLLLLLLLLLL !
j'attends vivement de voir ca !
Hors ligne