Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Pages: 1 2
Salut Seki, comme je le pensais ça n'avait rien à voir avec les .pbd mais avec le répertoire courant au niveau de windows (voir mon edit dans mon précédent message)
Hors ligne
OK. Je n'avais pas vue la partie "edit", sans doute ajoutée après que la page ait été affichée dans mon navigateur.
Effectivement le fonctionnement de PB fait changer de répertoire de travail dès qu'on navigue pour chercher un fichier et qui fait planter l'appli ensuite si on utilise des extensions (ou qui fait perdre les ressources graphiques) et qu'on ne pense pas à repositionner le répertoire de travail est un vrai boulet
Hors ligne
seki a écrit:
OK. Je n'avais pas vue la partie "edit", sans doute ajoutée après que la page ait été affichée dans mon navigateur.
vi
seki a écrit:
Effectivement le fonctionnement de PB fait changer de répertoire de travail dès qu'on navigue pour chercher un fichier et qui fait planter l'appli ensuite si on utilise des extensions (ou qui fait perdre les ressources graphiques) et qu'on ne pense pas à repositionner le répertoire de travail est un vrai boulet
D'ailleurs à ce propos pour creuser un peu plus (mon occupation principale ces temps ci, je creuse.... pendant que ceux qui ont les pistolets chargés font les guignols....)
Il n'est pas possible d'overrloader ces fonctions d'objets d'une manière globale et sûre comme on peut le faire pour une fonction pb si ?
par ex. on peut overloader la fonction messagebox() de pb en créant une fonction globale du même nom qui sera appellée toujours en priorité par PB
mais pour overloader la fonction DirList d'une listbox je devrais d'abord hériter de la classe listbox et là je pourrai redéfinir ma fonction mais le problème c'est qe rien n'empêche un autre dév d'utiliser une listbox standard de pb au lieu de la listbox héritée avec DirList overloadé.
c'est juste ?
Hors ligne
rincevent a écrit:
mais pour overloader la fonction DirList d'une listbox je devrais d'abord hériter de la classe listbox et là je pourrai redéfinir ma fonction mais le problème c'est qe rien n'empêche un autre dév d'utiliser une listbox standard de pb au lieu de la listbox héritée avec DirList overloadé.
c'est juste ?
farpaitement.
ca fonctionne bien mais il faut que les gens pensent à utiliser tes objets au lieu de ceux de base de PB.
pour le fun je viens d'essayer de sauvegarder mon u_checkbox en checkbox mais j'ai un invalid name c'est bien dommage :'(
Hors ligne
seki a écrit:
Les extensions pbni se composent d'une dll (avec l'extension .pbx) et d'un .pbd qui ne contient que les références vers les fonctions de la dll.
Le pbd est obtenu après compilation de la dll avec un outil sybase qui s'appelle pbx2pbd.
Par contre j'ai remarqué que tu peux ajouter au projet directement les pbx et l'ide se débrouille avec.
J'ai essayé d'importer les pbx pour m'affranchir des pbd.
Ca fonctionne bien sauf pour PbniList.pbx qui me retourne :
---------- Import PB Extension: (09:45:09)
Importing D:\dev\_dev_dwbm\PbniList.pbx - Error: Cannot create an entry in pbl for this extension.
---------- Finished (09:45:09)
Par ailleurs, faudra-t-il déployer les pbx avec l'appli, ou alors elle seront automatiquement embarquées dans la pbd issue de la pbl où on importe les extensions ?
Hors ligne
erasorz a écrit:
J'ai essayé d'importer les pbx pour m'affranchir des pbd.
Ca fonctionne bien sauf pour PbniList.pbx qui me retourne :---------- Import PB Extension: (09:45:09)
Importing D:\dev\_dev_dwbm\PbniList.pbx - Error: Cannot create an entry in pbl for this extension.
---------- Finished (09:45:09)
Tiens ? Il faudra que je fasse le test... Mais pour l’instant, je suis en train de jouer avec du java sur une machine décorée d’une pomme après un poste de secours pour un roller-derby .
erasorz a écrit:
Par ailleurs, faudra-t-il déployer les pbx avec l'appli, ou alors elle seront automatiquement embarquées dans la pbd issue de la pbl où on importe les extensions ?
Un fichier pbx, c’est une dll. Il faut déployer le pbx avec l’appli comme lorsque tu appelles une dll externe, si ce n’est pas une dll système
Hors ligne
erasorz a écrit:
---------- Import PB Extension: (09:45:09)
Importing D:\dev\_dev_dwbm\PbniList.pbx - Error: Cannot create an entry in pbl for this extension.
---------- Finished (09:45:09)
xlat a fait quelques tests et il semble que ça provienne d'une méthode de uo_list qui s'appelle 'insert'
Je pense refaire une version en renommant 'insert' -> 'insert_at' par exemple. ça évitera les ambiguïtés de parsing
Hors ligne
À la demande générale d'Erasorz (et aussi grâce à son lobbying !), une mise à jour de pbnilist est dispo en ligne sur mon dépôt github
Pour que l'import du pbx fonctionne en direct, j'ai renommé les 2 méthodes insert() de uo_list et uo_vector en inserthere().
La différence à l'utilisation, c'est qu'au lieu de définir pbnilist.pbd dans les propriétés de la target, on fait un "import PB extension" sur une pbl existante et pb va ajouter les fonctions globales et objets fournis dans l'extension directement dans la pbl, un peu comme des externals en utilisant une syntaxe avec le mot-clé "native"
global type uo_list from nonvisualobject native "PbniList.pbx"
Enjoy!
Hors ligne
Hors ligne
erasorz a écrit:
De rien (pour une fois que j'ai un client...)
Hors ligne
J'ai une appli (12.5) où ça fonctionne très bien et une autre appli (12.5) où je n'ai rien dans l'onglet syntax et quand je force la syncro le message suivant :
Pourtant la DW est bien en release 12.5.
Tu as une idée ?
Hors ligne
Et tu as modifier quelque chose dans la syntaxe avant de synchroniser ?
Le fait de ne rien avoir dans la syntaxe à l'ouverture indiquerait que ta dw n'est pas initialisé (pas de dataobject ou pas de create from sql).
Ca correspond à la propriété datawindow.syntax.
Hors ligne
Même quand il y a déjà des data j'ai ce comportement. (d'ailleurs les data sont bien affichées dans l'onglet Data)
Et je récupère bien la syntaxe avec Datawindow.syntax
EDIT : forcément ça marche mieux avec les DLL SciLexer
fatigué moi, heureusement que c'est le WE
Hors ligne
Pages: 1 2