Comment renseigner la fiche résumé des propriétés d'un fichier (autre que .exe)

Fabien LE LEZ

21/12/2006 à 22:50

On 21 Dec 2006 00:34:08 -0800, "eulalie" :

de la fiche 'Résumé' des propriétés d'un fichier

Ça serait-y pas un machin windowsien, ça ?
Si oui, tu t'es gourée de forum.
fr.comp.os.ms-windows.programmation

James Kanze

22/12/2006 à 09:35

Fabien LE LEZ wrote:

On 21 Dec 2006 00:34:08 -0800, "eulalie" :

de la fiche 'Résumé' des propriétés d'un fichier

Ça serait-y pas un machin windowsien, ça ?
Si oui, tu t'es gourée de forum.
fr.comp.os.ms-windows.programmation

Même si ce n'est pas pour une machine Windows, si la question
concerne la façon d'afficher un onglet, il s'est trompé de
groupe. Si en revanche la question concerne la façon d'obtenir
des informations concernant le fichier... Il y a des
propositions devant le comité, basées sur boost. Je n'en connais
pas trop le contenu ; c'est un aspect dont je n'ai pas encore eu
le temps de regarder. Mais ça rend le sujet pertinant ici.

Ceci dit, j'ai l'impression que les informations qu'il veut sur
le fichier concerne plutôt son contenu. Qu'il faut qu'il ouvre
le fichier, et en lire le debut, pour les en extraire. Et
qu'évidemment, pour ce faire, il faudrait qu'il connaisse le
format du fichier. Ce qui, de nouveau, ne convient pas réelement
ici (mais http://www.wotsit.org/ est un bon point du départ, je
crois, au moins en ce qui concerne les formats
« propriétaires »).

Aussi, je ne suis pas sûr, mais je crois que dans certains cas,
Microsoft garde ce genre d'informations dans des fichiers à
part, cachés quelque part, et inaccessible à d'autres
programmes. Au moins, quand je cherche à utiliser Windows
Exploreur pour réorganiser mes fichiers audio, je ne trouve pas
où il a caché les informations concernantes le compositeur, etc.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sylvain

22/12/2006 à 23:26

James Kanze wrote on 22/12/2006 09:35:

Même si ce n'est pas pour une machine Windows, si la question
concerne la façon d'afficher un onglet, il s'est trompé de
groupe.

elle semble concerner comment ""mettre programmatiquement des infos""
pour qu'un machin (accessoirement l'interface IShellPropSheetExt
manipulée par un explorateur windows) les affiche dans les bonnes cases!...

la question semble ignorer que 1) historiquement, cet onglet n'est que
capable de lister la resource 'version' du fichier dont on demande les
propriétés, que 2) windows ne gère pas, contrairement à MacOS, un
resource fork pour chaque fichier, et donc seul les binaires avec une
telle ressource version peuvent fournir ces infos, que 3) il est
possible de fournir une shell extension qui fournit la page 'Résumé'
pour un type de fichier particulier et/ou fournit les informations
requises par la page standard (ce que MS fait avec les fichiers de la
suite Office en fournissant une shall extension qui va parser les
structures non documentées des documents office pour en sortir le titre,
auteur et autre age du capitaine).

groupe. Si en revanche la question concerne la façon d'obtenir
des informations concernant le fichier... Il y a des
propositions devant le comité, basées sur boost. Je n'en connais
pas trop le contenu ; c'est un aspect dont je n'ai pas encore eu
le temps de regarder. Mais ça rend le sujet pertinant ici.

si cela inclut la définition de meta-information sur le fichier (auteur,
liste des révisions, commentaires, ...) oui, si le propos n'est que de
(forme négative chargée d'aucun sous-entendu négatif!) normaliser les
attributs usuels (date création, modification, ...) et le moyen de les
lire/écrire (ce qui serait un réel apport positif) cela ne sert pas la QO.

Ceci dit, j'ai l'impression que les informations qu'il veut sur
le fichier concerne plutôt son contenu. Qu'il faut qu'il ouvre
le fichier, et en lire le debut, pour les en extraire. Et
qu'évidemment, pour ce faire, il faudrait qu'il connaisse le
format du fichier. [...]

cela, plus le fait de fournir les interfaces (shell extension) attendues
par l'explorateur.

Aussi, je ne suis pas sûr, mais je crois que dans certains cas,
Microsoft garde ce genre d'informations dans des fichiers à
part, cachés quelque part, et inaccessible à d'autres
programmes. Au moins, quand je cherche à utiliser Windows
Exploreur pour réorganiser mes fichiers audio, je ne trouve pas
où il a caché les informations concernantes le compositeur, etc.

sous la forme de tags ID3 ajoutés à la fin du fichier. le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.

Sylvain.

James Kanze wrote on 22/12/2006 09:35:

Même si ce n'est pas pour une machine Windows, si la question
concerne la façon d'afficher un onglet, il s'est trompé de
groupe.

elle semble concerner comment ""mettre programmatiquement des infos""
pour qu'un machin (accessoirement l'interface IShellPropSheetExt
manipulée par un explorateur windows) les affiche dans les bonnes cases!...

la question semble ignorer que 1) historiquement, cet onglet n'est que
capable de lister la resource 'version' du fichier dont on demande les
propriétés, que 2) windows ne gère pas, contrairement à MacOS, un
resource fork pour chaque fichier, et donc seul les binaires avec une
telle ressource version peuvent fournir ces infos, que 3) il est
possible de fournir une shell extension qui fournit la page 'Résumé'
pour un type de fichier particulier et/ou fournit les informations
requises par la page standard (ce que MS fait avec les fichiers de la
suite Office en fournissant une shall extension qui va parser les
structures non documentées des documents office pour en sortir le titre,
auteur et autre age du capitaine).

