cs_PaTaTe
Messages postés2126Date d'inscriptionmercredi 21 août 2002StatutContributeurDernière intervention19 février 20212 14 oct. 2008 à 23:23
Je pensais ça aussi mais que dire alors des autres machines où j'ai tester la chose ? :)
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 14 oct. 2008 à 21:14
Ben ya pas de raison que ça marche pas alors puisque c'est que qui est utiliser par le système, l'explorateur entre-autre.
Ou alors ton Windows est vérolé, sinon je vois pas
cs_PaTaTe
Messages postés2126Date d'inscriptionmercredi 21 août 2002StatutContributeurDernière intervention19 février 20212 14 oct. 2008 à 00:14
Un PC tout ce qui a de plus normal sous Windows XP SP3.
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 13 oct. 2008 à 17:22
Tu as quelle configuration, machine, système d'exploitation, ... ?
cs_PaTaTe
Messages postés2126Date d'inscriptionmercredi 21 août 2002StatutContributeurDernière intervention19 février 20212 13 oct. 2008 à 15:03
Je sais c'est étrange ça a toujours fonctionné et il ne devrait pas en être autrement mais même ton code me sort "Pas d'association trouvée". Et pourtant l'association existe belle et bien.
Renfield
Messages postés17287Date d'inscriptionmercredi 2 janvier 2002StatutModérateurDernière intervention27 septembre 202174 13 oct. 2008 à 10:47
pas grand chose à en dire....
Private Declare Function FindExecutable Lib "shell32.dll" Alias "FindExecutableA" (ByVal lpFile As String, ByVal lpDirectory As String, ByVal lpResult As String) As Long
Private Sub Form_Load()
Dim sBuffer As String
sBuffer = Space$(260)
If FindExecutable("win.ini", Environ$("WinDIR"), sBuffer) > 32 Then
sBuffer = Left$(sBuffer, InStr(sBuffer, vbNullChar) - 1)
Else
sBuffer = "Pas d'association trouvée"
End If
MsgBox sBuffer
End Sub
cs_PaTaTe
Messages postés2126Date d'inscriptionmercredi 21 août 2002StatutContributeurDernière intervention19 février 20212 13 oct. 2008 à 02:03
Je me suis amusé à chercher des informations sur l'API FindExecutable car personnellement AUCUNS codes que j'ai pu écrire et testé le concernant n'a marché. Pourquoi ? j'aimerais bien le savoir. Aucune association n'est trouvée quelque soit le code ou l'extension utilisée. Un avis sur la question ?
Renfield
Messages postés17287Date d'inscriptionmercredi 2 janvier 2002StatutModérateurDernière intervention27 septembre 202174 2 juil. 2008 à 12:12
tu ne sembles pas avoir défini TA varaible nommmée Retour
(dont tu ne te sers pas en lecture, donc inutile ici)
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 2 juil. 2008 à 12:10
Ce n'est pas Wordpad.exe que tu dois passer en paramètre à la fonction, mais le fichier que tu veux ouvrir dans Wordpad.
Ce fichier doit déjà exister sur le disque !!!
Sinsitrus
Messages postés849Date d'inscriptionsamedi 11 juin 2005StatutMembreDernière intervention21 août 2015 2 juil. 2008 à 12:05
Variable non définie... pourquoi il m'envoie cette erreur ?
Private Sub B_NotePad_DblClick()
Retour = OuvrirFichier("C:\Program Files\Windows NT\Accessoires\wordpad.exe") ' Pour une exécution asynchrone
Retour = OuvrirFichier("C:\Program Files\Windows NT\Accessoires\wordpad.exe", False) ' Idem
Retour = OuvrirFichier("C:\Program Files\Windows NT\Accessoires\wordpad.exe", True) ' Pour une exécution synchrone
End Sub
sharkus
Messages postés43Date d'inscriptionmardi 16 juillet 2002StatutMembreDernière intervention10 juillet 2012 15 juin 2007 à 16:18
Impéccable cette source, exactement se que je cherchais, en plus bien expliqué.
Merci
wikad
Messages postés1Date d'inscriptionjeudi 26 décembre 2002StatutMembreDernière intervention 4 mars 2007 4 mars 2007 à 23:31
Merci pour la source, c'est bien fait.
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 28 sept. 2006 à 18:13
Quelqu'un qui comme moi, en travaillant sur plusieurs langages, doit avoir tendance à mélanger les subtilité de chacun d'eux.
Alors entre VB5/6, VB.NET2003, VB.NET2005, VC6, C pour µControleur, HPBasic, il y a de quoi s'y perdre.
C'est pour cela que pour l'instant (tant que pas d'utilité), j'ai renoncer à Delphi, C#, Php et autre.
cs_eldim
Messages postés956Date d'inscriptionlundi 30 mai 2005StatutMembreDernière intervention21 août 20141 28 sept. 2006 à 18:10
(croyance-informatique
religion-raison... ) très différent à chaque fois...
Renfield
Messages postés17287Date d'inscriptionmercredi 2 janvier 2002StatutModérateurDernière intervention27 septembre 202174 28 sept. 2006 à 18:06
j'ignore qui t'a appris cela... c'est pour le moins de dangereuses croyances :S
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 28 sept. 2006 à 18:00
Ok, je m'incline.
Mais j'ai les boules. On m'a toujours appris que & et AND c'était la même chose, ce n'est pas le cas.
Heureusement que dans les opérations logiques je met rarement &, je met AND car je prefère voir en clair l'opération. C'est un des tout petit reproches que je fais au C, surtout quand on mélange & et &&, ....
Renfield
Messages postés17287Date d'inscriptionmercredi 2 janvier 2002StatutModérateurDernière intervention27 septembre 202174 28 sept. 2006 à 17:47
& ne fais pas de Et logique, c'est certain. (And)
dangereux de dire que :
vbCritical & vbOKOnly = vbOkOnly
l'icone ne s'affiche pas, c'est parce que la MessageBox ne retrouve pas ses petits, et qu'en interne, il doit y avoir (en gros, je sais bien que c'est pas en VB derriere^^) :
If Style And VbCritical Then
'# Affichage de l'icone critical
End If
pour la concaténation, fais le test :
Private Sub Form_Load()
Test vbCritical & vbOKOnly
End Sub
Public Sub Test(ByVal Flags As VbMsgBoxStyle)
MsgBox Flags
End Sub
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 28 sept. 2006 à 17:29
D'ailleurs c'est faux, on dit tous une connerie depuis le début, vbCritical & vbOKOnly ne marche pas
vbCritical & vbOKOnly = vbOkOnly. L'icone (vbCritical) ne s'affiche pas.
tandis que vbCritical or vbOKOnly = vbCritical (parce que vbOkOnly=0), là, l'icone s'affiche.
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 28 sept. 2006 à 17:24
Faux Renfield
VB ne va pas faire de transtypage. Il va appliquer l'opération "Et Logiqque"
Dans ce cas ici, ça marche par vbOkOnly = 0
Mais en faisant l'opération sur admettons 3 et 5
3 And 5 1, alors que 3 Or 5 7
Renfield
Messages postés17287Date d'inscriptionmercredi 2 janvier 2002StatutModérateurDernière intervention27 septembre 202174 28 sept. 2006 à 16:38
"Renfield"
& est le symbole indiquant la concaténation de deux chaines de caractères. A defaut d'avoir deux chaines de caractère, VB va effectuer un transtypage (cast).
vbCritical, qui vaut 16, par exemple, va donner "16"
vbOkOnly, lui vaut 0. une fois "transformé" en String, ca va donner "0"
au final, tu auras effectué "16" & "0" ce qui donne bien entendu "160".
deuxième transtypage après, par la fonction MsgBox, qui attend une valeur numérique.
"160" devient alors 160
on est donc bien loin de 16 Or 0 qui donne 16
c'est pour cela qu'il faut utiliser & pour les concaténations (et pas '+' comme on le vois parfois)
et qu'il faut utiliser Or (et non And comme on le vois parfois) pour combiner des Flags...
en plus, c'est moins lourd pour le système, qui a moins de transtypages (inutiles de surcroit) a faire
romit
Messages postés160Date d'inscriptionjeudi 28 août 2003StatutMembreDernière intervention30 juin 2011 28 sept. 2006 à 16:27
RenFiled, je dis peut-etre une connerie mais je ne sais pas la différence entre.
vbCritical & vbOKOnly et vbCritical Or vbOKOnly
Lol, les deux fonctionnent, non ?
romit
Messages postés160Date d'inscriptionjeudi 28 août 2003StatutMembreDernière intervention30 juin 2011 28 sept. 2006 à 16:24
Moi ce que je dit c'est que essayer de recréer sois même ses fonctions c'est approfondir son savoir (c'est beau ce que je dis :p )
Même juste recréer une fonction sans l'integrer a un logiciel mais simplement pour voir comment elle est faite, ou par défi ^^
cs_eldim
Messages postés956Date d'inscriptionlundi 30 mai 2005StatutMembreDernière intervention21 août 20141 28 sept. 2006 à 16:06
Bonjour,
J'ai comme une impression de déja vu... lol
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 28 sept. 2006 à 10:12
Bien vu pour les options, Renfield, vbCritical Or vbOKOnly évidement.
Pour FindExecutable aussi d'ailleur.
J'ai développer ce code au départ, car le client me demandait une option pour ouvrir le manuel d'utilisation (au format pdf) depuis la page de garde du logiciel. J'ai d'abords mis le chemin de acrobat reader en dur, mais en essayant sur plusieurs pc (version différentes de AR) je me suis appercu que suivant les version de AR, les chemins d'installation étaient différents, pas possibile de coder en dur. Puis ce n'était pas forcément AR qui était installé. De plus l'exigeance était de désactiver le bouton si AR n'était pas installé sur la machine (chose qui ne devait normalement pas arrivé, puisque les machines étaient préparées en usine avant livraison).
Dans ces logiciels là, le code est divisé en 2, la partie recherche au lancement de l'appli (sub main) et la partie "shell" sur le bouton de la doc.
BruNews, je suis d'accord avec toi, une api windows sera toujours plus rapide que l'équivalent en code vb. A voir ensuite pour chaque cas, si le gain de temps, n'est pas perdu dans les appels à l'api ou dans la souplesse du code ou autres subtilités.
Renfield
Messages postés17287Date d'inscriptionmercredi 2 janvier 2002StatutModérateurDernière intervention27 septembre 202174 28 sept. 2006 à 09:28
Cela dit...
ajouter un controle avec FindExecutable, peut permettre de ne lancer un fichier (PDF, par exemple) que si une application lui est associée...
et de proposer, par exemple, de télécharger un logiciel pour le visionner...
NB: vbCritical & vbOKOnly
est, je l'espere une simple faute de frappe...(on se retrouve a passer 160 comme flag, au lieu de 16) tu voulais bien sur taper : vbCritical Or vbOKOnly
(voire même vbCritical, puisque VbOKOnly vaut 0)
BruNews
Messages postés21040Date d'inscriptionjeudi 23 janvier 2003StatutModérateurDernière intervention21 août 2019 28 sept. 2006 à 00:52
CASY, que ce soit clair, je ne mets pas en cause ton code qui est tout à fait correct.
ROMIT, je tiens par contre à rectifier ce que tu dis, important si qlq débutant passe par ici.
La programmation en vue de création, il y a des langages pour cela, VB comme tout interprété est fait pour utiliser des composants, pas grand chose d'autre. Quand tu veux faire en VB ce qui est déjà fourni, même en s'appliquant ce sera toujours plus mal et donc plus lent. Personne n'y peut rien, c'est inhérent aux interprétés.
Voyons cela par l'exemple:
- On Error GoTo OuvrirFichier_Error
chargement d'enorme structure et registres sur la pile qu'il faudra enlever en sortie, très couteux en cycles et totalement inutile si fait par API qui ne déclenche jamais d'erreur mais renvoie juste une valeur pour indiquer réussite ou échec.
- temp = Dir$(fichier)
GetFileAttributes aurait dit idem si fichier existe mais sans provoquer un SysAllocString ni le SysFreeString que vb appellera en sortie de func.
- pid = Shell(fichAOuvrir, vbMaximizedFocus)
Voila où je voulais arriver, ceci nous ramène à la CASE DEPART, Shell vb est un appel à ShellExecuteEx et tout ce qui a été fait avant a été pure perte de temps car l'API fait le check complet des arguments. Elle aurait idem en interne l'appel FindExecutable mais sans les allocs désallocs mémoire comme ceux vus plus haut ou ceux ci:
i = InStr(1, fileappli, Chr(0), vbBinaryCompare) - 1
fichAOuvrir = """" & Left$(fileappli, i) & """ " & fichier
Pour résumer, ne jamais faire par VB ce qui peut être appelé en API ou autre code natif, l'utilisateur final vous en sera reconnaissant (surtout son système).
Renfield
Messages postés17287Date d'inscriptionmercredi 2 janvier 2002StatutModérateurDernière intervention27 septembre 202174 28 sept. 2006 à 00:37
MadM@tt
Messages postés2167Date d'inscriptionmardi 11 novembre 2003StatutMembreDernière intervention16 juillet 20091 27 sept. 2006 à 23:38
Salut, Y'a du bon dans chaque code, la on peut réutiliser le tiens pour par exemple récupérer le nom de l'executable associé à une extension (et pas l'executer derrière), ce qui peut etre utile dans certains cas.
Enfin ça peut toujours servir, mais c'est vrai que ShellExecute fonctionne bien, meme si j'ai jamais fait gaffe si on pouvait attendre la fin dexecution du programme.
++
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 27 sept. 2006 à 22:49
Merci Romit.
Pour la synchro, on doit pouvoir y arriver avec ShellExecuteEx, mais au premier essai j'ai eu droit à un BSOD (c'est quand même rare sous XPSP2). Donc voilà, j'étudierais cela une autre fois.
romit
Messages postés160Date d'inscriptionjeudi 28 août 2003StatutMembreDernière intervention30 juin 2011 27 sept. 2006 à 22:45
CQFD ^^
romit
Messages postés160Date d'inscriptionjeudi 28 août 2003StatutMembreDernière intervention30 juin 2011 27 sept. 2006 à 22:42
Très juste. De plus la programmation justement c'est créer et pas utiliser ce qui est deja fait. Je suis bien conscient qu'on utilise Visual Basic ;)
Mais pourquoi ne pas essayer de recréer soi même ses fonctions. On va dire que c'est moins optimisés et tout ça. Pour 1/4 de secondes on s'en fiche complement de plus personne n'est obligé de l'utiliser !
Raison de plus: L'application peut être synchronisée avec l'application ouverte !
Donc : Pourquoi ne pas le faire sois même.
Bref je te mets 9/10 ;)
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 27 sept. 2006 à 21:56
Ok pour ShellExecute qui remplace la première partie de mon code.
Par contre comment rendre l'opération synchrone dans ce cas là ?
cs_casy
Messages postés7741Date d'inscriptionmercredi 1 septembre 2004StatutMembreDernière intervention24 septembre 201440 27 sept. 2006 à 21:41
En fait, à l'époque ou j'ai fait ce code, je ne connaissais pas ShellExecute (que je ne connais toujours pas d'ailleurs).
Comme ce code est éprouvé depuis maintenant 5ans et que le sujet reviens régulièrement sur le forum.
cs_Jack
Messages postés14006Date d'inscriptionsamedi 29 décembre 2001StatutModérateurDernière intervention28 août 201579 27 sept. 2006 à 19:49
Salut. L'API ShellExecute fait la même chose en une ligne.
Dis nous pourquoi tu as voulu passer par des chemins plus complexes, ou quels sont ses +
14 oct. 2008 à 23:23
14 oct. 2008 à 21:14
Ou alors ton Windows est vérolé, sinon je vois pas
14 oct. 2008 à 00:14
13 oct. 2008 à 17:22
13 oct. 2008 à 15:03
13 oct. 2008 à 10:47
Private Declare Function FindExecutable Lib "shell32.dll" Alias "FindExecutableA" (ByVal lpFile As String, ByVal lpDirectory As String, ByVal lpResult As String) As Long
Private Sub Form_Load()
Dim sBuffer As String
sBuffer = Space$(260)
If FindExecutable("win.ini", Environ$("WinDIR"), sBuffer) > 32 Then
sBuffer = Left$(sBuffer, InStr(sBuffer, vbNullChar) - 1)
Else
sBuffer = "Pas d'association trouvée"
End If
MsgBox sBuffer
End Sub
13 oct. 2008 à 02:03
2 juil. 2008 à 12:12
(dont tu ne te sers pas en lecture, donc inutile ici)
2 juil. 2008 à 12:10
Ce fichier doit déjà exister sur le disque !!!
2 juil. 2008 à 12:05
Private Sub B_NotePad_DblClick()
Retour = OuvrirFichier("C:\Program Files\Windows NT\Accessoires\wordpad.exe") ' Pour une exécution asynchrone
Retour = OuvrirFichier("C:\Program Files\Windows NT\Accessoires\wordpad.exe", False) ' Idem
Retour = OuvrirFichier("C:\Program Files\Windows NT\Accessoires\wordpad.exe", True) ' Pour une exécution synchrone
End Sub
15 juin 2007 à 16:18
Merci
4 mars 2007 à 23:31
28 sept. 2006 à 18:13
Alors entre VB5/6, VB.NET2003, VB.NET2005, VC6, C pour µControleur, HPBasic, il y a de quoi s'y perdre.
C'est pour cela que pour l'instant (tant que pas d'utilité), j'ai renoncer à Delphi, C#, Php et autre.
28 sept. 2006 à 18:10
religion-raison... ) très différent à chaque fois...
28 sept. 2006 à 18:06
28 sept. 2006 à 18:00
Mais j'ai les boules. On m'a toujours appris que & et AND c'était la même chose, ce n'est pas le cas.
Heureusement que dans les opérations logiques je met rarement &, je met AND car je prefère voir en clair l'opération. C'est un des tout petit reproches que je fais au C, surtout quand on mélange & et &&, ....
28 sept. 2006 à 17:47
dangereux de dire que :
vbCritical & vbOKOnly = vbOkOnly
l'icone ne s'affiche pas, c'est parce que la MessageBox ne retrouve pas ses petits, et qu'en interne, il doit y avoir (en gros, je sais bien que c'est pas en VB derriere^^) :
If Style And VbCritical Then
'# Affichage de l'icone critical
End If
pour la concaténation, fais le test :
Private Sub Form_Load()
Test vbCritical & vbOKOnly
End Sub
Public Sub Test(ByVal Flags As VbMsgBoxStyle)
MsgBox Flags
End Sub
28 sept. 2006 à 17:29
vbCritical & vbOKOnly = vbOkOnly. L'icone (vbCritical) ne s'affiche pas.
tandis que vbCritical or vbOKOnly = vbCritical (parce que vbOkOnly=0), là, l'icone s'affiche.
28 sept. 2006 à 17:24
VB ne va pas faire de transtypage. Il va appliquer l'opération "Et Logiqque"
Dans ce cas ici, ça marche par vbOkOnly = 0
Mais en faisant l'opération sur admettons 3 et 5
3 And 5 1, alors que 3 Or 5 7
28 sept. 2006 à 16:38
& est le symbole indiquant la concaténation de deux chaines de caractères. A defaut d'avoir deux chaines de caractère, VB va effectuer un transtypage (cast).
vbCritical, qui vaut 16, par exemple, va donner "16"
vbOkOnly, lui vaut 0. une fois "transformé" en String, ca va donner "0"
au final, tu auras effectué "16" & "0" ce qui donne bien entendu "160".
deuxième transtypage après, par la fonction MsgBox, qui attend une valeur numérique.
"160" devient alors 160
on est donc bien loin de 16 Or 0 qui donne 16
c'est pour cela qu'il faut utiliser & pour les concaténations (et pas '+' comme on le vois parfois)
et qu'il faut utiliser Or (et non And comme on le vois parfois) pour combiner des Flags...
en plus, c'est moins lourd pour le système, qui a moins de transtypages (inutiles de surcroit) a faire
28 sept. 2006 à 16:27
vbCritical & vbOKOnly et vbCritical Or vbOKOnly
Lol, les deux fonctionnent, non ?
28 sept. 2006 à 16:24
Même juste recréer une fonction sans l'integrer a un logiciel mais simplement pour voir comment elle est faite, ou par défi ^^
28 sept. 2006 à 16:06
J'ai comme une impression de déja vu... lol
28 sept. 2006 à 10:12
Pour FindExecutable aussi d'ailleur.
J'ai développer ce code au départ, car le client me demandait une option pour ouvrir le manuel d'utilisation (au format pdf) depuis la page de garde du logiciel. J'ai d'abords mis le chemin de acrobat reader en dur, mais en essayant sur plusieurs pc (version différentes de AR) je me suis appercu que suivant les version de AR, les chemins d'installation étaient différents, pas possibile de coder en dur. Puis ce n'était pas forcément AR qui était installé. De plus l'exigeance était de désactiver le bouton si AR n'était pas installé sur la machine (chose qui ne devait normalement pas arrivé, puisque les machines étaient préparées en usine avant livraison).
Dans ces logiciels là, le code est divisé en 2, la partie recherche au lancement de l'appli (sub main) et la partie "shell" sur le bouton de la doc.
BruNews, je suis d'accord avec toi, une api windows sera toujours plus rapide que l'équivalent en code vb. A voir ensuite pour chaque cas, si le gain de temps, n'est pas perdu dans les appels à l'api ou dans la souplesse du code ou autres subtilités.
28 sept. 2006 à 09:28
ajouter un controle avec FindExecutable, peut permettre de ne lancer un fichier (PDF, par exemple) que si une application lui est associée...
et de proposer, par exemple, de télécharger un logiciel pour le visionner...
NB: vbCritical & vbOKOnly
est, je l'espere une simple faute de frappe...(on se retrouve a passer 160 comme flag, au lieu de 16) tu voulais bien sur taper : vbCritical Or vbOKOnly
(voire même vbCritical, puisque VbOKOnly vaut 0)
28 sept. 2006 à 00:52
ROMIT, je tiens par contre à rectifier ce que tu dis, important si qlq débutant passe par ici.
La programmation en vue de création, il y a des langages pour cela, VB comme tout interprété est fait pour utiliser des composants, pas grand chose d'autre. Quand tu veux faire en VB ce qui est déjà fourni, même en s'appliquant ce sera toujours plus mal et donc plus lent. Personne n'y peut rien, c'est inhérent aux interprétés.
Voyons cela par l'exemple:
- On Error GoTo OuvrirFichier_Error
chargement d'enorme structure et registres sur la pile qu'il faudra enlever en sortie, très couteux en cycles et totalement inutile si fait par API qui ne déclenche jamais d'erreur mais renvoie juste une valeur pour indiquer réussite ou échec.
- temp = Dir$(fichier)
GetFileAttributes aurait dit idem si fichier existe mais sans provoquer un SysAllocString ni le SysFreeString que vb appellera en sortie de func.
- pid = Shell(fichAOuvrir, vbMaximizedFocus)
Voila où je voulais arriver, ceci nous ramène à la CASE DEPART, Shell vb est un appel à ShellExecuteEx et tout ce qui a été fait avant a été pure perte de temps car l'API fait le check complet des arguments. Elle aurait idem en interne l'appel FindExecutable mais sans les allocs désallocs mémoire comme ceux vus plus haut ou ceux ci:
i = InStr(1, fileappli, Chr(0), vbBinaryCompare) - 1
fichAOuvrir = """" & Left$(fileappli, i) & """ " & fichier
Pour résumer, ne jamais faire par VB ce qui peut être appelé en API ou autre code natif, l'utilisateur final vous en sera reconnaissant (surtout son système).
28 sept. 2006 à 00:37
http://www.vbfrance.com/codes/SHELLANDWAIT-EXECUTER-APPLICATION-ATTENDRE-FIN-RENVOYER-SON-CODE_34867.aspx
27 sept. 2006 à 23:38
Enfin ça peut toujours servir, mais c'est vrai que ShellExecute fonctionne bien, meme si j'ai jamais fait gaffe si on pouvait attendre la fin dexecution du programme.
++
27 sept. 2006 à 22:49
Pour la synchro, on doit pouvoir y arriver avec ShellExecuteEx, mais au premier essai j'ai eu droit à un BSOD (c'est quand même rare sous XPSP2). Donc voilà, j'étudierais cela une autre fois.
27 sept. 2006 à 22:45
27 sept. 2006 à 22:42
Mais pourquoi ne pas essayer de recréer soi même ses fonctions. On va dire que c'est moins optimisés et tout ça. Pour 1/4 de secondes on s'en fiche complement de plus personne n'est obligé de l'utiliser !
Raison de plus: L'application peut être synchronisée avec l'application ouverte !
Donc : Pourquoi ne pas le faire sois même.
Bref je te mets 9/10 ;)
27 sept. 2006 à 21:56
Par contre comment rendre l'opération synchrone dans ce cas là ?
27 sept. 2006 à 21:41
Comme ce code est éprouvé depuis maintenant 5ans et que le sujet reviens régulièrement sur le forum.
27 sept. 2006 à 19:49
Dis nous pourquoi tu as voulu passer par des chemins plus complexes, ou quels sont ses +