[API Win32] Charger une icône présente dans les ressources
18 réponses
victor.thuillier
Bonjour.
J'aimerais bien savoir comment modifier l'attribut hIcon de la
structure WNDCLASS de la classe de ma fen=EAtre pour qu'il utilise
l'ic=F4ne que j'ai mise en ressource (j'ai cr=E9=E9 un fichier ressources.r=
c
et j'y ai plac=E9 la ligne suivante : 1 ICON "icone.ico").
Ma question c'est : qu'est-ce que je dois mettre dans le deuxi=E8me
argument de la fonction LoadIcon ? Le premier, c'est mon programme,
mais le second, je comprends pas ... il identifie l'ic=F4ne, oui, mais
comment ?
Voilà, il y a quelque chose que j'ai fais de travers ? Car même avec notepad ça met aussi longtemps ... alors que quand je double-clique dessus via l'explorateur, l'ouverture est instantanée (enfin, presque :p).
On 11 avr, 19:06, "mika" <m...@ole.com> wrote:
Essaie avec le notepad pour voir si c'est aussi long ...
Oui, c'est toujours aussi long ... Voici comment je procède :
Voilà, il y a quelque chose que j'ai fais de travers ? Car même avec
notepad ça met aussi longtemps ... alors que quand je double-clique
dessus via l'explorateur, l'ouverture est instantanée (enfin,
presque :p).
Voilà, il y a quelque chose que j'ai fais de travers ? Car même avec notepad ça met aussi longtemps ... alors que quand je double-clique dessus via l'explorateur, l'ouverture est instantanée (enfin, presque :p).
mika
a écrit dans le message de news:
Voilà, il y a quelque chose que j'ai fais de travers ? Car même avec notepad ça met aussi longtemps ... alors que quand je double-clique dessus via l'explorateur, l'ouverture est instantanée (enfin, presque :p).
Pas besoin de thread normalement Un appel comme ShellExecute(NULL, "open", "notepad.exe", 0, 0, SW_SHOWNORMAL); doit être immédiat
<victor.thuillier@hotmail.fr> a écrit dans le message de news:
c62cbcc8-1910-4870-9532-98d398d4435f@b1g2000vbc.googlegroups.com...
Voilà, il y a quelque chose que j'ai fais de travers ? Car même avec
notepad ça met aussi longtemps ... alors que quand je double-clique
dessus via l'explorateur, l'ouverture est instantanée (enfin,
presque :p).
Pas besoin de thread normalement
Un appel comme
ShellExecute(NULL, "open", "notepad.exe", 0, 0, SW_SHOWNORMAL);
doit être immédiat
Voilà, il y a quelque chose que j'ai fais de travers ? Car même avec notepad ça met aussi longtemps ... alors que quand je double-clique dessus via l'explorateur, l'ouverture est instantanée (enfin, presque :p).
Pas besoin de thread normalement Un appel comme ShellExecute(NULL, "open", "notepad.exe", 0, 0, SW_SHOWNORMAL); doit être immédiat
victor.thuillier
J'ai copié / collé ta ligne de code, je l'ai placé à la place de l'appel de la fonction _beginthread. La fonction ShellExecute fait patiner le programme (il ne répond plus, il est bloqué quoi) pendant 8 secondes puis d'un coup il se débloque et notepad s'ouvre.
J'ai copié / collé ta ligne de code, je l'ai placé à la place de
l'appel de la fonction _beginthread. La fonction ShellExecute fait
patiner le programme (il ne répond plus, il est bloqué quoi) pendant 8
secondes puis d'un coup il se débloque et notepad s'ouvre.
J'ai copié / collé ta ligne de code, je l'ai placé à la place de l'appel de la fonction _beginthread. La fonction ShellExecute fait patiner le programme (il ne répond plus, il est bloqué quoi) pendant 8 secondes puis d'un coup il se débloque et notepad s'ouvre.
mika
a écrit dans le message de news:
J'ai copié / collé ta ligne de code, je l'ai placé à la place de l'appel de la fonction _beginthread. La fonction ShellExecute fait patiner le programme (il ne répond plus, il est bloqué quoi) pendant 8 secondes puis d'un coup il se débloque et notepad s'ouvre.
Le problème est ailleurs. Si tu l'ajoutes au code du wizard Win32 de Visual Studio avec les options par défaut, ça doit pas faire ça...
<victor.thuillier@hotmail.fr> a écrit dans le message de news:
3fb14c7f-0b14-4539-933d-d24e15b1da1f@g36g2000vbi.googlegroups.com...
J'ai copié / collé ta ligne de code, je l'ai placé à la place de
l'appel de la fonction _beginthread. La fonction ShellExecute fait
patiner le programme (il ne répond plus, il est bloqué quoi) pendant 8
secondes puis d'un coup il se débloque et notepad s'ouvre.
Le problème est ailleurs.
Si tu l'ajoutes au code du wizard Win32 de Visual Studio avec les options
par défaut, ça doit pas faire ça...
J'ai copié / collé ta ligne de code, je l'ai placé à la place de l'appel de la fonction _beginthread. La fonction ShellExecute fait patiner le programme (il ne répond plus, il est bloqué quoi) pendant 8 secondes puis d'un coup il se débloque et notepad s'ouvre.
Le problème est ailleurs. Si tu l'ajoutes au code du wizard Win32 de Visual Studio avec les options par défaut, ça doit pas faire ça...
Sylvain SF
a écrit :
J'ai copié / collé ta ligne de code, je l'ai placé à la place de l'appel de la fonction _beginthread. La fonction ShellExecute fait patiner le programme (il ne répond plus, il est bloqué quoi) pendant 8 secondes puis d'un coup il se débloque et notepad s'ouvre.
ton pb n'est pas lié à l'API ShellExecute mais à ton environnement complet, que tu n'as pas précisé.
il est très vraisemblable que l'OS ou un anti-malware-divers s'interroge longuement sur les droits de l'utilisateur courant (user ou admin ?) à lancer un processus.
si tu es sous Vista la réponse est presque implicite, sinon cherches du coté des "outils (dit) de sécurité" installés.
Sylvain.
victor.thuillier@hotmail.fr a écrit :
J'ai copié / collé ta ligne de code, je l'ai placé à la place de
l'appel de la fonction _beginthread. La fonction ShellExecute fait
patiner le programme (il ne répond plus, il est bloqué quoi) pendant 8
secondes puis d'un coup il se débloque et notepad s'ouvre.
ton pb n'est pas lié à l'API ShellExecute mais à ton environnement
complet, que tu n'as pas précisé.
il est très vraisemblable que l'OS ou un anti-malware-divers
s'interroge longuement sur les droits de l'utilisateur courant
(user ou admin ?) à lancer un processus.
si tu es sous Vista la réponse est presque implicite, sinon
cherches du coté des "outils (dit) de sécurité" installés.
J'ai copié / collé ta ligne de code, je l'ai placé à la place de l'appel de la fonction _beginthread. La fonction ShellExecute fait patiner le programme (il ne répond plus, il est bloqué quoi) pendant 8 secondes puis d'un coup il se débloque et notepad s'ouvre.
ton pb n'est pas lié à l'API ShellExecute mais à ton environnement complet, que tu n'as pas précisé.
il est très vraisemblable que l'OS ou un anti-malware-divers s'interroge longuement sur les droits de l'utilisateur courant (user ou admin ?) à lancer un processus.
si tu es sous Vista la réponse est presque implicite, sinon cherches du coté des "outils (dit) de sécurité" installés.
Sylvain.
victor.thuillier
Je suis sous XP 2002 familial SP3, je suis sur la session Propriétaire (qui est d'ailleurs la seule session de l'ordinateur, donc administrateur) avec Avira AntiVir Personal Edition Classic comme antivirus et Sunbelt Personal Firewall comme parefeu.
Je ne comprends pas pourquoi ShellExecute met beaucoup plus de temps qu'un double clique via l'explorateur, car au fond c'est la même chose : lancement d'un programme.
Merci de m'aider. :)
Je suis sous XP 2002 familial SP3, je suis sur la session Propriétaire
(qui est d'ailleurs la seule session de l'ordinateur, donc
administrateur) avec Avira AntiVir Personal Edition Classic comme
antivirus et Sunbelt Personal Firewall comme parefeu.
Je ne comprends pas pourquoi ShellExecute met beaucoup plus de temps
qu'un double clique via l'explorateur, car au fond c'est la même
chose : lancement d'un programme.
Je suis sous XP 2002 familial SP3, je suis sur la session Propriétaire (qui est d'ailleurs la seule session de l'ordinateur, donc administrateur) avec Avira AntiVir Personal Edition Classic comme antivirus et Sunbelt Personal Firewall comme parefeu.
Je ne comprends pas pourquoi ShellExecute met beaucoup plus de temps qu'un double clique via l'explorateur, car au fond c'est la même chose : lancement d'un programme.
Merci de m'aider. :)
Sylvain SF
a écrit :
Je suis sous XP 2002 familial SP3, je suis sur la session Propriétaire (qui est d'ailleurs la seule session de l'ordinateur, donc administrateur) avec Avira AntiVir Personal Edition Classic comme antivirus et Sunbelt Personal Firewall comme parefeu.
Je ne comprends pas pourquoi ShellExecute met beaucoup plus de temps qu'un double clique via l'explorateur, car au fond c'est la même chose : lancement d'un programme.
c'est le même résultat mais pas la même action. lorsqu'un soft est lancé par l'OS suite à un clic utilisateur, il est raisonnable de penser que l'utilisateur est à l'origine de l'action. quand un soft lance un soft, les anti-malware (anti-virus, firewall, etc) peuvent craindre qu'un soft apparemment anodin essaie le lancer une tache douteuse en sous-process.
je ne sais pas si c'est votre problème mais il serait intéressant de faire le test et désactivant (à tour de role) AntiVir et Sunbelt.
autre option, non évoquée, c'est l'environnement de dév. (no précisé) qui déconne - à savoir qui peine à créer un contexte debug pour y lancer le sous process; faire des essais avec une version release du soft lancée "à la souris" serait intéressant (en la comparant à la version tournant sous Studio en mode debug).
Sylvain.
victor.thuillier@hotmail.fr a écrit :
Je suis sous XP 2002 familial SP3, je suis sur la session Propriétaire
(qui est d'ailleurs la seule session de l'ordinateur, donc
administrateur) avec Avira AntiVir Personal Edition Classic comme
antivirus et Sunbelt Personal Firewall comme parefeu.
Je ne comprends pas pourquoi ShellExecute met beaucoup plus de temps
qu'un double clique via l'explorateur, car au fond c'est la même
chose : lancement d'un programme.
c'est le même résultat mais pas la même action.
lorsqu'un soft est lancé par l'OS suite à un clic utilisateur,
il est raisonnable de penser que l'utilisateur est à l'origine
de l'action.
quand un soft lance un soft, les anti-malware (anti-virus, firewall,
etc) peuvent craindre qu'un soft apparemment anodin essaie le lancer
une tache douteuse en sous-process.
je ne sais pas si c'est votre problème mais il serait intéressant
de faire le test et désactivant (à tour de role) AntiVir et Sunbelt.
autre option, non évoquée, c'est l'environnement de dév. (no précisé)
qui déconne - à savoir qui peine à créer un contexte debug pour y
lancer le sous process; faire des essais avec une version release
du soft lancée "à la souris" serait intéressant (en la comparant à
la version tournant sous Studio en mode debug).
Je suis sous XP 2002 familial SP3, je suis sur la session Propriétaire (qui est d'ailleurs la seule session de l'ordinateur, donc administrateur) avec Avira AntiVir Personal Edition Classic comme antivirus et Sunbelt Personal Firewall comme parefeu.
Je ne comprends pas pourquoi ShellExecute met beaucoup plus de temps qu'un double clique via l'explorateur, car au fond c'est la même chose : lancement d'un programme.
c'est le même résultat mais pas la même action. lorsqu'un soft est lancé par l'OS suite à un clic utilisateur, il est raisonnable de penser que l'utilisateur est à l'origine de l'action. quand un soft lance un soft, les anti-malware (anti-virus, firewall, etc) peuvent craindre qu'un soft apparemment anodin essaie le lancer une tache douteuse en sous-process.
je ne sais pas si c'est votre problème mais il serait intéressant de faire le test et désactivant (à tour de role) AntiVir et Sunbelt.
autre option, non évoquée, c'est l'environnement de dév. (no précisé) qui déconne - à savoir qui peine à créer un contexte debug pour y lancer le sous process; faire des essais avec une version release du soft lancée "à la souris" serait intéressant (en la comparant à la version tournant sous Studio en mode debug).
Sylvain.
victor.thuillier
C'est bon, j'utilise CreateProcess et tout va mieux, il se lance directement sans m'embêter. :)
Merci à tous !
C'est bon, j'utilise CreateProcess et tout va mieux, il se lance
directement sans m'embêter. :)
