2009-11-18 6 views
3

On peut obtenir le texte de l'élément sélectionné dans la vue en liste d'un dialogue commun. Mais on ne peut pas obtenir son PIDL, et si l'utilisateur a choisi de cacher les extensions connues (la valeur par défaut), alors on ne peut pas vraiment dire quel fichier a été sélectionné sans son extension ou son PIDL.Obtenir le vrai nom du fichier actuellement sélectionné dans la boîte de dialogue de fichier commun?

façons donc possible de résoudre ce pourrait être:

  1. Obtenir une IShellView de la boîte de dialogue standard de fichier ouvert . Le IShellView sous-jacent peut dire ce que le PIDL est pour la sélection actuelle . Donc, si je pouvais simplement obtenir à partir de l'IShellView, je serais golden. Malheureusement, je ne vois aucun CDM_xxx qui le ferait. Et je ne peux pas penser du haut de ma tête de tout ce qui pourrait y parvenir! :(
  2. Une autre idée ?!

Nous avons utilisé de compter sur le fait que le Windows 9x, 2000, et la version XP de la boîte de dialogue de fichier commun stocké PIDL de chaque élément dans les données de lvItem (crédit d'origine Paul DiLascia):

LPCITEMIDLIST pidlItem = (LPCITEMIDLIST) pListCtrl-> GetItemData (nItem);

Cependant, à partir de contrôles communs de Vista et au-dessus, cette technique échoue :(

Des pensées?

EDIT: Je dois pouvoir obtenir cette information non seulement pour l'élément actuellement sélectionné dans la vue de liste, mais pour tous les éléments de la vue de liste.

EDIT2: La raison pour laquelle je dois creuser si profond:

Dans les versions précédentes de notre application, nous offrons la possibilité de: (1) Appuyez sur un bouton personnalisé « Preview » qui ferme la boîte de dialogue, mais les transferts au app la liste des éléments actuellement affichés dans la vue, dans leur ordre visible, avec l'index de celui actuellement mis en évidence. Cette liste doit être entièrement spécifiée - voir 3 fichiers qui sont tous "J1329192" (quand il y a vraiment 3 fichiers "J1329192.xyz" "J1329192.xzy" et "J1329192.zyx" [dans cet ordre) n'est pas utile.

Les utilisateurs sont autorisés à taper un filtre de nom de fichier partiel dans le champ "nom de fichier:" et la boîte de dialogue commune affiche uniquement les fichiers correspondant au filtre partiel donné, dans l'ordre de tri choisi par l'utilisateur. Donc, pour rapporter à l'application exactement ce que l'utilisateur voulait prévisualiser, il faut que nous puissions interroger cette information à partir du contrôle de vue liste (ou du dialogue commun lui-même).

Nous apportons également d'autres améliorations à la boîte de dialogue des fichiers - y compris un volet de prévisualisation qui affiche la sélection actuelle de l'utilisateur sous forme de vignette, ainsi qu'une interface personnalisée, etc. (avec beaucoup de travail) avant Vista. Post Vista, j'ai couru dans le mur sur le mur. Pour le moment, nous utilisons une boîte de dialogue de fichier standard avec seulement quelques fonctionnalités, ce qui ne correspond pas aux clients (qu'est-ce qui est arrivé à X?!)

Il y a d'autres améliorations, mais c'est un bonne vue d'ensemble Et ils se résument tous à exiger la connaissance de "vraiment, honnêtement, quel fichier est spécifiquement dans la vue à l'index X?" Et pour des raisons inconnues - Microsoft ne semble pas ressentir le besoin de fournir une telle interface. En fait, ils ne l'ont jamais fait.Ce n'est que grâce à un peu de piratage et de rétro-ingénierie que nous avons pu comprendre comment les choses fonctionnaient sous le capot et obtenir les informations nécessaires. Et oui, ce n'est pas pris en charge, et oui, MS a inévitablement enfreint notre code. Je ne les blâme pas vraiment pour ça - ce que je trouve désagréable, c'est que leur interface plus récente et plus spiffieuse est beaucoup plus fermée que leur ancienne - et ils n'ont pas fourni plus d'interfaces frontales - interfaces supportées - pour faire ces améliorations de dialogues . C'est comme s'ils faisaient un grand pas en arrière - et aucun en avant (au nom du progrès).

+0

Quel est le problème avec CDM_GETFILEPATH? – MSN

+0

Cela vous indique ce que le dialogue commun pense être le nom de fichier retourné de la boîte de dialogue - y compris l'extension par défaut, tout ce que l'utilisateur a tapé, etc .. Ce n'est pas simplement "la chose sélectionnée dans la liste" – Mordachai

+0

GetItemData vous appelez d'abord GetItem et le cast lParam? Le même? – BostonLogan

Répondre

2

Envoyez WM_USER+7 pour obtenir le navigateur, puis obtenez l'interface IShellView de l'affichage de la coque active.

Vous connaissez la conséquence habituelle de l'utilisation d'un comportement non documenté, n'est-ce pas?

+0

Je vais donner un coup de feu. Merci - et surtout merci pour le lien – Mordachai

1

Ah, je l'ai trouvé. Vous aurez besoin d'utiliser IFileOpenDialog pour Vista, ce qui devrait soutenir explicitilty toutes les opérations que vous avez mentionnées.

+0

J'étais conscient de cette interface, bu t vague sur les détails. Cela ressemble à un excellent article! Je vais essayer cette approche aussi. Je vous remercie! – Mordachai

+0

Malheureusement IFileOpenDialog ne parvient pas à vous donner un accès direct à l'objet de vue du shell - au moins de toute manière documentée. J'ai trouvé que quelqu'un a suggéré que vous pouvez interroger l'interface IShellBrowser à partir de IFileOpenDialog, que vous pouvez utiliser pour accéder à IShellView. Donc c'est plutôt bien - et pas pire que la réponse que j'ai choisie pour cette question. – Mordachai

+0

Mais finalement, je dois pouvoir ajouter d'autres contrôles personnalisés à notre version de la boîte de dialogue Open - et l'interface IFileDialog ne vous donne pas carte blanche pour ajouter vos propres contrôles (seulement ceux qu'ils ont décidé sont autorisés , comme les cases à cocher, les boutons-poussoirs et les radiobuttons - mais pas de contrôles personnalisés). Donc, pour nos objectifs ultimes, IFileDialog est une impasse ultime (enfin, techniquement, si nous passons les ressources à trouver comment étendre le shell pour prévisualiser nos fichiers personnalisés, nous pourrions faire fonctionner ce système). – Mordachai

1

Je sais qu'il s'agit d'un ancien thread mais, dans Vista +, les boîtes de dialogue de style ancien sont toujours supportées. Vous pouvez désactiver le style Vista et conserver toutes vos commandes personnalisées comme auparavant. C'est ce que nous faisons: nous avons une fenêtre de prévisualisation personnalisée dans un template accroché dans CFileDialog, qui semble impossible à reproduire dans IFileDialog.

Je crois que vous devez passer FALSE dans un paramètre BOOL dans le constructeur pour désactiver les boîtes de dialogue de style Vista.

Questions connexes