Le forum (ô combien francophone) des utilisateurs de Powerbuilder.
Bonjour,
Context: PB 10.5
Serveur : MS 2008 R2 SP1
On utilise la fonction GetFileOpenName qui ouvre la fenêtre windows de navigation de fichier, de manière aléatoire lorsqu'un utilisateur a une interaction dans cette dernière, l'application est fermée sans message d'erreur et sans trace dans le journal d'évènement windows.
Quelqu'un a-t-il déjà rencontré ce problème ?
Cordialement
Yann
Hors ligne
Il y a un ancestral problème potentiel avec GetFileOpenName() / GetFileSaveName() / GetFolder() : cela change le répertoire de travail de l'application (working dir) et à la suite de cela, lors d'un accès à une ressource (image, pbx ou dll locale, ...) PB ne retrouve plus la ressource. Un symptôme courant est la perte des images dans les menus, picture controls, ce qui n'est pas fatal pour une image mais peut l'être pour un accès à une DW ou une dll.
Est-ce que vous "remettez" le répertoire de travail après avoir navigué dans un autre répertoire via GetFileOpenName() ? Si c'est "non" il est probable que le problème vienne de là.
Un contournement est de mémoriser le répertoire courant avec GetCurrentDirectory() et de le repositionner avec ChangeDirectory(). Nous on a évité le problème en créant des fonctions globales du même nom GetFileXXName() mais avec un nombre de paramètres différents et on wrappe l'appel à la vraie fonction avec la mémorisation et la restauration du répertoire courant.
Hors ligne
Bonjour,
Ce problème me rappelle quelque chose (au vue de la description de seki). J'ai contourné le problème d'une façon différente, je déclare un path propre à l'application dans la clé de registre destinée à cet effet :
HKEY_LOCAL_MACHINE\SOFTWARE\Windows\CurrentVersion\App Paths
Tu verras, en consultant cette clé, il est très facile de s'inspirer des clés existantes pour construire une clé propre à son application.
Hors ligne
Bonjour Buck,
buck a écrit:
Ce problème me rappelle quelque chose (au vue de la description de seki). J'ai contourné le problème d'une façon différente, je déclare un path propre à l'application dans la clé de registre destinée à cet effet :
HKEY_LOCAL_MACHINE\SOFTWARE\Windows\CurrentVersion\App Paths
Je connais ce paramétrage possible (à une époque on mettait toutes les dll du runtime PB dans un sous-répertoire de l'appli et on faisait pointer ce path spécifique à l'exe sur ce répertoire), mais ça permet aussi d'éviter les problèmes avec les resources ? Si tu ouvres une fenêtre contenant une image embarquée via le .pbr du projet après avoir utilisé GetFile[Open|Save]Name() et avoir changé de répertoire, est-ce que l'image est affichée correctement ?
Hors ligne
Bonjour,
Je n'ai aucun problème. D'ailleurs, le runtime PB est dans son propre répertoire et les pbd sont réparties dans plusieurs répertoires en fonction du choix de l'utilisateur au moment de l'installation selon les modules souhaités (La fonction SetLibraryList est appelé à l'ouverture de l'application pour sélectionner les pbd de l'application en fonction des modules installés).
Je n'ai pas de problème avec les ressources. On utilise très souvent GetFile[Open|Save]Name() pour différents import/export sans aucun problème (et la GED). D'ailleurs en général, on ouvre par défaut sur le répertoire Mes Documents de l'utilisateur. Je précise que je suis en PB 11.5.1 4897 et il me semble avoir rencontré ce problème lorsque notre application était en version 7 ou 9.
Comme, tu peux le voir dans l'image ci-dessous, l'application est un peu chargée au niveau des ressources :
Hors ligne
buck a écrit:
Comme, tu peux le voir dans l'image ci-dessous, l'application est un peu chargée au niveau des ressources :
Effectivement. Comment dire ? L'usage de telles textures en fond de fenêtre dans une appli pro me surprend
Il faudra que je ré-essaie si ça corrige les symptômes de ressources perdues qu'on avait rencontré ici.
PS: c'est marrant, l'icône de la fenêtre me rappelle le défun et regretté proxomitron mais avec des couleurs différentes (en négatif ?)
Dernière modification par seki (25-03-2014 12:34:53)
Hors ligne
PS: c'est marrant, l'icône de la fenêtre me rappelle le défun et regretté proxomitron mais avec des couleurs différentes (en négatif ?)
Non, rien à voir, je connais d'ailleurs pas ce produit. Toute l'iconographie a été crée entièrement chez nous par des graphistes externes ou internes.
Hors ligne
Bonjour
Je pense que je n'ai pas correctement détaillé le problème.
En fait le problème survient quand l'utilisateur remonte d'un niveau par exemple dans l'arborescence des répertoires.
L'utilisateur est encore sur la fenêtre de dialogue windows, il n'a pas pas choisis de fichier et la fenêtre se ferme en fermant l'application.
Est-ce que ce pourrait être le flag 66 qui correspond à
OFN_EXPLORER (Use an Explorer-style dialog box.) et
OFN_NOCHANGEDIR (Restore the current directory to its original value if the user changed the directory while searching for files. This option has no effect for GetOpenFileName on Windows NT, 2000, and XP.)
qui pourrait rendre GetfileOpenName instable.
Habituellement je ne précise pas ce flag (c'est un autre développeur qui a écrit ce code)GetFileOpenName("Sélection", ls_docpath, ls_docname, "", "Tous les fichiers (*.*),*.*,Fichiers PDF (*.PDF), *.PDF", ls_rep_doc_ext, 66 )
Dernière modification par ydl (28-03-2014 16:40:22)
Hors ligne
Le simple fait de changer de répertoire dans la fenêtre de sélection fait changer le répertoire courant. Est-ce que l'application utilise du code asynchrone (timers, callbacks, extensions PBNI, dlls, ...) susceptibles de continuer à fonctionner pendant le choix de fichier / répertoire ? Cela pourrait quand même venir de là.
Il faudrait tester la méthode mentionnée par Buck et mettre le répertoire de l'application dans le path propre à l'exe de l'appli.
Hors ligne
buck a écrit:
Comme, tu peux le voir dans l'image ci-dessous [...]
à propos : je me demandais d'où viennent le tab control texturé qu'on peut voir dans la fenêtre, c'est un contrôle maison ?
Hors ligne
Oui, c'est un contrôle maison
Hors ligne
Bonjour,
Même souci avec la commande Dirlist tout du moins sous version Appeon 2017R2....
Bon WE!!!
Hors ligne