groupe. Si en revanche la question concerne la façon d'obtenir
des informations concernant le fichier... Il y a des
propositions devant le comité, basées sur boost. Je n'en connais
pas trop le contenu ; c'est un aspect dont je n'ai pas encore eu
le temps de regarder. Mais ça rend le sujet pertinant ici.

si cela inclut la définition de meta-information sur le fichier (auteur,
liste des révisions, commentaires, ...) oui, si le propos n'est que de
(forme négative chargée d'aucun sous-entendu négatif!) normaliser les
attributs usuels (date création, modification, ...) et le moyen de les
lire/écrire (ce qui serait un réel apport positif) cela ne sert pas la QO.

Ceci dit, j'ai l'impression que les informations qu'il veut sur
le fichier concerne plutôt son contenu. Qu'il faut qu'il ouvre
le fichier, et en lire le debut, pour les en extraire. Et
qu'évidemment, pour ce faire, il faudrait qu'il connaisse le
format du fichier. [...]

cela, plus le fait de fournir les interfaces (shell extension) attendues
par l'explorateur.

Aussi, je ne suis pas sûr, mais je crois que dans certains cas,
Microsoft garde ce genre d'informations dans des fichiers à
part, cachés quelque part, et inaccessible à d'autres
programmes. Au moins, quand je cherche à utiliser Windows
Exploreur pour réorganiser mes fichiers audio, je ne trouve pas
où il a caché les informations concernantes le compositeur, etc.

sous la forme de tags ID3 ajoutés à la fin du fichier. le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.

Sylvain.

Vous avez filtré cet utilisateur ! Consultez son message

James Kanze wrote on 22/12/2006 09:35:

Même si ce n'est pas pour une machine Windows, si la question
concerne la façon d'afficher un onglet, il s'est trompé de
groupe.

elle semble concerner comment ""mettre programmatiquement des infos""
pour qu'un machin (accessoirement l'interface IShellPropSheetExt
manipulée par un explorateur windows) les affiche dans les bonnes cases!...

la question semble ignorer que 1) historiquement, cet onglet n'est que
capable de lister la resource 'version' du fichier dont on demande les
propriétés, que 2) windows ne gère pas, contrairement à MacOS, un
resource fork pour chaque fichier, et donc seul les binaires avec une
telle ressource version peuvent fournir ces infos, que 3) il est
possible de fournir une shell extension qui fournit la page 'Résumé'
pour un type de fichier particulier et/ou fournit les informations
requises par la page standard (ce que MS fait avec les fichiers de la
suite Office en fournissant une shall extension qui va parser les
structures non documentées des documents office pour en sortir le titre,
auteur et autre age du capitaine).

groupe. Si en revanche la question concerne la façon d'obtenir
des informations concernant le fichier... Il y a des
propositions devant le comité, basées sur boost. Je n'en connais
pas trop le contenu ; c'est un aspect dont je n'ai pas encore eu
le temps de regarder. Mais ça rend le sujet pertinant ici.

