PureBasic

J'ai une combobox qui affiche les noms des dossiers, mais lorsque le nom dépasse la longueur de la zone d'affichage, on ne voit pas la fin du nom du dossier, voir sur l'image ci-dessous.

Je pense qu'il existe des API windows pour tronquer ce nom mais je ne trouve pas. Avez-vous une idée sur ces API.

Merci

Il y a bien une fonction qui donne le chemin court, comme sous MS Dos, mais je pense que ce n'est pas ce que tu cherches.
De toute façon, je ne me souviens pas du nom de la fonction

Sinon, ça doit assez simple de faire une fonction qui te coupe le chemin et ne garde que le nom du fichier et celui du dernier dossier, par exemple.

Un truc qui te permette de remplacer un chemin comme ça:

C:\Dossier1\Dossier2\Dossier3\Dossier4\Dossier5\Fichier.glop

en chemin comme ça:

C:\...\...\...\...\Dossier5\Fichier.glop

Ça donnerait un petit code dans ce genre là, à mettre dans une procédure: Résultat au debugger:

C:\...\...\...\...\Dossier5\Fichier.glop

Merci Chris, disons que je voulais utiliser les API.

A+
Denis

J'ai retrouvé la fonction. C'est GetShortPathName_()

Par contre, ça te donne une chaine qui est presque aussi longue que celle que tu veux convertir

tu ne peux pas ajouter un ScrollBarGadget ?

