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

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.

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...

wazou1812 a écrit:

Et ça sert à quoi d'avoir des librairie dynamique ?

Faire une modif et ne regenerer que la pbd modifiée

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)

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

et à chrnico pour ces explications aussi limpides qu'utiles

UP: + 50 pépites pour chrnico

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 ?

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.

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