si cela inclut la définition de meta-information sur le fichier (auteur,
liste des révisions, commentaires, ...) oui, si le propos n'est que de
(forme négative chargée d'aucun sous-entendu négatif!) normaliser les
attributs usuels (date création, modification, ...) et le moyen de les
lire/écrire (ce qui serait un réel apport positif) cela ne sert pas la QO.

Ceci dit, j'ai l'impression que les informations qu'il veut sur
le fichier concerne plutôt son contenu. Qu'il faut qu'il ouvre
le fichier, et en lire le debut, pour les en extraire. Et
qu'évidemment, pour ce faire, il faudrait qu'il connaisse le
format du fichier. [...]

cela, plus le fait de fournir les interfaces (shell extension) attendues
par l'explorateur.

Aussi, je ne suis pas sûr, mais je crois que dans certains cas,
Microsoft garde ce genre d'informations dans des fichiers à
part, cachés quelque part, et inaccessible à d'autres
programmes. Au moins, quand je cherche à utiliser Windows
Exploreur pour réorganiser mes fichiers audio, je ne trouve pas
où il a caché les informations concernantes le compositeur, etc.

sous la forme de tags ID3 ajoutés à la fin du fichier. le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.

Sylvain.

John Deuf

27/12/2006 à 17:15

Sylvain :

sous la forme de tags ID3 ajoutés à la fin du fichier. le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.

Bien sûr que si.
http://jc.bellamy.free.fr/fr/stream.html

--
John Deuf

Sylvain

27/12/2006 à 21:33

John Deuf wrote on 27/12/2006 17:15:

Sylvain :

sous la forme de tags ID3 ajoutés à la fin du fichier. le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.

Bien sûr que si.

même si cela était - qu'il existe un système de partition inconnu de 98%
des utilisateurs, et de plus de la moitié des développeurs, apportant un
vague succédané à cela - je ne pense pas que cela ait à voir avec fclc++

http://jc.bellamy.free.fr/fr/stream.html

à part une mise en page désastreuse et de la pub (de merde) qui déborde
/ dégueule / m'envahit, il y aurait qlq chose à y trouver ?

Sylvain.

Serge Paccalin

28/12/2006 à 08:42

Le 27.12.2006 21:33, :

le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.

Bien sûr que si.

même si cela était

Mais cela est. Un antivirus comme Kaspersky l'utilise pour stocker des
empreintes de fichier, par exemple. Les rootkits aiment bien, aussi.

je ne pense pas que cela ait à voir avec fclc++

Ah là, je suis d'accord.

http://jc.bellamy.free.fr/fr/stream.html

à part une mise en page désastreuse et de la pub (de merde) qui dé borde
/ dégueule / m'envahit, il y aurait qlq chose à y trouver ?

Quand on s'intéresse au fonctionnement de Windows, le site de
Jean-Claude Bellamy est un... must.

--
___________
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Pour bien répondre avec Google, ne pas cliquer
-'(__) « Répondre », mais « Afficher les options »,
_/___(_) puis cliquer « Répondre » (parmi les options).

John Deuf

28/12/2006 à 10:40

Sylvain :

même si cela était

Ca l'est.

qu'il existe un système de partition inconnu de 98%
des utilisateurs, et de plus de la moitié des développeurs

Ne prend pas ton cas pour une généralité.

je ne pense pas que cela ait à voir avec fclc++

Alors pourquoi as-tu abordé le sujet ?
En outre, ce n'est pas parce que ce n'est pas en charte qu'on doit laisser
passer des faussetés.

à part une mise en page désastreuse et de la pub (de merde) qui déborde
/ dégueule / m'envahit,

Il y a un dicton qui dit que la violence est le dernier refuge de
l'incompétence. Pourquoi n'as-tu pas avoué que tu t'étais trompé ? Ne
crois-tu pas que ça aurait été plus intelligent ?

Mais c'est vrai que de la façon péremptoire dont tu as dis la chose avant,
je conçois qu'il soit difficile de se rétracter. La prochaine fois tu
devrais dire "je pense que ça n'existe pas sous windows".

il y aurait qlq chose à y trouver ?

Lis-la, et tu verras. Ca parle de quelque chose que tu prétends ne pas
exister.

--
John Deuf

Sylvain

28/12/2006 à 22:02

John Deuf wrote on 28/12/2006 10:40:

Sylvain :

même si cela était

Ca l'est.

pas (mais pas du tout) au sens "fork" de MacOS, c'était mon point si
cela t'a échappé.

qu'il existe un système de partition inconnu de 98%
des utilisateurs, et de plus de la moitié des développeurs

Ne prend pas ton cas pour une généralité.

intéressante introduction de touche-pipi, dois-je perdre mon temps sur
le même niveau ?

pour citer ton mentor: "Cette fonctionnalité est assez peu connue...",
entre "peu connue" et "inconnue", je te laisse également te tater.
pour ma part, dès 1998 j'expérimentais les bugs de W2k et IIS3 et
patchais ces "::$DATA" nocifs.

je ne pense pas que cela ait à voir avec fclc++

Alors pourquoi as-tu abordé le sujet ?

pour le cadrer, lui donner du sens, posée comme telle la question
n'explique pas l'origine du besoin OR cela a nécessairement un fort
impact, sauf à vouloir coder un truc inutile pour le simple plaisir de.

En outre, ce n'est pas parce que ce n'est pas en charte qu'on doit laisser
passer des faussetés.

ton point est au moins aussi faux; laissez penser que "ça" existe (par
essence?) alors que cela reste une option non 'reliable' est une source
d'égarement pour qui te lirait.

à part une mise en page désastreuse et de la pub (de merde) qui déborde
/ dégueule / m'envahit,

Il y a un dicton qui dit que la violence est le dernier refuge de
l'incompétence.

d'où ton ton !

Pourquoi n'as-tu pas avoué que tu t'étais trompé ?

"avouer" ?? on est au tribunal ou au confessionnal ?
je ne fréquente aucun des 2 - et mon point reste exact.

Ne crois-tu pas que ça aurait été plus intelligent ?

où est l'intelligence de ta réponse ?

Mais c'est vrai que de la façon péremptoire dont tu as dis la chose avant,

tu confonds "court" et "péremptoire".

je conçois qu'il soit difficile de se rétracter. La prochaine fois tu
devrais dire "je pense que ça n'existe pas sous windows".

la prochaine fois que tu ne cernes pas l'implication d'un problème,
n'essaies pas d'inventer ce que devrait dire les autres.

pour détailler en longueur ce que tu prendras pour péremptoire si,
apparemment, je ne te détaille pas ce qui t'aura échappé:

- les pseudo-streams NTFS ne sont supportés et gérés que par NTFS
non cela n'en fait pas un 'feature reliable' sur lequel on peut baser un
développement; à moins a) de ne jamais sauvegarder sur CD/DVD (t'as lu
les normes ISO j'imagine) b) jamais échanger via clés USB (FAT/FAT32),
c) jamais mailer, d) donc de vouloir coder un truc inutile pour le
simple plaisir de. (bis)
(par comparaison lorsque MacOS enregistre ces fichiers sur un support
FAT, il créé 2 fichiers, un pour le data fork (tjrs présent), un pour
les resource fork, si nécessaire -- ici on pourra parler d'un truc qui
existe, et non d'une vague bidouille servant l'OS et lui seul, gestion
des ACL notamment).

- écrire par code les attributs affichés par l'onglet 'Résumé' de
l'explorateur n'a de sens que pour des fichiers que l'on créé (on
pourrait peut être trouver qlq rares exceptions); dans le cas contraire,
soit ces attributs sont déjà déterminés par les extensions standards de
l'explorateur (cas des fichiers images, son, ...) car ces attributs
peuvent être déterminés par analyse systématique du contenu; soit cela
consisterait à réinventer l'IHM de l'explorateur, et en particulier, le
bouton Appliquer de cet onglet, dans ce cas il paraîtra clair que les
attributs ne peuvent pas être déterminés et donc que la connaissance des
"auteurs", "mots-clés", "commentaires" ne peut venir que de la saisie
par l'utilisateur final pour, au final, les fixer par code ... qui aura
donc réinventer la propertySheet windows.

