Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Bonjour,
Sur une appli que je ne connais pas, je constate que la construction de l'executable utilise des fichiers pbr d'une part, et ne choisit pas toutes les pbl pour construire les pbd.
Dans les fichiers pbr, il y a le nom de tous les objets (dw, fenetre .... + les noms des bmp)
Y-a-t-il une raison particulière sur l'utilisation des pbr dans ce cas, il me semblait que les pbr devaient utilisés pour donner le chemin des bmp, ico .... et encore si ils ne se trouvent pas dans le répertoire de l'appli ?
Et dans la 2 eme partie de l'appli, si toutes les pbl ne sont pas cochées pour construire les pbd, cela veux donc dire que toutes les pbls ne font pas partie de l'appli ? Mais cela ne semble pas logique.
Quelqu'un a-t-il des explications sur 2 points ?
ici
Hors ligne
wazou1812 a écrit:
Et dans la 2 eme partie de l'appli, si toutes les pbl ne sont pas cochées pour construire les pbd, cela veux donc dire que toutes les pbls ne font pas partie de l'appli ? Mais cela ne semble pas logique.
Je fais cela aussi pour une pbd qui me sert à sauvegarder les dw pour des editions
cette pbd est recréée au lancement de l'appli sur les postes clients et ne doit pas etre sur le serveur
--> pas besoin de la generer
Hors ligne
Pour le deuxième point, lorsqu'une PBL n'est pas cochée, ses objets sont intégrés dans l'EXE (sous certaines conditions voir plus bas) !
La coche sert à déterminer si l'on veut une librairie dynamique ou non.
Et quand c'est non, c'est directement dans l'exe.
Donc l'exe est plus gros et cela peu poser des problèmes de mémoire (espace d'exécution en RAM plus important) ou lors de certains appels dynamiques, dans ce cas souvent les dataobject sont ajoutés dans le PBR pour permettre au compilateur C d'intégrer les dataobject appelés dynamiquement (dw.dataobject="d_toto") des PBL non cochée dans l'exe, car les objets "orphelins" (sans lien : pas d'appel et pas d'héritage) ne seront pas intégrés...
A l'inverse, dans le cas de JCZ c'est très interessant pour ne pas intégrer des objets inutiles...
Hors ligne
Chrnico a écrit:
La coche sert à déterminer si l'on veut une librairie dynamique ou non. ...
Et ça sert à quoi d'avoir des librairie dynamique ?
Ne vaut-il mieux pas tout mettre en pbd ?
Car sinon cela veut dire que à chaque ajout d'une nouvelle dw, il faut la rajouter dans le fichier pbr , c'est un peu lourd en maintenance.
Hors ligne
Attention aussi que dans ce cas ne sont inclus dans l'EXE que les ressources déclarée spécifiquement dans le code
cela veut dire que si tu as une datawindow object "d_exemple_fr" dans une pbl qui ne sera pas compilée en pbd et que la seule utilisation que tu fais de cette dw object se fait par exemple ainsi :
dw_1.dataobject = "d_exemple"
alors la DW ne sera pas incluse dans l'EXE et donc il y aura une erreur lors de la tentative d'utiliser dw_1
par contre si tu as une DW control sur une fenêtre et que tu remplis la propriété "Dataobject" avec d_exemple là la dw object sera incluse dans l'exe.
d'une manière générale j'ai toujours vu des applications avec une exe et toutes les pbl's compilées en pbd, c'est quand même le plus simple et le plus sûr, perso je ne vois pas l'intérêt de faier autrement (je dis pas ça pour critiquer hein, j'ai bien compris que l'appli est comme ça et qu'il faut le gérer, je parle en général)
Hors ligne
Seulement si tu faus dw.dataobejct ="d_toto" et que la PBL n'est pas cochée.
Générer des PBD (PowerBuilder Dynamic Library) évite d'avoir ce genre de problème et un exe trop gros...
Hors ligne
JCZ a écrit:
wazou1812 a écrit:
Et dans la 2 eme partie de l'appli, si toutes les pbl ne sont pas cochées pour construire les pbd, cela veux donc dire que toutes les pbls ne font pas partie de l'appli ? Mais cela ne semble pas logique.
Je fais cela aussi pour une pbd qui me sert à sauvegarder les dw pour des editions
cette pbd est recréée au lancement de l'appli sur les postes clients et ne doit pas etre sur le serveur
--> pas besoin de la generer
pbD ?
parceque j'ai aussi utilisé cette technique mais avec une pbL pour sauvegarder (au moyen de LibraryExport, LibraryImport) les layouts customisés par les users (ex : ordre des colonnes modifié)
Hors ligne
wazou1812 a écrit:
Et ça sert à quoi d'avoir des librairie dynamique ?
Faire une modif et ne regenerer que la pbd modifiée
Hors ligne
rincevent a écrit:
pbD ?
parceque j'ai aussi utilisé cette technique mais avec une pbL pour sauvegarder (au moyen de LibraryExport, LibraryImport) les layouts customisés par les users (ex : ordre des colonnes modifié)
oui oui pbd
Hors ligne
JCZ a écrit:
rincevent a écrit:
pbD ?
parceque j'ai aussi utilisé cette technique mais avec une pbL pour sauvegarder (au moyen de LibraryExport, LibraryImport) les layouts customisés par les users (ex : ordre des colonnes modifié)oui oui pbd
en utilisant aussi LibraryExport ?
peux tu donner un peu plus de détails ? (en MP si nécéssaire pour pas trop dévier du sujet)
Hors ligne
ben ça peut rester dans le sujet, c'est toujours interessant d'apprendre des nouvelles choses ...
Hors ligne
Une PBD, donc une librairie dynamique, est une PBL compilée. Elle est appelée ainsi car elle est chargée en mémoire dynamiquement lors de l'appel de l'un de ses objets (et non au lancement de l'exe). Donc en découpant intelligement sont application, il est possible d'optimiser la gestion mémoire du poste client. Ainsi, une fonctionnalité peu utilisée devrait avoir tout ses objets dans une PBL à part pour ne pas les charger en mémoire inutilement. Une erreur que je constate souvent chez les clients et de ranger les objets par type dans les PBL (PBL des fenêtres, PBL des DW, etc.). Avec une telle organisation tout les objets sont chargés en mémoire quasiment dès le lancement de l'application. Un seul PBR est également préjudiciable. Théoriquement, il faudrait en faire un par PBD pour ne pas mettre toutes les images et objets dynamiques dans l'EXE si le client ne les utilise pas systématiquement (mais là, c'est plus difficile à maintenir et donc souvent le choix de la facilité est fait avec un PBR associé à l'EXE directement).
ATTENTION également à ne pas décocher les PBL du framework même si elle sont déjà présente sur les postes clients. Sinon tous objets ancêtres vont être intégrés dans l'EXE (et les PBD déjà sur le poste client ne seront pas utilisées). Le risque de plantage est de toute façon tellement grand dans ce cas, que vous verez vite votre erreur
Pour répondre à la question, pouquoi faire des PBD et non pas tout dans un EXE, cela vient du mode de fonctionnement des micro-processeurs. Un microprocesseur ne travaille qu'avec des instructions et des données en RAM (il ne sait pas lire directement sur le disque). Lorsque la RAM est saturée, il faut donc que le système libère de la place pour continuer à travailler. Il le fait en déchargeant sur disque des parties de la RAM affectées aux process en cours d'exécution mais non actifs (voir sur google horloge système, mémoire virtuelle, fichier d'échange, etc...). Lorsque le process redevient actif, le système fait l'opération inverse. C'est ce qu'on appelle l'opération de SWAP. Votre EXE en cours d'éxécution s'il est actif ne pourra donc pas être swappé, par contre les PBD non utilisée au moment où le système manque de mémoire pourront l'être. Si tous les développeurs ne faisaient que des EXE sans PBD (ou DLL pour bon nombre d'autres langages) alors votre système afficherait rapidement "mémoire insuffisante" sans pouvoir faire quoi que ce soit pour en libérer, au risque de planter (écran bleu sous 95) ou de ne plus pouvoir lancer de nouveau programme.
L'existance de PBD est donc justifiée, leur taille pas trop grosse aussi. Pour éviter de devoir swapper de gros morceaux d'application inutilement (opération couteuse en terme de performance et nécessitant un fichier d'échange plus important que réellement nécessaire => voir dans google : sectorisation d'un disque, facteur de blocage, etc.)
Voilà, les puristes des systèmes réagiront car j'ai volontairement simplifié certaines explications
Hors ligne
Pour répondre à la question pourquoi PB ne fait pas de PBD directement depuis chaque PBL sans laisser le choix au développeur. Simplement parce que dans certains cas, il est nécessaire de n'avoir qu'un seul fichier EXE...
Hors ligne
et
à chrnico pour ces explications aussi limpides qu'utiles
UP: + 50 pépites pour chrnico
Hors ligne
Tout à fait d'accord avec Foon :
Hors ligne
Félicitation à tous.
Et normalement, l'utilisation des fichiers pbr, est plutot faite pour spécifier le chemin de .bmp (ou .ico ....) ou y-a-t-il une autre utilisation courante ?
Hors ligne
wazou1812 a écrit:
Félicitation à tous.
Et normalement, l'utilisation des fichiers pbr, est plutot faite pour spécifier le chemin de .bmp (ou .ico ....) ou y-a-t-il une autre utilisation courante ?
en effet comme ça a été dit : pour des objets dynamiques
j'ai aussi connu des développeurs qui créaient une feuille w_ressource où ils mettaient un dwcontrol pour chaque DWO et un picturecontrol pour chaque image appelées dynamiquement pour qu'elles soient prises en compte à la compil...
les PBR sont utiles pour "embarquer" des objets dans l'appli
ex: si tu as sur le poste de dev un fichier c:\blabla\image.bmp utilisé dynamiquement non déclaré dans un PBR il ne sera visible sur le poste client uniquement si celui-ci a également le fichier c:\blabla\image.bmp (ou image.bmp dans le repertoire de l'exe, il me semble)
Hors ligne
les PBR sont utiles pour "embarquer" des objets dans l'appli
ex: si tu as sur le poste de dev un fichier c:\blabla\image.bmp utilisé dynamiquement non déclaré dans un PBR il ne sera visible sur le poste client uniquement si celui-ci a également le fichier c:\blabla\image.bmp (ou image.bmp dans le repertoire de l'exe, il me semble)
Sauf si le chemin des objets n'est pas spécifié, si le fichier image.bmp se trouve dans le même répertoire que les pbd et l'exe, dans se cas PB se débrouille tout seul, et donc pas besoin de fichier pbr. Enfin chez nous, sur une grosse appli, ça fonctionne comme ça depuis longtemps et sans problème.
Merci à tous pour toutes ces précisions et je mets le sujet en résolu.
Hors ligne
wazou1812 a écrit:
Sauf si le chemin des objets n'est pas spécifié, si le fichier image.bmp se trouve dans le même répertoire que les pbd et l'exe, dans se cas PB se débrouille tout seul, et donc pas besoin de fichier pbr. Enfin chez nous, sur une grosse appli, ça fonctionne comme ça depuis longtemps et sans problème.
effectivement, mais cela t'obliges à déployer toutes les images, même minimes
Hors ligne
eRaSorZ a écrit:
...j'ai aussi connu des développeurs qui créaient une feuille w_ressource où ils mettaient un dwcontrol pour chaque DWO et un picturecontrol pour chaque image appelées dynamiquement pour qu'elles soient prises en compte à la compil...
Il y a des générateurs de pbr sur internet.
Il en reste peut-être encore un gratuit.
Quand j'étais jeune j'en avais écrit un, mais ait perdu les sources
Hors ligne
Petite précision concernant les images et icônes du PBR : elles sont directement intégrées dans l'exe (ou la PBD auquelle on associe le PBR) et n'ont plus besoin d'être copier sur le poste du client.
Pour cela il faut respecter les règles suivantes :
- ne pas mettre le chemin dans le PBR mais simplement le nom de fichier
- ne pas mettre le chemin dans les controles PB (image, picturebutton, etc.) mais simplement le nom du fichier
- s'assurer qu'au moment de la génération de l'exe les images soient dans le path de la machine qui génère l'exe
Hors ligne