Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Langage Perl Perl/Tk getOpenFile

Perl/Tk getOpenFile

18 réponses
Avatar
genomart
Bonjour,

J'utilise la m=E9thode getOpenFile pour ouvrir un popup windows et
s=E9lectionner plusieurs fichiers.
Mais j'ai un bug et je ne sais pas comment le r=E9soudre.

Voici le bout de script :

# Get the file (.txt files)
my @types =3D ( [ "Data Files", '.txt', 'TEXT' ], [ "All Files",
"*" ] );
my @TabFiles =3D $Widget->getOpenFile(
-initialdir =3D> "C:/",
-multiple =3D> 1,
-filetypes =3D> \@types,
);

J'essaye donc de s=E9lectionner plusieurs fichiers en m=EAme temps.
Dans la fen=EAtre popup windows, je peux s=E9lectionner autant de fichiers
que je souhaites. Le souci est au niveau de
@TabFiles.
Si je s=E9lectionne plus de 500 ou 600 fichiers, je n'ai pas le nombre
exact, @TabFiles est vide. en dessous, je n'ai pas de soucis.

Comment r=E9soudre ce probl=E8me ?
Y a t il une limite ? Est ce d=FB =E0 la taille du tableau @TabFiles ? Ou
bien est ce un souci Windows ?

Si j'utilise excel ou PsPad par exemple pour ouvrir ces 600 fichiers,
j'ai le m=EAme popup windows, mais ils arrivent =E0 ouvrir les fichiers
(=E7a rame, normal), mais il essaye de les ouvrir un =E0 un. Donc c'est un
souci Tk, non!!

Merci

--
genome
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Paul Gaborit
À (at) Tue, 24 Feb 2009 01:43:57 -0800 (PST),
écrivait (wrote):
2 - Apparemment, sous linux, l'option -mulitple plante, donc faudrait
aussi y faire quelque chose :-)



Le patch est minime...

3 - J'ai envoyé un mail à Mr slaven pour lui faire part du problème.



Très bien.

4 - Maintenant en ce qui concerne se limiter à 600 fichiers, le
probleme est que ce ne sera pas possible car :
- En fonction de l'utilisateur et des chemins de ses fichiers, il
pourra autant être bloqué à 400 ou 600 fichiers.
- Je ne peux pas contrôler la fenêtre de sélection de fichiers et
donc connaitre le nombre de fichiers qu'un utilisateur souhaite
sélectionner.