- reste donc le cas où un programme créant des fichiers (format
propriétaire ou classique) dispose (directement ou via saisie simplifié,
eg préférence globale, tel le nom du créateur) des informations à
renseigner; dans ce cas, soit on choisit la face nord (ton mentor: "il
n'existe sous Windows AUCUN outil capable de ...") qui garantit que les
infos seront potentiellement perdus dès le premier échange / transfert /
sauvegarde, voire impossible à créer (partition FATxx); soit on choisit
de coder sa propre shell extension (interface IShellPropSheetExt) que
l'on diffuse (comme DLL) avec son soft sans se soucier de la partition
hôte et en obtenant le résultat attendu sur toutes les partitions.

il y aurait qlq chose à y trouver ?

Lis-la, et tu verras. Ca parle de quelque chose que tu prétends ne pas
exister.

hmm, lis-la et tu verras, peut être, que l'existence à laquelle tu crois
(et autorise moi à ne pas souhaiter discuter des croyances que chacun
peux / à le droit / d'avoir) n'est même pas un début de réponse au PO.

Sylvain.

John Deuf wrote on 28/12/2006 10:40:

Sylvain :

même si cela était

Ca l'est.

pas (mais pas du tout) au sens "fork" de MacOS, c'était mon point si
cela t'a échappé.

qu'il existe un système de partition inconnu de 98%
des utilisateurs, et de plus de la moitié des développeurs

Ne prend pas ton cas pour une généralité.

intéressante introduction de touche-pipi, dois-je perdre mon temps sur
le même niveau ?

pour citer ton mentor: "Cette fonctionnalité est assez peu connue...",
entre "peu connue" et "inconnue", je te laisse également te tater.
pour ma part, dès 1998 j'expérimentais les bugs de W2k et IIS3 et
patchais ces "::$DATA" nocifs.

je ne pense pas que cela ait à voir avec fclc++

Alors pourquoi as-tu abordé le sujet ?

pour le cadrer, lui donner du sens, posée comme telle la question
n'explique pas l'origine du besoin OR cela a nécessairement un fort
impact, sauf à vouloir coder un truc inutile pour le simple plaisir de.

En outre, ce n'est pas parce que ce n'est pas en charte qu'on doit laisser
passer des faussetés.

ton point est au moins aussi faux; laissez penser que "ça" existe (par
essence?) alors que cela reste une option non 'reliable' est une source
d'égarement pour qui te lirait.

à part une mise en page désastreuse et de la pub (de merde) qui déborde
/ dégueule / m'envahit,

Il y a un dicton qui dit que la violence est le dernier refuge de
l'incompétence.

d'où ton ton !

Pourquoi n'as-tu pas avoué que tu t'étais trompé ?

"avouer" ?? on est au tribunal ou au confessionnal ?
je ne fréquente aucun des 2 - et mon point reste exact.

Ne crois-tu pas que ça aurait été plus intelligent ?

où est l'intelligence de ta réponse ?

Mais c'est vrai que de la façon péremptoire dont tu as dis la chose avant,

tu confonds "court" et "péremptoire".

je conçois qu'il soit difficile de se rétracter. La prochaine fois tu
devrais dire "je pense que ça n'existe pas sous windows".

la prochaine fois que tu ne cernes pas l'implication d'un problème,
n'essaies pas d'inventer ce que devrait dire les autres.

pour détailler en longueur ce que tu prendras pour péremptoire si,
apparemment, je ne te détaille pas ce qui t'aura échappé:

- les pseudo-streams NTFS ne sont supportés et gérés que par NTFS
non cela n'en fait pas un 'feature reliable' sur lequel on peut baser un
développement; à moins a) de ne jamais sauvegarder sur CD/DVD (t'as lu
les normes ISO j'imagine) b) jamais échanger via clés USB (FAT/FAT32),
c) jamais mailer, d) donc de vouloir coder un truc inutile pour le
simple plaisir de. (bis)
(par comparaison lorsque MacOS enregistre ces fichiers sur un support
FAT, il créé 2 fichiers, un pour le data fork (tjrs présent), un pour
les resource fork, si nécessaire -- ici on pourra parler d'un truc qui
existe, et non d'une vague bidouille servant l'OS et lui seul, gestion
des ACL notamment).

- écrire par code les attributs affichés par l'onglet 'Résumé' de
l'explorateur n'a de sens que pour des fichiers que l'on créé (on
pourrait peut être trouver qlq rares exceptions); dans le cas contraire,
soit ces attributs sont déjà déterminés par les extensions standards de
l'explorateur (cas des fichiers images, son, ...) car ces attributs
peuvent être déterminés par analyse systématique du contenu; soit cela
consisterait à réinventer l'IHM de l'explorateur, et en particulier, le
bouton Appliquer de cet onglet, dans ce cas il paraîtra clair que les
attributs ne peuvent pas être déterminés et donc que la connaissance des
"auteurs", "mots-clés", "commentaires" ne peut venir que de la saisie
par l'utilisateur final pour, au final, les fixer par code ... qui aura
donc réinventer la propertySheet windows.