Resultat = ScrollBarGadget(#Gadget, x, y, Largeur, Hauteur, Minimum, Maximum, LongueurPage [, Options])

comme ça tu ne tronque rien ,

Dobro a écrit :tu ne peux pas ajouter un ScrollBarGadget ?

Resultat = ScrollBarGadget(#Gadget, x, y, Largeur, Hauteur, Minimum, Maximum, LongueurPage [, Options])

comme ça tu ne tronque rien ,

Une ScrollBar sur un combo!
Tu fais ça comment, toi?

oui.. bon je vais dormir

Il me semble avoir vu du code il y a longtemps sur ce sujet et je pense à LSI mais j'ai aussi la mémoire qui flanche

...

zaphod a écrit :Salut,

peut être l'api : PathCompactPathEx ?

Merci zaphod, je pense que ça correspond à ce que je cherche.
Je vais faire des essais.

A+
Denis

j'ai déjà vu ça sur certain programme, généralement le texte est tronqué mais affiché en entier dans une bulle d'aide (GadgetToolTip)

pat

Merci Chris, disons que je voulais utiliser les API.

Juste une question Denis , pourquoi utilisé des API dès lors que l'on peut s'en passer ?
imagine que l'année prochaine pour x ou y raison Microsoft change son API ( pour par exemple , forcer les dev , a passer sur une plateforme supérieur )
Comment peut tu géré cela surtout si tu as des centaines de sources à updaté ?

http://fr.wikipedia.org/wiki/Enfermemen ... C3%A9taire

C'est juste une question , pas besoin de trollé , c'est la réponse de Denis qui m'intéresse ( LSI & Jacobus aussi )

@++

Je me permets de poser cette interrogation.
Les commandes natives PB équivalente à certaines API n'utilisent-elles pas elles aussi ces API ?
Si Grosoft modifiaient une API, les commandes PB seraient elles alors aussi compromises jusqu'à ce que les devs la re-programment ?

G-Rom a écrit :

Merci Chris, disons que je voulais utiliser les API.

Juste une question Denis , pourquoi utilisé des API dès lors que l'on peut s'en passer ?
imagine que l'année prochaine pour x ou y raison Microsoft change son API ( pour par exemple , forcer les dev , a passer sur une plateforme supérieur )
Comment peut tu géré cela surtout si tu as des centaines de sources à updaté ?

http://fr.wikipedia.org/wiki/Enfermemen ... C3%A9taire

C'est juste une question , pas besoin de trollé , c'est la réponse de Denis qui m'intéresse ( LSI & Jacobus aussi )

@++

G-Rom a écrit :Juste une question Denis , pourquoi utilisé des API dès lors que l'on peut s'en passer ?

Pourquoi utiliser un tel portable alors que l'on peut s'en passer ?
Pourquoi utiliser un téléviseur alors que l'on peut s'en passer ?
Pourquoi utiliser une voiture alors que l'on peut s'en passer ?

Je n'oppose pas les API aux commandes natives de PB.
Il existe des milliers d'API éprouvées qui permettent de presque tout faire. Les utiliser permet aussi de comprendre comment Microsoft travaille. Cela réduit aussi le code final de l'executable.
En plus, ca permet de progresser un peu.

G-Rom a écrit :imagine que l'année prochaine pour x ou y raison Microsoft change son API ( pour par exemple , forcer les dev , a passer sur une plateforme supérieur )
Comment peut tu géré cela surtout si tu as des centaines de sources à updaté ?

Ce qu'il me semble (mais je ne connais pas l'ensemble des API) c'est que bien souvent Microsoft utilise des types de variables basées sur des structures, souvent ce sont ces structures qui changent avec les versions, pas les API. Cela ouvre pour la même API de nouvelles fonctionnalités. Mais MS développe aussi de nouvelles API mais la compatibilté de l'ancienne API avec le nouvel OS reste.
Pour moi, le plus difficile c'est de trouver l'API qui va bien dans la doc monstrueuse de MS, pas de l'utiliser, même si parfois on a mal à la tête et on gueule un coup parce que l'on y arrive pas.

Il est clair que si l'on veut un développement Windows, MAC, Linux, utiliser les API est possible mais entraine une compilation conditionnelle qui devient fastidieuse à gérer.

Pour finir, je pense qu'essayer de développer un logiciel en PB sous Windows sans utiliser les API devient vite difficile à faire (je ne parle pas de quelques centaines de lignes, mais de milliers).
De même, l'interception d'événements sur les gadgets reste limité, il faut prévoir les callback sous Windows.

A force d'utiliser les API d'énumération des ressources des fichiers (FindResource, FindResourceEx, LoadResource, LockResource, SizeofResource, BeginUpdateResource etc.) que je trouvais pénible au début, je me suis rendu compte plus tard que c'était franchement excellent comme système.
J'ai écris des fonctions similaires pour énumérer les fichiers au format ico et les fichiers librairie au format .icl NE pour PureIconManager. Ca marche franchement bien, cela permet de retrouver facilement les éléments du fichier que l'on recherche.

Ce que tu dis pour Microsoft est valable pour pour PB. Depuis l'an 2000 (c'est cette année là que j'ai découvert PB), les nombreuses versions de PB obligent parfois/souvent de changer son code pour qu'il fonctionne avec la nouvelle version. Certain sur le forum se souviennent peut-être qu'au début les constantes pouvaient évoluer, aujourd'hui c'est terminé. Il a fallu recoder tout les projets sur lesquels on travaillait. Des commandes PB disparaissent, d'autres évoluent et ce n'est pas toujours compatible d'une version à l'autre.

A+
Denis

Je sais que je ne suis pas un reference, mais j'aime aussi les API, je suis donc tout d'accord avec DENIS

C'est sur que pas mal de membres ici utilisent LINUX, voir MAC, et de ce fait sont obligé de se rapprocher le plus possible du natif pour que cela marche avec les deux OS

A contrario, beaucoup de membres arrivent du C, et donc de ce fait utilisent les API comme il le faisaient avec le C, mais en plus simple

Pour ma part, je n'ai pas assez de capacité pour utiliser correctement LINUX ou MAC, j'ai deja du mal avec WINDOWS, alors comme je sais que je ne coderais que pour WINDOWS, utiliser les API est une evidence et meme parfois un confort

ARS a écrit :Les commandes natives PB équivalente à certaines API n'utilisent-elles pas elles aussi ces API ?
Si Grosoft modifiaient une API, les commandes PB seraient elles alors aussi compromises jusqu'à ce que les devs la re-programment ?

Je me suis aussi posé cette question tres interessante....est ce que derriere les commandes PB il y a des API ???