Donc, y a t il un moyen pour contrôler et par exemple limiter le
nombre de fichiers à sélectionner ? (Même si cette solution ne
m'arrange pas vraiment)



Non. Ce qui est dommage c'est qu'en cas de dépassement du nombre, on
ne récupère pas les /n/ premiers fichiers choisis mais carrément rien
du tout !

Existe il d'autre dialogue de sélection de fichiers, aussi jolie que
la native ?



Il y a Tk::FileSelect qui est pur Perl/Tk mais je ne crois pas qu'il
accepte les sélections multiples...

Si je dois en recréer une quel est le(s) module(s) a utiliser ?



Se baser sur Tk::FileSelect par exemple...

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
Avatar
jl_morel
Dans l'article ,
a dit...

Comme c'est aussi une limitation de l'API Windows (GetOpenFileName),
je ne suis pas sûr que ça résolve le problème. Ce qui est étonnant,
c'est qu'a priori (si j'ai bien lu la doc de Microsoft) Windows limite
à 32K pas à ~10K...




D'après la doc Microsoft de la fonction GetOpenFileName :

Note, when selecting multiple files, the total character limit for the file
names depends on the operating system and the version of the function.

Windows 95/98/Me: (only ANSI is supported) no restriction
Microsoft Windows NT4 and earlier: 32k limit
Windows 2000/XP: (ANSI) 32k limit, (Unicode) no restriction

Normalement, il ne doit pas y avoir de restriction avec Tk-804.028 qui
utilise Unicode sur un Win32 moderne.

Quand on utilise cette fonction, on alloue un tampon d'une taille par
défaut suffisante pour tous les cas usuels. Si le tampon est trop petit, la
fonction renvoie l'erreur FNERR_BUFFERTOOSMALL et donne la taille du tampon
nécessaire dans nMaxFile. On réalloue un tampon de cette taille et on
appelle une seconde fois la fonction.

Dans le fichier tkWinDialog.c le tampon est alloué sur la pile; on ne peut
pas changer sa taille. Dans le code des fonctions GetFileNameW (unicode) et
GetFileNameA (ansi) on a le commentaire :

*
* We could also check for FNERR_BUFFERTOOSMALL, but we can't
* really do anything about it when it happens.
*/

Pour bien faire, il faudrait récrire la fonction en tapant dans le tas avec
malloc...

Pour voir, j'ai recompilé Tk avec
#define TK_MULTI_MAX_PATH (MAX_PATH*160)
(donc 41600 caractères)

J'ai pu sélectionner 1600 fichiers au lieu de 800 maxi avec la version
normale.
Mais il y a toujours une limite...


--
J-L.M.
http://www.bribes.org/perl
Avatar
jl_morel
Dans l'article <d6dd223c-4b3c-4c82-ae4a-
, a dit...

Existe il d'autre dialogue de sélection de fichiers, aussi jolie que
la native ?
Si je dois en recréer une quel est le(s) module(s) a utiliser ?




Voir l'article de Slaven sur PerlTk.org:
http://www.perltk.org/index.php?option=com_content&task=view&id!&Itemid(

Il y a aussi Tk::JFileDialog mais
- le résultat n'est pas joli joli,
- le mode selection multiple ne permet pas la sélection par groupe : pour
sélectionner 600 fichiers, il faut cliquer 600 fois ! Dans un certain sens,
ça résout le problème...

--
J-L.M.
http://www.bribes.org/perl
Avatar
genomart
On 24 fév, 13:32, (Jean-Louis MOREL) wrote:
Dans l'article <d6dd223c-4b3c-4c82-ae4a-
, a dit...

>Existe il d'autre dialogue de sélection de fichiers, aussi jolie que
>la native ?
>Si je dois en recréer une quel est le(s) module(s) a utiliser ?

Voir l'article de Slaven sur PerlTk.org:
 http://www.perltk.org/index.php?option=com_content&task=view&id= 21&It...

Il y a aussi Tk::JFileDialog mais
- le résultat n'est pas joli joli,
- le mode selection multiple ne permet pas la sélection par groupe : po ur
  sélectionner 600 fichiers, il faut cliquer 600 fois ! Dans un certa in sens,
  ça résout le problème...

--
J-L.M.http://www.bribes.org/perl



Tk::JFileDialog => beurk :-)

Pour le moment, pour palier à ce problème, je demande plutôt à
l'utilisateur de sélectionner un répertoire. ensuite, moi je liste les
fichiers et si la longueur de tous les fichiers dépasse 10_000 octets,
je mets les noms de fichiers dans un widget scrolled et il sélectionne
ce qu'il souhaite, sinon, si < 10_000 alors page windows classique.

Voilà, sauf si quelqu'un a mieux à proposer.

concernant la recompilation de Tk. Faut il que je dise à slaven de
modifier cette ligne
#define TK_MULTI_MAX_PATH (MAX_PATH*160)
(donc 41600 caractères)

A combien ça devient irresonnable. *160, *1000 ou autre ?
Avatar
Paul Gaborit
À (at) 24 Feb 2009 11:24:46 GMT,
(Jean-Louis MOREL) écrivait (wrote):
D'après la doc Microsoft de la fonction GetOpenFileName :

Note, when selecting multiple files, the total character limit for the file
names depends on the operating system and the version of the function.

Windows 95/98/Me: (only ANSI is supported) no restriction
Microsoft Windows NT4 and earlier: 32k limit
Windows 2000/XP: (ANSI) 32k limit, (Unicode) no restriction

Normalement, il ne doit pas y avoir de restriction avec Tk-804.028 qui
utilise Unicode sur un Win32 moderne.

Quand on utilise cette fonction, on alloue un tampon d'une taille par
défaut suffisante pour tous les cas usuels. Si le tampon est trop petit, la
fonction renvoie l'erreur FNERR_BUFFERTOOSMALL et donne la taille du tampon
nécessaire dans nMaxFile. On réalloue un tampon de cette taille et on
appelle une seconde fois la fonction.



Et l'utilisateur doit tout re-sélectionner ou Windows a conservé
ailleurs l'information afin de pouvoir remplir la chaîne lorsqu'elle
sera assez longue ?

Dans le fichier tkWinDialog.c le tampon est alloué sur la pile; on ne peut
pas changer sa taille. Dans le code des fonctions GetFileNameW (unicode) et
GetFileNameA (ansi) on a le commentaire :

*
* We could also check for FNERR_BUFFERTOOSMALL, but we can't
* really do anything about it when it happens.
*/

Pour bien faire, il faudrait récrire la fonction en tapant dans le tas avec
malloc...



Si je comprends bien, la bonne méthode est de faire un premier appel
avec un buffer de taille nulle puis une fois que l'erreur est générée,
il suffit d'allouer la bonne taille de buffer (via 'malloc') et de
réappeler la fonction. C'est pas simple comme API mais pourquoi pas...

Une bonne suggestion à faire aux auteurs de Perl/Tk. Sauf qu'il faudra
aussi gérer la compatibilité avec l'ancienne API qui, elle, a bien une
limite arbitraire.

Pour voir, j'ai recompilé Tk avec
#define TK_MULTI_MAX_PATH (MAX_PATH*160)
(donc 41600 caractères)

J'ai pu sélectionner 1600 fichiers au lieu de 800 maxi avec la version
normale.
Mais il y a toujours une limite...



C'est ça le vrai problème : une limite arbitraire *et* aucun moyen de
savoir qu'on l'a atteinte...

En tous cas, merci pour ta lecture plus précise des docs
microsoftienne.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
Avatar
genomart
Merci pour vos réponse.
En tout cas, ça a permis de mettre la main sur une limitation qui
reste cachée et pas forcément évidente à desceller.

Je me demande s'il ne serait pas préférable de faire un retour
également sur le site de l'auteur de Tk ici
http://www.perltk.org/index.php?option=com_contact&Itemid=3
Puis sur le CPAN (dans active Bug Tk)

Qu 'en pensez vous?
Avatar
Paul Gaborit
À (at) Tue, 24 Feb 2009 05:36:26 -0800 (PST),
écrivait (wrote):
Je me demande s'il ne serait pas préférable de faire un retour
également sur le site de l'auteur de Tk ici
http://www.perltk.org/index.php?option=com_contact&Itemid=3
Puis sur le CPAN (dans active Bug Tk)

Qu 'en pensez vous?



De mon point de vue, tout est bon. Plus on laisse de traces de ce
genre de soucis, plus d'autres peuvent les retrouver et en profiter.
Cela peut aussi inciter les auteurs a améliorer le code. Le tout est
de rester courtois et respectueux du travail fourni.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>
Avatar
genomart
On 24 fév, 15:58, Paul Gaborit wrote:
À (at) Tue, 24 Feb 2009 05:36:26 -0800 (PST),
écrivait (wrote):

> Je me demande s'il ne serait pas préférable de faire un retour
> également sur le site de l'auteur de Tk ici
>http://www.perltk.org/index.php?option=com_contact&Itemid=3
> Puis sur le CPAN (dans active Bug Tk)

> Qu 'en pensez vous?

De mon point de vue, tout est bon. Plus on laisse de traces de ce
genre de soucis, plus d'autres peuvent les retrouver et en profiter.
Cela peut aussi inciter les auteurs a améliorer le code. Le tout est
de rester courtois et respectueux du travail fourni.

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Perl en français - <http://perl.mines-albi.fr/>



c'est fait
1 2