- reste donc le cas où un programme créant des fichiers (format
propriétaire ou classique) dispose (directement ou via saisie simplifié,
eg préférence globale, tel le nom du créateur) des informations à
renseigner; dans ce cas, soit on choisit la face nord (ton mentor: "il
n'existe sous Windows AUCUN outil capable de ...") qui garantit que les
infos seront potentiellement perdus dès le premier échange / transfert /
sauvegarde, voire impossible à créer (partition FATxx); soit on choisit
de coder sa propre shell extension (interface IShellPropSheetExt) que
l'on diffuse (comme DLL) avec son soft sans se soucier de la partition
hôte et en obtenant le résultat attendu sur toutes les partitions.

il y aurait qlq chose à y trouver ?

Lis-la, et tu verras. Ca parle de quelque chose que tu prétends ne pas
exister.

hmm, lis-la et tu verras, peut être, que l'existence à laquelle tu crois
(et autorise moi à ne pas souhaiter discuter des croyances que chacun
peux / à le droit / d'avoir) n'est même pas un début de réponse au PO.

Sylvain.

Vous avez filtré cet utilisateur ! Consultez son message

John Deuf wrote on 28/12/2006 10:40:

Sylvain :

même si cela était

Ca l'est.

pas (mais pas du tout) au sens "fork" de MacOS, c'était mon point si
cela t'a échappé.

qu'il existe un système de partition inconnu de 98%
des utilisateurs, et de plus de la moitié des développeurs

Ne prend pas ton cas pour une généralité.

intéressante introduction de touche-pipi, dois-je perdre mon temps sur
le même niveau ?

pour citer ton mentor: "Cette fonctionnalité est assez peu connue...",
entre "peu connue" et "inconnue", je te laisse également te tater.
pour ma part, dès 1998 j'expérimentais les bugs de W2k et IIS3 et
patchais ces "::$DATA" nocifs.

je ne pense pas que cela ait à voir avec fclc++

Alors pourquoi as-tu abordé le sujet ?

pour le cadrer, lui donner du sens, posée comme telle la question
n'explique pas l'origine du besoin OR cela a nécessairement un fort
impact, sauf à vouloir coder un truc inutile pour le simple plaisir de.

En outre, ce n'est pas parce que ce n'est pas en charte qu'on doit laisser
passer des faussetés.

ton point est au moins aussi faux; laissez penser que "ça" existe (par
essence?) alors que cela reste une option non 'reliable' est une source
d'égarement pour qui te lirait.

à part une mise en page désastreuse et de la pub (de merde) qui déborde
/ dégueule / m'envahit,

Il y a un dicton qui dit que la violence est le dernier refuge de
l'incompétence.

d'où ton ton !

Pourquoi n'as-tu pas avoué que tu t'étais trompé ?

"avouer" ?? on est au tribunal ou au confessionnal ?
je ne fréquente aucun des 2 - et mon point reste exact.

Ne crois-tu pas que ça aurait été plus intelligent ?

où est l'intelligence de ta réponse ?

Mais c'est vrai que de la façon péremptoire dont tu as dis la chose avant,

tu confonds "court" et "péremptoire".

je conçois qu'il soit difficile de se rétracter. La prochaine fois tu
devrais dire "je pense que ça n'existe pas sous windows".

la prochaine fois que tu ne cernes pas l'implication d'un problème,
n'essaies pas d'inventer ce que devrait dire les autres.

pour détailler en longueur ce que tu prendras pour péremptoire si,
apparemment, je ne te détaille pas ce qui t'aura échappé:

- les pseudo-streams NTFS ne sont supportés et gérés que par NTFS
non cela n'en fait pas un 'feature reliable' sur lequel on peut baser un
développement; à moins a) de ne jamais sauvegarder sur CD/DVD (t'as lu
les normes ISO j'imagine) b) jamais échanger via clés USB (FAT/FAT32),
c) jamais mailer, d) donc de vouloir coder un truc inutile pour le
simple plaisir de. (bis)
(par comparaison lorsque MacOS enregistre ces fichiers sur un support
FAT, il créé 2 fichiers, un pour le data fork (tjrs présent), un pour
les resource fork, si nécessaire -- ici on pourra parler d'un truc qui
existe, et non d'une vague bidouille servant l'OS et lui seul, gestion
des ACL notamment).

- écrire par code les attributs affichés par l'onglet 'Résumé' de
l'explorateur n'a de sens que pour des fichiers que l'on créé (on
pourrait peut être trouver qlq rares exceptions); dans le cas contraire,
soit ces attributs sont déjà déterminés par les extensions standards de
l'explorateur (cas des fichiers images, son, ...) car ces attributs
peuvent être déterminés par analyse systématique du contenu; soit cela
consisterait à réinventer l'IHM de l'explorateur, et en particulier, le
bouton Appliquer de cet onglet, dans ce cas il paraîtra clair que les
attributs ne peuvent pas être déterminés et donc que la connaissance des
"auteurs", "mots-clés", "commentaires" ne peut venir que de la saisie
par l'utilisateur final pour, au final, les fixer par code ... qui aura
donc réinventer la propertySheet windows.

- reste donc le cas où un programme créant des fichiers (format
propriétaire ou classique) dispose (directement ou via saisie simplifié,
eg préférence globale, tel le nom du créateur) des informations à
renseigner; dans ce cas, soit on choisit la face nord (ton mentor: "il
n'existe sous Windows AUCUN outil capable de ...") qui garantit que les
infos seront potentiellement perdus dès le premier échange / transfert /
sauvegarde, voire impossible à créer (partition FATxx); soit on choisit
de coder sa propre shell extension (interface IShellPropSheetExt) que
l'on diffuse (comme DLL) avec son soft sans se soucier de la partition
hôte et en obtenant le résultat attendu sur toutes les partitions.

il y aurait qlq chose à y trouver ?

Lis-la, et tu verras. Ca parle de quelque chose que tu prétends ne pas
exister.

hmm, lis-la et tu verras, peut être, que l'existence à laquelle tu crois
(et autorise moi à ne pas souhaiter discuter des croyances que chacun
peux / à le droit / d'avoir) n'est même pas un début de réponse au PO.

Sylvain.

Sylvain

28/12/2006 à 22:25

Serge Paccalin wrote on 28/12/2006 08:42:

Le 27.12.2006 21:33, :

le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.
Bien sûr que si.

même si cela était

Mais cela est. Un antivirus comme Kaspersky l'utilise pour stocker des
empreintes de fichier, par exemple. Les rootkits aiment bien, aussi.

et donc il rescanne systématiquement les fichiers sains sur support ne
gérant pas les pseudo-streams NTFS; un fichier caché aurait été plus
intelligent (une shell extension permet, si besoin - is pour éviter le
rescan - de copier ce fichier en même temps que le fichier principal).

je ne pense pas que cela ait à voir avec fclc++

Ah là, je suis d'accord.

http://jc.bellamy.free.fr/fr/stream.html
à part une mise en page désastreuse et de la pub (de merde) qui déborde

/ dégueule / m'envahit, il y aurait qlq chose à y trouver ?

Quand on s'intéresse au fonctionnement de Windows, le site de
Jean-Claude Bellamy est un... must.

reste que ça dégueule de pub et que la mise en page est désastreuse:
- réaffichage de la page nouveauté à chaque redimensionnement de la page
principale,
- largeur de page excessive imposée par un inutile menu bleu mal conçu
(date de modif: inutile, favoris (mise en): inutile, "non au TCE": ???
et nécessairement inutile)
- etc

pour le fond, et parlant de la page citée, l'essentiel des infos venant
d'une recopie du MSDN, elle ne m'a rien appris, pour le reste l'approche
volontairement exhaustive peut sûrement aider qui s'intéresse ...

Sylvain.

James Kanze

31/12/2006 à 00:32

Sylvain wrote:

James Kanze wrote on 22/12/2006 09:35:

Même si ce n'est pas pour une machine Windows, si la question
concerne la façon d'afficher un onglet, il s'est trompé de
groupe.

elle semble concerner comment ""mettre programmatiquement des infos""
pour qu'un machin (accessoirement l'interface IShellPropSheetExt
manipulée par un explorateur windows) les affiche dans les bonnes cases !...

J'avout que ça ne m'était pas bien clair si sa question
concernait comment trouver les informations, comment créer un
onglet, ou comment communiquer les informations vers l'onglet.
Ou peut-être tous les trois. (Mais c'est fort possible qu'il y a
des aspects de la programmation Windows qui rend sa question
plus claire. Parce que comme chacun ici sait, je ne suis pas
particulièrement fort en Windows.)

la question semble ignorer que 1) historiquement, cet onglet n'est que
capable de lister la resource 'version' du fichier dont on demande les
propriétés, que 2) windows ne gère pas, contrairement à MacOS, un
resource fork pour chaque fichier, et donc seul les binaires avec une
telle ressource version peuvent fournir ces infos, que 3) il est
possible de fournir une shell extension qui fournit la page 'Résumé'
pour un type de fichier particulier et/ou fournit les informations
requises par la page standard (ce que MS fait avec les fichiers de la
suite Office en fournissant une shall extension qui va parser les
structures non documentées des documents office pour en sortir le titre,
auteur et autre age du capitaine).

