Migration de Powerbuilder 6.5 vers 10.5

Question

Nous avons une application construite avec PFC. Je suis confronté à un problème étrange. Lorsque je définis un espace de travail et n'ouvre que les bibliothèques PFC, je peux migrer et faire une construction complète. Toutefois, lorsque je l'inclue dans ma bibliothèque d'applications, il ne génère pas et me donne une erreur indiquant C0001: Type de données illégal s_printsetupattrib.

Cette erreur se produit partout où elle est utilisée.

Google n'a donné aucune réponse. J'ai essayé de régénérer s_printsetupattrib dans le pfcapsrv.pbl, et il régénère bien. L'étape suivante que j'ai essayé était de régénérer pfc_n_cst_platform (pfcapsrv.pbl), et d'autres tels objets, mais ceux-ci ne régénèrent pas, et lancent cette erreur.

Y a-t-il quelque chose dans la séquence dans laquelle le pbl doit être listé dans la liste de bibliothèque de migration d'application?

J'apprécierai toute aide en la matière.

Cordialement, Ndesai.

Answer 1

Si vous pouvez migrer votre PFC sans erreur, ce n'est pas le PFC 6.5. J'ai migré de 6,5 à 9,0 mais je n'ai plus mes notes. La configuration de l'imprimante est l'une des choses que Sybase a ajouté autour de la version 8 ou 9. PFC plus ancien a utilisé une DLL personnalisée et la structure pour afficher la boîte de dialogue d'imprimante système, mais les nouveaux vintages de PB ont l'appel intégré. Les versions plus récentes du PFC utilisent des objets au lieu de structures pour transmettre des valeurs. C'est une autre façon que je sais que vous n'utilisez pas un vieux PFC. Votre application 6.5 est cependant écrite pour l'ancien PFC.

Je vous recommande d'obtenir le latest build of the PFC for 10.5 de Codeplex. Je pense que l'aide est dans ce paquet, sinon ping et je vais vous trouver un lien. Regardez la nouvelle façon d'appeler la configuration d'impression dans PFC et changez votre code en conséquence. Il y a quelques pièges non-PFC à surveiller. Regardez à travers Terry's archive of PowerBuilder changes pour voir ce qui pourrait vous mordre. En dehors de ma tête, je pense qu'il y a des changements de comportement pour les masques d'édition, les arborescences et les événements DataWindow (dans l'ordre où ils se produisent).

Answer 2

J'ai remarqué que cette question est datée, mais en ajoutant mes 2cents puisque vous n'avez pas vraiment eu de réponse. Si vous utilisez un objet de projet et que vous exécutez le build "deploy" à partir de là et que "full build" est spécifié, PB compile automatiquement les choses dans le bon ordre, pas besoin de mettre les choses en ordre sauf si vous avez un objet dupliqué noms qui n'est pas la meilleure idée. Je suppose que je vous recommande de vérifier pour vous assurer que vous n'avez pas d'objets en double dans vos PBL aussi. Si vous rencontrez toujours des problèmes, j'ai eu des problèmes où le compilateur PB est confus comme des situations d'auto-référencement ou d'autres situations complexes et c'est un PITA, la plupart du temps cela est quelque chose qui a été mal conçu alors essayez de comprendre ce qui se passe et modifier le code, pas ce que vous voulez entendre, mais des choses se produisent.

Ou ... comme autre solution de contournement, nous avons eu du code d'erreur qui ne compile pas correctement et quand il échoue, vous trouvez l'objet qui ne compilera pas (dans votre cas celui référençant la structure) et l'ouvrirez avec le fichier -> open source, trouvez le code référençant la structure et si possible commentez-le et essayez la recompilation. Après tout compile ouvrir l'objet commenté manuellement et compiler. Ce que vous décrivez n'est pas totalement rare, vous devez parfois faire preuve de créativité, en particulier lorsque vous utilisez le PFC daté.

Sincèrement, Riche