Comme j'ai dit, je ne connais pas bien Windows. Si tu avais
écrit ce texte en arabe, je n'en aurais pas compris moins. C'est
quoi, par exemple, « la ressource 'version' » ? Voire même,
qu'est-ce que tu entends sous « ressource », quand tu parles
d'un fichier ? Je connais le concept d'un fichier de ressources
sous Java, et j'ai entendu vaguement que Windows permet
d'attacher quelque chose du genre à un fichier binaire, ce qui
me semble a priori fort utile. Mais c'est à peu près la limite
de mes connaissances. (Je sais aussi que la plupart des
gestionnaires de fenêtres, aussi bien Windows que KDE, CDE, etc.
sous X, ont un système d'associer des actions à des types de
fichiers, où en général le « type », c'est déterminé par le
suffixe du nom du fichier. Encore que ce n'est pas réelement
quelque chose du nouveau : make n'en faisait pas autrement avec
ces règles prédéfinies, il y a 25 ans ou plus. Mais ici, il
s'agit des informations générales, et non propre à chaque
fichier. Est-ce que ça a quand même un rapport ?)

groupe. Si en revanche la question concerne la façon d'obtenir
des informations concernant le fichier... Il y a des
propositions devant le comité, basées sur boost. Je n'en connais
pas trop le contenu ; c'est un aspect dont je n'ai pas encore eu
le temps de regarder. Mais ça rend le sujet pertinant ici.

si cela inclut la définition de meta-information sur le fichier (auteur,
liste des révisions, commentaires, ...) oui, si le propos n'est que de
(forme négative chargée d'aucun sous-entendu négatif!) normaliser l es
attributs usuels (date création, modification, ...) et le moyen de les
lire/écrire (ce qui serait un réel apport positif) cela ne sert pas l a QO.

En effet, pour être sujet à la normalisation, il faut bien qu'il
soit implémenté assez généralement. La norme ne reconnaît même
pas encore des répertoires, pour dire. Je crois qu'il y a une
certaine évolution à cet égard (et que les répertoires risquent
de faire leur entrée dans la norme), mais si quelque chose
n'existe pas à la fois sous Unix et sous Windows, dans une forme
à peu près semblable, je crois que ses chances à la
normalisation sont assez faibles.

Ceci dit, j'ai l'impression que les informations qu'il veut sur
le fichier concerne plutôt son contenu. Qu'il faut qu'il ouvre
le fichier, et en lire le debut, pour les en extraire. Et
qu'évidemment, pour ce faire, il faudrait qu'il connaisse le
format du fichier. [...]

cela, plus le fait de fournir les interfaces (shell extension) attendues
par l'explorateur.

Je suis prèsque sûr d'avoir mal compris quelque chose, parce que
« shell extension », pour moi, ressonne comme une extension du
programme shell. Programme qui ne sert pour ainsi dire pas sous
Windows, autant que je sache. Moi, quand je développe sous
Windows, j'utilise un shell : ksh. Et gvim. Et le make de GNU.
Et bien que je me sers du compilateur VC++, je ne sais pas
encore comment invoquer le débogueur. (Si je n'ai pas trop
l'habitude d'utiliser un débogueur sur mon propre code, j'ai eu
un problème avec GNU make où il m'aurait bien été utile.) Mais
j'ai comme une impression que mon cas n'est pas typique.

Aussi, je ne suis pas sûr, mais je crois que dans certains cas,
Microsoft garde ce genre d'informations dans des fichiers à
part, cachés quelque part, et inaccessible à d'autres
programmes. Au moins, quand je cherche à utiliser Windows
Exploreur pour réorganiser mes fichiers audio, je ne trouve pas
où il a caché les informations concernantes le compositeur, etc.

sous la forme de tags ID3 ajoutés à la fin du fichier. le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.

Encore, tu m'as perdu. C'est quoi, un tag ID3 ? Et qu'est-ce
que tu entends par gérer deux flux pour un fichier ? Ça
m'étonnerait fort que je ne pourrais pas ouvrir deux ifstream
distincts sur le même fichier. Et d'après le contexte, je ne
crois pas non plus que tu parles de quelque chose que les
informations à des priorités différentes des stream de Unix.

--
James Kanze (Gabi Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sylvain wrote:

James Kanze wrote on 22/12/2006 09:35:

Même si ce n'est pas pour une machine Windows, si la question
concerne la façon d'afficher un onglet, il s'est trompé de
groupe.

elle semble concerner comment ""mettre programmatiquement des infos""
pour qu'un machin (accessoirement l'interface IShellPropSheetExt
manipulée par un explorateur windows) les affiche dans les bonnes cases !...

J'avout que ça ne m'était pas bien clair si sa question
concernait comment trouver les informations, comment créer un
onglet, ou comment communiquer les informations vers l'onglet.
Ou peut-être tous les trois. (Mais c'est fort possible qu'il y a
des aspects de la programmation Windows qui rend sa question
plus claire. Parce que comme chacun ici sait, je ne suis pas
particulièrement fort en Windows.)

la question semble ignorer que 1) historiquement, cet onglet n'est que
capable de lister la resource 'version' du fichier dont on demande les
propriétés, que 2) windows ne gère pas, contrairement à MacOS, un
resource fork pour chaque fichier, et donc seul les binaires avec une
telle ressource version peuvent fournir ces infos, que 3) il est
possible de fournir une shell extension qui fournit la page 'Résumé'
pour un type de fichier particulier et/ou fournit les informations
requises par la page standard (ce que MS fait avec les fichiers de la
suite Office en fournissant une shall extension qui va parser les
structures non documentées des documents office pour en sortir le titre,
auteur et autre age du capitaine).

Comme j'ai dit, je ne connais pas bien Windows. Si tu avais
écrit ce texte en arabe, je n'en aurais pas compris moins. C'est
quoi, par exemple, « la ressource 'version' » ? Voire même,
qu'est-ce que tu entends sous « ressource », quand tu parles
d'un fichier ? Je connais le concept d'un fichier de ressources
sous Java, et j'ai entendu vaguement que Windows permet
d'attacher quelque chose du genre à un fichier binaire, ce qui
me semble a priori fort utile. Mais c'est à peu près la limite
de mes connaissances. (Je sais aussi que la plupart des
gestionnaires de fenêtres, aussi bien Windows que KDE, CDE, etc.
sous X, ont un système d'associer des actions à des types de
fichiers, où en général le « type », c'est déterminé par le
suffixe du nom du fichier. Encore que ce n'est pas réelement
quelque chose du nouveau : make n'en faisait pas autrement avec
ces règles prédéfinies, il y a 25 ans ou plus. Mais ici, il
s'agit des informations générales, et non propre à chaque
fichier. Est-ce que ça a quand même un rapport ?)

groupe. Si en revanche la question concerne la façon d'obtenir
des informations concernant le fichier... Il y a des
propositions devant le comité, basées sur boost. Je n'en connais
pas trop le contenu ; c'est un aspect dont je n'ai pas encore eu
le temps de regarder. Mais ça rend le sujet pertinant ici.

si cela inclut la définition de meta-information sur le fichier (auteur,
liste des révisions, commentaires, ...) oui, si le propos n'est que de
(forme négative chargée d'aucun sous-entendu négatif!) normaliser l es
attributs usuels (date création, modification, ...) et le moyen de les
lire/écrire (ce qui serait un réel apport positif) cela ne sert pas l a QO.

En effet, pour être sujet à la normalisation, il faut bien qu'il
soit implémenté assez généralement. La norme ne reconnaît même
pas encore des répertoires, pour dire. Je crois qu'il y a une
certaine évolution à cet égard (et que les répertoires risquent
de faire leur entrée dans la norme), mais si quelque chose
n'existe pas à la fois sous Unix et sous Windows, dans une forme
à peu près semblable, je crois que ses chances à la
normalisation sont assez faibles.

Ceci dit, j'ai l'impression que les informations qu'il veut sur
le fichier concerne plutôt son contenu. Qu'il faut qu'il ouvre
le fichier, et en lire le debut, pour les en extraire. Et
qu'évidemment, pour ce faire, il faudrait qu'il connaisse le
format du fichier. [...]

cela, plus le fait de fournir les interfaces (shell extension) attendues
par l'explorateur.

Je suis prèsque sûr d'avoir mal compris quelque chose, parce que
« shell extension », pour moi, ressonne comme une extension du
programme shell. Programme qui ne sert pour ainsi dire pas sous
Windows, autant que je sache. Moi, quand je développe sous
Windows, j'utilise un shell : ksh. Et gvim. Et le make de GNU.
Et bien que je me sers du compilateur VC++, je ne sais pas
encore comment invoquer le débogueur. (Si je n'ai pas trop
l'habitude d'utiliser un débogueur sur mon propre code, j'ai eu
un problème avec GNU make où il m'aurait bien été utile.) Mais
j'ai comme une impression que mon cas n'est pas typique.

Aussi, je ne suis pas sûr, mais je crois que dans certains cas,
Microsoft garde ce genre d'informations dans des fichiers à
part, cachés quelque part, et inaccessible à d'autres
programmes. Au moins, quand je cherche à utiliser Windows
Exploreur pour réorganiser mes fichiers audio, je ne trouve pas
où il a caché les informations concernantes le compositeur, etc.

sous la forme de tags ID3 ajoutés à la fin du fichier. le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.

Encore, tu m'as perdu. C'est quoi, un tag ID3 ? Et qu'est-ce
que tu entends par gérer deux flux pour un fichier ? Ça
m'étonnerait fort que je ne pourrais pas ouvrir deux ifstream
distincts sur le même fichier. Et d'après le contexte, je ne
crois pas non plus que tu parles de quelque chose que les
informations à des priorités différentes des stream de Unix.

--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Sylvain wrote:

James Kanze wrote on 22/12/2006 09:35:

Même si ce n'est pas pour une machine Windows, si la question
concerne la façon d'afficher un onglet, il s'est trompé de
groupe.

elle semble concerner comment ""mettre programmatiquement des infos""
pour qu'un machin (accessoirement l'interface IShellPropSheetExt
manipulée par un explorateur windows) les affiche dans les bonnes cases !...

J'avout que ça ne m'était pas bien clair si sa question
concernait comment trouver les informations, comment créer un
onglet, ou comment communiquer les informations vers l'onglet.
Ou peut-être tous les trois. (Mais c'est fort possible qu'il y a
des aspects de la programmation Windows qui rend sa question
plus claire. Parce que comme chacun ici sait, je ne suis pas
particulièrement fort en Windows.)

la question semble ignorer que 1) historiquement, cet onglet n'est que
capable de lister la resource 'version' du fichier dont on demande les
propriétés, que 2) windows ne gère pas, contrairement à MacOS, un
resource fork pour chaque fichier, et donc seul les binaires avec une
telle ressource version peuvent fournir ces infos, que 3) il est
possible de fournir une shell extension qui fournit la page 'Résumé'
pour un type de fichier particulier et/ou fournit les informations
requises par la page standard (ce que MS fait avec les fichiers de la
suite Office en fournissant une shall extension qui va parser les
structures non documentées des documents office pour en sortir le titre,
auteur et autre age du capitaine).

Comme j'ai dit, je ne connais pas bien Windows. Si tu avais
écrit ce texte en arabe, je n'en aurais pas compris moins. C'est
quoi, par exemple, « la ressource 'version' » ? Voire même,
qu'est-ce que tu entends sous « ressource », quand tu parles
d'un fichier ? Je connais le concept d'un fichier de ressources
sous Java, et j'ai entendu vaguement que Windows permet
d'attacher quelque chose du genre à un fichier binaire, ce qui
me semble a priori fort utile. Mais c'est à peu près la limite
de mes connaissances. (Je sais aussi que la plupart des
gestionnaires de fenêtres, aussi bien Windows que KDE, CDE, etc.
sous X, ont un système d'associer des actions à des types de
fichiers, où en général le « type », c'est déterminé par le
suffixe du nom du fichier. Encore que ce n'est pas réelement
quelque chose du nouveau : make n'en faisait pas autrement avec
ces règles prédéfinies, il y a 25 ans ou plus. Mais ici, il
s'agit des informations générales, et non propre à chaque
fichier. Est-ce que ça a quand même un rapport ?)

groupe. Si en revanche la question concerne la façon d'obtenir
des informations concernant le fichier... Il y a des
propositions devant le comité, basées sur boost. Je n'en connais
pas trop le contenu ; c'est un aspect dont je n'ai pas encore eu
le temps de regarder. Mais ça rend le sujet pertinant ici.

si cela inclut la définition de meta-information sur le fichier (auteur,
liste des révisions, commentaires, ...) oui, si le propos n'est que de
(forme négative chargée d'aucun sous-entendu négatif!) normaliser l es
attributs usuels (date création, modification, ...) et le moyen de les
lire/écrire (ce qui serait un réel apport positif) cela ne sert pas l a QO.

En effet, pour être sujet à la normalisation, il faut bien qu'il
soit implémenté assez généralement. La norme ne reconnaît même
pas encore des répertoires, pour dire. Je crois qu'il y a une
certaine évolution à cet égard (et que les répertoires risquent
de faire leur entrée dans la norme), mais si quelque chose
n'existe pas à la fois sous Unix et sous Windows, dans une forme
à peu près semblable, je crois que ses chances à la
normalisation sont assez faibles.

Ceci dit, j'ai l'impression que les informations qu'il veut sur
le fichier concerne plutôt son contenu. Qu'il faut qu'il ouvre
le fichier, et en lire le debut, pour les en extraire. Et
qu'évidemment, pour ce faire, il faudrait qu'il connaisse le
format du fichier. [...]

cela, plus le fait de fournir les interfaces (shell extension) attendues
par l'explorateur.

Je suis prèsque sûr d'avoir mal compris quelque chose, parce que
« shell extension », pour moi, ressonne comme une extension du
programme shell. Programme qui ne sert pour ainsi dire pas sous
Windows, autant que je sache. Moi, quand je développe sous
Windows, j'utilise un shell : ksh. Et gvim. Et le make de GNU.
Et bien que je me sers du compilateur VC++, je ne sais pas
encore comment invoquer le débogueur. (Si je n'ai pas trop
l'habitude d'utiliser un débogueur sur mon propre code, j'ai eu
un problème avec GNU make où il m'aurait bien été utile.) Mais
j'ai comme une impression que mon cas n'est pas typique.

Aussi, je ne suis pas sûr, mais je crois que dans certains cas,
Microsoft garde ce genre d'informations dans des fichiers à
part, cachés quelque part, et inaccessible à d'autres
programmes. Au moins, quand je cherche à utiliser Windows
Exploreur pour réorganiser mes fichiers audio, je ne trouve pas
où il a caché les informations concernantes le compositeur, etc.

sous la forme de tags ID3 ajoutés à la fin du fichier. le file system
windows ne sait pas (nativement) gérer 2 flux pour un fichier.

Encore, tu m'as perdu. C'est quoi, un tag ID3 ? Et qu'est-ce
que tu entends par gérer deux flux pour un fichier ? Ça
m'étonnerait fort que je ne pourrais pas ouvrir deux ifstream
distincts sur le même fichier. Et d'après le contexte, je ne
crois pas non plus que tu parles de quelque chose que les
informations à des priorités différentes des stream de Unix.

--
James Kanze (Gabi Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Comment renseigner la fiche résumé des propriétés d'un fichier (autre que .exe)

10 réponses

Veuillez sélectionner un problème