J'ai essayé l'exemple donné par APIGuide (de allapi.net, devenu
mentalis.org si je ne m'abuse) pour ShellExecuteEx, et ça fonctionne
très bien (tel quel).
Le "verb" fourni est "Properties", et effectivement ça ouvre la boîte de
propriétés du fichier indiqué -en fait après avoir corrigé le nom du
fichier, car celui proposé n'existe pas sur mon système.
Si je ne m'abuse, ça devrait marcher aussi avec d'autres verbes ?
J'ai essayé print, effectivement j'ai un message m'indiquant que les
pages successives sont en préparation d'impression -j'interromps, il
s'agissait juste de savoir si ça marche.
Mais alors maintenant "open", ça ne lui fait ni chaud ni froid.
J'ai enlevé SEE_MASK_FLAG_NO_UI, alors si je change l'orthographe du
verbe il me rappelle à l'ordre. open lui convient, mais pour dormir.
D'habitude pour dormir on ferme les rideaux, non ?
D'aileurs, c'est un fichier texte, et le verbe Properties n'est pas
propre à ce type de fichiers si je ne m'abuse.
"open" est un verbe prévu dans la clef HKEY_CLASSES_ROOT\txtfile\shell
du registre. On y trouve aussi print.
Dans le menu contextuel les actions proposées sont exprimées en Français.
De toute manière, si je ne m'abuse, comme c'est lpfile qui est renseigné
et non lpIDlist, ce sont les valeurs du registre qui priment. Ce qui
explique que open est accepté (pas de message d'erreur) et non ouvrir.
Un double-clic sur le fichier dans l'explorateur fonctionne.
C'est quoi qui m'a échappé ?
C'est vrai je pourrais faire un Shell mais j'aimerais bien être sûr de
ne pas me tromper de fenêtre pour écrire dedans. On peut utiliser
ShellExecuteEx sur Notepad, aussi, mais là de toute manière le problème
est le même : ni chaud ni froid, comme Windows Media Player quand il dit
qu'il est "prêt".
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
Jacques93
Gloops a écrit :
Bonjour tout le monde,
J'ai essayé l'exemple donné par APIGuide (de allapi.net, devenu mentalis.org si je ne m'abuse) pour ShellExecuteEx, et ça fonctionne très bien (tel quel).
Le "verb" fourni est "Properties", et effectivement ça ouvre la boîte de propriétés du fichier indiqué -en fait après avoir corrigé le nom du fichier, car celui proposé n'existe pas sur mon système.
Si je ne m'abuse, ça devrait marcher aussi avec d'autres verbes ?
J'ai essayé print, effectivement j'ai un message m'indiquant que les pages successives sont en préparation d'impression -j'interromps, il s'agissait juste de savoir si ça marche.
Mais alors maintenant "open", ça ne lui fait ni chaud ni froid.
J'ai enlevé SEE_MASK_FLAG_NO_UI, alors si je change l'orthographe du verbe il me rappelle à l'ordre. open lui convient, mais pour dormir. D'habitude pour dormir on ferme les rideaux, non ?
D'aileurs, c'est un fichier texte, et le verbe Properties n'est pas propre à ce type de fichiers si je ne m'abuse.
"open" est un verbe prévu dans la clef HKEY_CLASSES_ROOTtxtfileshell du registre. On y trouve aussi print.
Dans le menu contextuel les actions proposées sont exprimées en Français.
De toute manière, si je ne m'abuse, comme c'est lpfile qui est renseigné et non lpIDlist, ce sont les valeurs du registre qui priment. Ce qui explique que open est accepté (pas de message d'erreur) et non ouvrir.
Un double-clic sur le fichier dans l'explorateur fonctionne.
C'est quoi qui m'a échappé ?
C'est vrai je pourrais faire un Shell mais j'aimerais bien être sûr de ne pas me tromper de fenêtre pour écrire dedans. On peut utiliser ShellExecuteEx sur Notepad, aussi, mais là de toute manière le problème est le même : ni chaud ni froid, comme Windows Media Player quand il dit qu'il est "prêt".
Sub ShowProps(FileName As String, OwnerhWnd As Long) Dim SEI As SHELLEXECUTEINFO Dim r As Long With SEI 'Set the structure's size .cbSize = Len(SEI) 'Seet the mask .fMask = SEE_MASK_FLAG_NO_UI 'Set the owner window .hwnd = OwnerhWnd 'Show the properties .lpVerb = "open" 'Set the filename .lpFile = FileName .lpParameters = vbNullChar .lpDirectory = vbNullChar .nShow = SW_SHOWNORMAL ' ou SW_SHOWMAXIMIZED .hInstApp = 0 .lpIDList = 0 End With r = ShellExecuteEx(SEI) End Sub
-- Cordialement,
Jacques.
Gloops a écrit :
Bonjour tout le monde,
J'ai essayé l'exemple donné par APIGuide (de allapi.net, devenu
mentalis.org si je ne m'abuse) pour ShellExecuteEx, et ça fonctionne
très bien (tel quel).
Le "verb" fourni est "Properties", et effectivement ça ouvre la boîte de
propriétés du fichier indiqué -en fait après avoir corrigé le nom du
fichier, car celui proposé n'existe pas sur mon système.
Si je ne m'abuse, ça devrait marcher aussi avec d'autres verbes ?
J'ai essayé print, effectivement j'ai un message m'indiquant que les
pages successives sont en préparation d'impression -j'interromps, il
s'agissait juste de savoir si ça marche.
Mais alors maintenant "open", ça ne lui fait ni chaud ni froid.
J'ai enlevé SEE_MASK_FLAG_NO_UI, alors si je change l'orthographe du
verbe il me rappelle à l'ordre. open lui convient, mais pour dormir.
D'habitude pour dormir on ferme les rideaux, non ?
D'aileurs, c'est un fichier texte, et le verbe Properties n'est pas
propre à ce type de fichiers si je ne m'abuse.
"open" est un verbe prévu dans la clef HKEY_CLASSES_ROOTtxtfileshell
du registre. On y trouve aussi print.
Dans le menu contextuel les actions proposées sont exprimées en Français.
De toute manière, si je ne m'abuse, comme c'est lpfile qui est renseigné
et non lpIDlist, ce sont les valeurs du registre qui priment. Ce qui
explique que open est accepté (pas de message d'erreur) et non ouvrir.
Un double-clic sur le fichier dans l'explorateur fonctionne.
C'est quoi qui m'a échappé ?
C'est vrai je pourrais faire un Shell mais j'aimerais bien être sûr de
ne pas me tromper de fenêtre pour écrire dedans. On peut utiliser
ShellExecuteEx sur Notepad, aussi, mais là de toute manière le problème
est le même : ni chaud ni froid, comme Windows Media Player quand il dit
qu'il est "prêt".
Sub ShowProps(FileName As String, OwnerhWnd As Long)
Dim SEI As SHELLEXECUTEINFO
Dim r As Long
With SEI
'Set the structure's size
.cbSize = Len(SEI)
'Seet the mask
.fMask = SEE_MASK_FLAG_NO_UI
'Set the owner window
.hwnd = OwnerhWnd
'Show the properties
.lpVerb = "open"
'Set the filename
.lpFile = FileName
.lpParameters = vbNullChar
.lpDirectory = vbNullChar
.nShow = SW_SHOWNORMAL ' ou SW_SHOWMAXIMIZED
.hInstApp = 0
.lpIDList = 0
End With
r = ShellExecuteEx(SEI)
End Sub
J'ai essayé l'exemple donné par APIGuide (de allapi.net, devenu mentalis.org si je ne m'abuse) pour ShellExecuteEx, et ça fonctionne très bien (tel quel).
Le "verb" fourni est "Properties", et effectivement ça ouvre la boîte de propriétés du fichier indiqué -en fait après avoir corrigé le nom du fichier, car celui proposé n'existe pas sur mon système.
Si je ne m'abuse, ça devrait marcher aussi avec d'autres verbes ?
J'ai essayé print, effectivement j'ai un message m'indiquant que les pages successives sont en préparation d'impression -j'interromps, il s'agissait juste de savoir si ça marche.
Mais alors maintenant "open", ça ne lui fait ni chaud ni froid.
J'ai enlevé SEE_MASK_FLAG_NO_UI, alors si je change l'orthographe du verbe il me rappelle à l'ordre. open lui convient, mais pour dormir. D'habitude pour dormir on ferme les rideaux, non ?
D'aileurs, c'est un fichier texte, et le verbe Properties n'est pas propre à ce type de fichiers si je ne m'abuse.
"open" est un verbe prévu dans la clef HKEY_CLASSES_ROOTtxtfileshell du registre. On y trouve aussi print.
Dans le menu contextuel les actions proposées sont exprimées en Français.
De toute manière, si je ne m'abuse, comme c'est lpfile qui est renseigné et non lpIDlist, ce sont les valeurs du registre qui priment. Ce qui explique que open est accepté (pas de message d'erreur) et non ouvrir.
Un double-clic sur le fichier dans l'explorateur fonctionne.
C'est quoi qui m'a échappé ?
C'est vrai je pourrais faire un Shell mais j'aimerais bien être sûr de ne pas me tromper de fenêtre pour écrire dedans. On peut utiliser ShellExecuteEx sur Notepad, aussi, mais là de toute manière le problème est le même : ni chaud ni froid, comme Windows Media Player quand il dit qu'il est "prêt".
Sub ShowProps(FileName As String, OwnerhWnd As Long) Dim SEI As SHELLEXECUTEINFO Dim r As Long With SEI 'Set the structure's size .cbSize = Len(SEI) 'Seet the mask .fMask = SEE_MASK_FLAG_NO_UI 'Set the owner window .hwnd = OwnerhWnd 'Show the properties .lpVerb = "open" 'Set the filename .lpFile = FileName .lpParameters = vbNullChar .lpDirectory = vbNullChar .nShow = SW_SHOWNORMAL ' ou SW_SHOWMAXIMIZED .hInstApp = 0 .lpIDList = 0 End With r = ShellExecuteEx(SEI) End Sub
-- Cordialement,
Jacques.
Gloops
Youpi ça marche !
Juste le mode d'affichage, alors ?
Merci.
Je croyais qu'on récupérait le numéro de la nouvelle fenêtre dans SEI.hWnd, mais apparemment non, il va falloir plutôt convertir hpInstApp. Il y a quelques notions que je ne maîtrise pas vraiment là, il va falloir que je plonge dans le bouquin. ________________________________________ Jacques93 a écrit, le 26/10/2005 12:50 :
Sub ShowProps(FileName As String, OwnerhWnd As Long) Dim SEI As SHELLEXECUTEINFO Dim r As Long With SEI 'Set the structure's size .cbSize = Len(SEI) 'Seet the mask .fMask = SEE_MASK_FLAG_NO_UI 'Set the owner window .hwnd = OwnerhWnd 'Show the properties .lpVerb = "open" 'Set the filename .lpFile = FileName .lpParameters = vbNullChar .lpDirectory = vbNullChar .nShow = SW_SHOWNORMAL ' ou SW_SHOWMAXIMIZED .hInstApp = 0 .lpIDList = 0 End With r = ShellExecuteEx(SEI) End Sub
Youpi ça marche !
Juste le mode d'affichage, alors ?
Merci.
Je croyais qu'on récupérait le numéro de la nouvelle fenêtre dans
SEI.hWnd, mais apparemment non, il va falloir plutôt convertir
hpInstApp. Il y a quelques notions que je ne maîtrise pas vraiment là,
il va falloir que je plonge dans le bouquin.
________________________________________
Jacques93 a écrit, le 26/10/2005 12:50 :
Sub ShowProps(FileName As String, OwnerhWnd As Long)
Dim SEI As SHELLEXECUTEINFO
Dim r As Long
With SEI
'Set the structure's size
.cbSize = Len(SEI)
'Seet the mask
.fMask = SEE_MASK_FLAG_NO_UI
'Set the owner window
.hwnd = OwnerhWnd
'Show the properties
.lpVerb = "open"
'Set the filename
.lpFile = FileName
.lpParameters = vbNullChar
.lpDirectory = vbNullChar
.nShow = SW_SHOWNORMAL ' ou SW_SHOWMAXIMIZED
.hInstApp = 0
.lpIDList = 0
End With
r = ShellExecuteEx(SEI)
End Sub
Je croyais qu'on récupérait le numéro de la nouvelle fenêtre dans SEI.hWnd, mais apparemment non, il va falloir plutôt convertir hpInstApp. Il y a quelques notions que je ne maîtrise pas vraiment là, il va falloir que je plonge dans le bouquin. ________________________________________ Jacques93 a écrit, le 26/10/2005 12:50 :
Sub ShowProps(FileName As String, OwnerhWnd As Long) Dim SEI As SHELLEXECUTEINFO Dim r As Long With SEI 'Set the structure's size .cbSize = Len(SEI) 'Seet the mask .fMask = SEE_MASK_FLAG_NO_UI 'Set the owner window .hwnd = OwnerhWnd 'Show the properties .lpVerb = "open" 'Set the filename .lpFile = FileName .lpParameters = vbNullChar .lpDirectory = vbNullChar .nShow = SW_SHOWNORMAL ' ou SW_SHOWMAXIMIZED .hInstApp = 0 .lpIDList = 0 End With r = ShellExecuteEx(SEI) End Sub
Jacques93
Bonjour Gloops, Gloops a écrit :
Youpi ça marche !
Juste le mode d'affichage, alors ?
Merci.
Je croyais qu'on récupérait le numéro de la nouvelle fenêtre dans SEI.hWnd, mais apparemment non, il va falloir plutôt convertir hpInstApp. Il y a quelques notions que je ne maîtrise pas vraiment là, il va falloir que je plonge dans le bouquin.
La valeur renvoyée dans sei.hWnd est celle de la fenêtre à laquelle vont être attacher les MessageBox si il y a une erreur lors de l'execution de ShellExecute. C'est le hWnd de la fenêtre VB ...
-- Cordialement,
Jacques.
Bonjour Gloops,
Gloops a écrit :
Youpi ça marche !
Juste le mode d'affichage, alors ?
Merci.
Je croyais qu'on récupérait le numéro de la nouvelle fenêtre dans
SEI.hWnd, mais apparemment non, il va falloir plutôt convertir
hpInstApp. Il y a quelques notions que je ne maîtrise pas vraiment là,
il va falloir que je plonge dans le bouquin.
La valeur renvoyée dans sei.hWnd est celle de la fenêtre à laquelle vont
être attacher les MessageBox si il y a une erreur lors de l'execution de
ShellExecute. C'est le hWnd de la fenêtre VB ...
Je croyais qu'on récupérait le numéro de la nouvelle fenêtre dans SEI.hWnd, mais apparemment non, il va falloir plutôt convertir hpInstApp. Il y a quelques notions que je ne maîtrise pas vraiment là, il va falloir que je plonge dans le bouquin.
La valeur renvoyée dans sei.hWnd est celle de la fenêtre à laquelle vont être attacher les MessageBox si il y a une erreur lors de l'execution de ShellExecute. C'est le hWnd de la fenêtre VB ...
-- Cordialement,
Jacques.
Gloops
C'est fou comme je me suis compliqué l'existence avec peu de choses.
L'appel du fichier texte avec ShellExecute l'ouvre avec l'application par défaut, et puis fini.
Sinon, pour un message court, on peut afficher une fenêtre en s'inspirant de ceci :
http://www.shrinkwrapvb.com/createw.htm
Mais alors là, il y a un truc qui m'intrigue. ça marche bien tant qu'on ne touche pas au module qui ouvre la fenêtre. Si on met ne serait-ce qu'une apostrophe de commentaire, à l'exécution VB plante. Si on a sauvegardé avant d'exécuter, au chargement suivant ça marche. Donc, si on veut modifier le message, soit on l'inscrit dans un fichier, soit on le prépare depuis un autre module.
Pour un message qui tient à l'écran ça m'a l'air d'être une piste à explorer, il y a quelques modifs à faire pour que l'utilisateur puisse copier le texte. En revanche avec ça si il y un défilement à faire il faut le gérer soi-même il me semble.
C'est fou comme je me suis compliqué l'existence avec peu de choses.
L'appel du fichier texte avec ShellExecute l'ouvre avec l'application
par défaut, et puis fini.
Sinon, pour un message court, on peut afficher une fenêtre en
s'inspirant de ceci :
http://www.shrinkwrapvb.com/createw.htm
Mais alors là, il y a un truc qui m'intrigue. ça marche bien tant qu'on
ne touche pas au module qui ouvre la fenêtre. Si on met ne serait-ce
qu'une apostrophe de commentaire, à l'exécution VB plante. Si on a
sauvegardé avant d'exécuter, au chargement suivant ça marche. Donc, si
on veut modifier le message, soit on l'inscrit dans un fichier, soit on
le prépare depuis un autre module.
Pour un message qui tient à l'écran ça m'a l'air d'être une piste à
explorer, il y a quelques modifs à faire pour que l'utilisateur puisse
copier le texte. En revanche avec ça si il y un défilement à faire il
faut le gérer soi-même il me semble.
C'est fou comme je me suis compliqué l'existence avec peu de choses.
L'appel du fichier texte avec ShellExecute l'ouvre avec l'application par défaut, et puis fini.
Sinon, pour un message court, on peut afficher une fenêtre en s'inspirant de ceci :
http://www.shrinkwrapvb.com/createw.htm
Mais alors là, il y a un truc qui m'intrigue. ça marche bien tant qu'on ne touche pas au module qui ouvre la fenêtre. Si on met ne serait-ce qu'une apostrophe de commentaire, à l'exécution VB plante. Si on a sauvegardé avant d'exécuter, au chargement suivant ça marche. Donc, si on veut modifier le message, soit on l'inscrit dans un fichier, soit on le prépare depuis un autre module.
Pour un message qui tient à l'écran ça m'a l'air d'être une piste à explorer, il y a quelques modifs à faire pour que l'utilisateur puisse copier le texte. En revanche avec ça si il y un défilement à faire il faut le gérer soi-même il me semble.
parci
On Fri, 28 Oct 2005 02:32:59 +0200, Gloops wrote:
Sinon, pour un message court, on peut afficher une fenêtre en s'inspirant de ceci :
http://www.shrinkwrapvb.com/createw.htm
Mais alors là, il y a un truc qui m'intrigue. ça marche bien tant qu'on ne touche pas au module qui ouvre la fenêtre. Si on met ne serait-ce qu'une apostrophe de commentaire, à l'exécution VB plante. Si on a sauvegardé avant d'exécuter, au chargement suivant ça marche. Donc, si on veut modifier le message, soit on l'inscrit dans un fichier, soit on le prépare depuis un autre module.
Je peux modifier le module sans plantage (VB5).
Pour un message qui tient à l'écran ça m'a l'air d'être une piste à explorer, il y a quelques modifs à faire pour que l'utilisateur puisse copier le texte. En revanche avec ça si il y un défilement à faire il faut le gérer soi-même il me semble.
Il faut tout gérer dans la WindowProc. C'est bien de faire du C, mais si c'est pour faire de manière compliquée ce que permet simplement VB via un form par exemple, je ne vois pas trop l'intérêt. Un peu comme si tu remplaçais la fonction MsgBox de VB par l'API MessageBox (2 fonctions strictement équivalentes).
On Fri, 28 Oct 2005 02:32:59 +0200, Gloops <gloops@niark.fr> wrote:
Sinon, pour un message court, on peut afficher une fenêtre en
s'inspirant de ceci :
http://www.shrinkwrapvb.com/createw.htm
Mais alors là, il y a un truc qui m'intrigue. ça marche bien tant qu'on
ne touche pas au module qui ouvre la fenêtre. Si on met ne serait-ce
qu'une apostrophe de commentaire, à l'exécution VB plante. Si on a
sauvegardé avant d'exécuter, au chargement suivant ça marche. Donc, si
on veut modifier le message, soit on l'inscrit dans un fichier, soit on
le prépare depuis un autre module.
Je peux modifier le module sans plantage (VB5).
Pour un message qui tient à l'écran ça m'a l'air d'être une piste à
explorer, il y a quelques modifs à faire pour que l'utilisateur puisse
copier le texte. En revanche avec ça si il y un défilement à faire il
faut le gérer soi-même il me semble.
Il faut tout gérer dans la WindowProc. C'est bien de faire du C, mais
si c'est pour faire de manière compliquée ce que permet simplement VB
via un form par exemple, je ne vois pas trop l'intérêt.
Un peu comme si tu remplaçais la fonction MsgBox de VB par l'API
MessageBox (2 fonctions strictement équivalentes).
Sinon, pour un message court, on peut afficher une fenêtre en s'inspirant de ceci :
http://www.shrinkwrapvb.com/createw.htm
Mais alors là, il y a un truc qui m'intrigue. ça marche bien tant qu'on ne touche pas au module qui ouvre la fenêtre. Si on met ne serait-ce qu'une apostrophe de commentaire, à l'exécution VB plante. Si on a sauvegardé avant d'exécuter, au chargement suivant ça marche. Donc, si on veut modifier le message, soit on l'inscrit dans un fichier, soit on le prépare depuis un autre module.
Je peux modifier le module sans plantage (VB5).
Pour un message qui tient à l'écran ça m'a l'air d'être une piste à explorer, il y a quelques modifs à faire pour que l'utilisateur puisse copier le texte. En revanche avec ça si il y un défilement à faire il faut le gérer soi-même il me semble.
Il faut tout gérer dans la WindowProc. C'est bien de faire du C, mais si c'est pour faire de manière compliquée ce que permet simplement VB via un form par exemple, je ne vois pas trop l'intérêt. Un peu comme si tu remplaçais la fonction MsgBox de VB par l'API MessageBox (2 fonctions strictement équivalentes).
Gloops
parci a écrit, le 29/10/2005 23:21 :
Je peux modifier le module sans plantage (VB5).
Ah, c'est chez moi que ça coince, alors ? Bon, tant que je n'ai pas à le faire toutes les cinq minutes ... On pourrait s'amuser à chercher par curiosité, enfin ça dépend si il y a quelqu'un que ça branche. D'autant que ça promet d'être un truc à chercher un bout de temps.
Il faut tout gérer dans la WindowProc. C'est bien de faire du C, mais si c'est pour faire de manière compliquée ce que permet simplement VB via un form par exemple, je ne vois pas trop l'intérêt. Un peu comme si tu remplaçais la fonction MsgBox de VB par l'API MessageBox (2 fonctions strictement équivalentes).
Ah, c'est sûr, si le langage permet de faire les choses plus simplement, c'est dommage de s'en priver.
En fait, je cherchais comment afficher une boîte de message dont l'utilisateur puisse copier le contenu dans le presse-papiers. Une fois que ça serait au point je mettrais ça dans mes procédures d'erreur. Serais-je parti sur une fausse piste ?
Parce que MsgBox, pour sélectionner quelque chose dedans et le copier dans le presse-papiers, il faut être doué. A part faire une copie d'écran, mais comme optimisation des messageries, ce n'est pas top.
parci a écrit, le 29/10/2005 23:21 :
Je peux modifier le module sans plantage (VB5).
Ah, c'est chez moi que ça coince, alors ?
Bon, tant que je n'ai pas à le faire toutes les cinq minutes ...
On pourrait s'amuser à chercher par curiosité, enfin ça dépend si il y a
quelqu'un que ça branche. D'autant que ça promet d'être un truc à
chercher un bout de temps.
Il faut tout gérer dans la WindowProc. C'est bien de faire du C, mais
si c'est pour faire de manière compliquée ce que permet simplement VB
via un form par exemple, je ne vois pas trop l'intérêt.
Un peu comme si tu remplaçais la fonction MsgBox de VB par l'API
MessageBox (2 fonctions strictement équivalentes).
Ah, c'est sûr, si le langage permet de faire les choses plus simplement,
c'est dommage de s'en priver.
En fait, je cherchais comment afficher une boîte de message dont
l'utilisateur puisse copier le contenu dans le presse-papiers. Une fois
que ça serait au point je mettrais ça dans mes procédures d'erreur.
Serais-je parti sur une fausse piste ?
Parce que MsgBox, pour sélectionner quelque chose dedans et le copier
dans le presse-papiers, il faut être doué. A part faire une copie
d'écran, mais comme optimisation des messageries, ce n'est pas top.
Ah, c'est chez moi que ça coince, alors ? Bon, tant que je n'ai pas à le faire toutes les cinq minutes ... On pourrait s'amuser à chercher par curiosité, enfin ça dépend si il y a quelqu'un que ça branche. D'autant que ça promet d'être un truc à chercher un bout de temps.
Il faut tout gérer dans la WindowProc. C'est bien de faire du C, mais si c'est pour faire de manière compliquée ce que permet simplement VB via un form par exemple, je ne vois pas trop l'intérêt. Un peu comme si tu remplaçais la fonction MsgBox de VB par l'API MessageBox (2 fonctions strictement équivalentes).
Ah, c'est sûr, si le langage permet de faire les choses plus simplement, c'est dommage de s'en priver.
En fait, je cherchais comment afficher une boîte de message dont l'utilisateur puisse copier le contenu dans le presse-papiers. Une fois que ça serait au point je mettrais ça dans mes procédures d'erreur. Serais-je parti sur une fausse piste ?
Parce que MsgBox, pour sélectionner quelque chose dedans et le copier dans le presse-papiers, il faut être doué. A part faire une copie d'écran, mais comme optimisation des messageries, ce n'est pas top.
parci
On Sun, 30 Oct 2005 21:49:39 +0100, Gloops wrote:
En fait, je cherchais comment afficher une boîte de message dont l'utilisateur puisse copier le contenu dans le presse-papiers. Une fois que ça serait au point je mettrais ça dans mes procédures d'erreur. Serais-je parti sur une fausse piste ?
Un form avec un textbox.
Parce que MsgBox, pour sélectionner quelque chose dedans et le copier dans le presse-papiers, il faut être doué.
Retrouver le texte d'une zone static pour une fenêtre de type dialog, c'est pas très compliqué à faire (tu pourrais le programmer dans un petit utilitaire).
A part faire une copie d'écran, mais comme optimisation des messageries, ce n'est pas top.
Tu peux aussi écrire une fonction qui place le texte dans le presse-papier avant de l'afficher.
On Sun, 30 Oct 2005 21:49:39 +0100, Gloops <gloops@niark.fr> wrote:
En fait, je cherchais comment afficher une boîte de message dont
l'utilisateur puisse copier le contenu dans le presse-papiers. Une fois
que ça serait au point je mettrais ça dans mes procédures d'erreur.
Serais-je parti sur une fausse piste ?
Un form avec un textbox.
Parce que MsgBox, pour sélectionner quelque chose dedans et le copier
dans le presse-papiers, il faut être doué.
Retrouver le texte d'une zone static pour une fenêtre de type dialog,
c'est pas très compliqué à faire (tu pourrais le programmer dans un
petit utilitaire).
A part faire une copie
d'écran, mais comme optimisation des messageries, ce n'est pas top.
Tu peux aussi écrire une fonction qui place le texte dans le
presse-papier avant de l'afficher.
En fait, je cherchais comment afficher une boîte de message dont l'utilisateur puisse copier le contenu dans le presse-papiers. Une fois que ça serait au point je mettrais ça dans mes procédures d'erreur. Serais-je parti sur une fausse piste ?
Un form avec un textbox.
Parce que MsgBox, pour sélectionner quelque chose dedans et le copier dans le presse-papiers, il faut être doué.
Retrouver le texte d'une zone static pour une fenêtre de type dialog, c'est pas très compliqué à faire (tu pourrais le programmer dans un petit utilitaire).
A part faire une copie d'écran, mais comme optimisation des messageries, ce n'est pas top.
Tu peux aussi écrire une fonction qui place le texte dans le presse-papier avant de l'afficher.
Gloops
parci a écrit, le 30/10/2005 22:48 :
On Sun, 30 Oct 2005 21:49:39 +0100, Gloops wrote:
En fait, je cherchais comment afficher une boîte de message dont l'utilisateur puisse copier le contenu dans le presse-papiers. Une fois que ça serait au point je mettrais ça dans mes procédures d'erreur. Serais-je parti sur une fausse piste ?
Un form avec un textbox.
Oui, j'avais bien fait ça, sous Access.
Après quand j'ai vu afficher un message sans formulaire autour http://www.mvps.org/accessfr/forms/frm0046.htm
je me suis dit qu'il devait y avoir moyen d'affiner un peu.
ça ce n'était pas la réponse, mais je n'étais pas sûr d'être allé au bout ...
Parce que MsgBox, pour sélectionner quelque chose dedans et le copier dans le presse-papiers, il faut être doué.
Retrouver le texte d'une zone static pour une fenêtre de type dialog, c'est pas très compliqué à faire (tu pourrais le programmer dans un petit utilitaire).
Oui le stockage de la donnée c'est effectivement une question aussi, si on creuse ça c'est pour optimiser. En attendant je cherche surtout pour afficher. C'est vrai qu'il y a la création d'un formulaire. Tu penses que c'est le mieux alors ?
Je vais voir par là ... Un formulaire passe-partout, que je n'aurai qu'à importer dans chaque nouvelle application. Là il faudra préfixer le nom de la procédure avec celui du formulaire, aussi. Sinon il faut importer un module en plus.
A part faire une copie d'écran, mais comme optimisation des messageries, ce n'est pas top.
Tu peux aussi écrire une fonction qui place le texte dans le presse-papier avant de l'afficher.
Effectivement je sentais venir cette objection. Après il faut aussi faire savoir à l'utilisateur que le message est dans le presse-papiers. C'est vrai qu'on peut allonger le message pour le dire, à condition de ne pas atteindre la longueur limite, si il y en a une.
L'avantage avec un truc évident sur le plan graphique, c'est que ça marche même avant qu'on ait eu le temps de traduire les messages de l'application. A condition bien sûr que le mec en face de l'écran soit un petit peu fufu, si il voit un message dans une zone de texte, il va faire une copie pour vous montrer ça quand vous serez revenus de déjeuner. Alors que si c'est écrit, dans une langue qu'il comprend mal, que le message est copié dans le presse-papiers, il ne va pas forcément savoir le conserver.
parci a écrit, le 30/10/2005 22:48 :
On Sun, 30 Oct 2005 21:49:39 +0100, Gloops <gloops@niark.fr> wrote:
En fait, je cherchais comment afficher une boîte de message dont
l'utilisateur puisse copier le contenu dans le presse-papiers. Une fois
que ça serait au point je mettrais ça dans mes procédures d'erreur.
Serais-je parti sur une fausse piste ?
Un form avec un textbox.
Oui, j'avais bien fait ça, sous Access.
Après quand j'ai vu afficher un message sans formulaire autour
http://www.mvps.org/accessfr/forms/frm0046.htm
je me suis dit qu'il devait y avoir moyen d'affiner un peu.
ça ce n'était pas la réponse, mais je n'étais pas sûr d'être allé au
bout ...
Parce que MsgBox, pour sélectionner quelque chose dedans et le copier
dans le presse-papiers, il faut être doué.
Retrouver le texte d'une zone static pour une fenêtre de type dialog,
c'est pas très compliqué à faire (tu pourrais le programmer dans un
petit utilitaire).
Oui le stockage de la donnée c'est effectivement une question aussi, si
on creuse ça c'est pour optimiser. En attendant je cherche surtout pour
afficher. C'est vrai qu'il y a la création d'un formulaire. Tu penses
que c'est le mieux alors ?
Je vais voir par là ... Un formulaire passe-partout, que je n'aurai qu'à
importer dans chaque nouvelle application. Là il faudra préfixer le nom
de la procédure avec celui du formulaire, aussi. Sinon il faut importer
un module en plus.
A part faire une copie
d'écran, mais comme optimisation des messageries, ce n'est pas top.
Tu peux aussi écrire une fonction qui place le texte dans le
presse-papier avant de l'afficher.
Effectivement je sentais venir cette objection.
Après il faut aussi faire savoir à l'utilisateur que le message est dans
le presse-papiers. C'est vrai qu'on peut allonger le message pour le
dire, à condition de ne pas atteindre la longueur limite, si il y en a une.
L'avantage avec un truc évident sur le plan graphique, c'est que ça
marche même avant qu'on ait eu le temps de traduire les messages de
l'application.
A condition bien sûr que le mec en face de l'écran soit un petit peu
fufu, si il voit un message dans une zone de texte, il va faire une
copie pour vous montrer ça quand vous serez revenus de déjeuner. Alors
que si c'est écrit, dans une langue qu'il comprend mal, que le message
est copié dans le presse-papiers, il ne va pas forcément savoir le
conserver.
En fait, je cherchais comment afficher une boîte de message dont l'utilisateur puisse copier le contenu dans le presse-papiers. Une fois que ça serait au point je mettrais ça dans mes procédures d'erreur. Serais-je parti sur une fausse piste ?
Un form avec un textbox.
Oui, j'avais bien fait ça, sous Access.
Après quand j'ai vu afficher un message sans formulaire autour http://www.mvps.org/accessfr/forms/frm0046.htm
je me suis dit qu'il devait y avoir moyen d'affiner un peu.
ça ce n'était pas la réponse, mais je n'étais pas sûr d'être allé au bout ...
Parce que MsgBox, pour sélectionner quelque chose dedans et le copier dans le presse-papiers, il faut être doué.
Retrouver le texte d'une zone static pour une fenêtre de type dialog, c'est pas très compliqué à faire (tu pourrais le programmer dans un petit utilitaire).
Oui le stockage de la donnée c'est effectivement une question aussi, si on creuse ça c'est pour optimiser. En attendant je cherche surtout pour afficher. C'est vrai qu'il y a la création d'un formulaire. Tu penses que c'est le mieux alors ?
Je vais voir par là ... Un formulaire passe-partout, que je n'aurai qu'à importer dans chaque nouvelle application. Là il faudra préfixer le nom de la procédure avec celui du formulaire, aussi. Sinon il faut importer un module en plus.
A part faire une copie d'écran, mais comme optimisation des messageries, ce n'est pas top.
Tu peux aussi écrire une fonction qui place le texte dans le presse-papier avant de l'afficher.
Effectivement je sentais venir cette objection. Après il faut aussi faire savoir à l'utilisateur que le message est dans le presse-papiers. C'est vrai qu'on peut allonger le message pour le dire, à condition de ne pas atteindre la longueur limite, si il y en a une.
L'avantage avec un truc évident sur le plan graphique, c'est que ça marche même avant qu'on ait eu le temps de traduire les messages de l'application. A condition bien sûr que le mec en face de l'écran soit un petit peu fufu, si il voit un message dans une zone de texte, il va faire une copie pour vous montrer ça quand vous serez revenus de déjeuner. Alors que si c'est écrit, dans une langue qu'il comprend mal, que le message est copié dans le presse-papiers, il ne va pas forcément savoir le conserver.
parci
On Sun, 30 Oct 2005 23:44:45 +0100, Gloops wrote:
C'est vrai qu'il y a la création d'un formulaire. Tu penses que c'est le mieux alors ?
Pas vraiment. Tu peux aussi écrire les erreurs dans une log et demander à l'utilisateur de joindre ce fichier plutôt qu'une copie de l'écran. Là aussi, tu peux écrire une fonction réutilisable dans toute appli (le chemin du fichier log peut être fonction de App.Path et d'une constante pour le nom du fichier, par exemple).
Tu as intérêt à implémenter ton gestionnaire d'erreur avec MZTools (http://www.mztools.com/) pour que l'appel de cette fonction soit systématique.
On Sun, 30 Oct 2005 23:44:45 +0100, Gloops <gloops@niark.fr> wrote:
C'est vrai qu'il y a la création d'un formulaire. Tu penses
que c'est le mieux alors ?
Pas vraiment.
Tu peux aussi écrire les erreurs dans une log et demander à
l'utilisateur de joindre ce fichier plutôt qu'une copie de l'écran.
Là aussi, tu peux écrire une fonction réutilisable dans toute appli
(le chemin du fichier log peut être fonction de App.Path et d'une
constante pour le nom du fichier, par exemple).
Tu as intérêt à implémenter ton gestionnaire d'erreur avec MZTools
(http://www.mztools.com/) pour que l'appel de cette fonction soit
systématique.
C'est vrai qu'il y a la création d'un formulaire. Tu penses que c'est le mieux alors ?
Pas vraiment. Tu peux aussi écrire les erreurs dans une log et demander à l'utilisateur de joindre ce fichier plutôt qu'une copie de l'écran. Là aussi, tu peux écrire une fonction réutilisable dans toute appli (le chemin du fichier log peut être fonction de App.Path et d'une constante pour le nom du fichier, par exemple).
Tu as intérêt à implémenter ton gestionnaire d'erreur avec MZTools (http://www.mztools.com/) pour que l'appel de cette fonction soit systématique.
Gloops
parci a écrit, le 31/10/2005 19:43 :
On Sun, 30 Oct 2005 23:44:45 +0100, Gloops wrote:
C'est vrai qu'il y a la création d'un formulaire. Tu penses que c'est le mieux alors ?
Pas vraiment. Tu peux aussi écrire les erreurs dans une log et demander à l'utilisateur de joindre ce fichier plutôt qu'une copie de l'écran. Là aussi, tu peux écrire une fonction réutilisable dans toute appli (le chemin du fichier log peut être fonction de App.Path et d'une constante pour le nom du fichier, par exemple).
Effectivement, et j'irais même jusqu'à automatiser l'envoi du mail. Bien entendu, il arrive un moment où il faut se calmer, parce que si une erreur se produit pendant la procédure d'erreur, on n'est pas vraiment avancé. D'ailleurs arrivé là il ne faut pas se louper, car il faut penser à autoriser au niveau du pare-feu. J'imagine qu'il vaut mieux faire les choses en plusieurs fois, et se contenter de faire apparaître un bouton sur le formulaire de menu, qui transmettra le mail. Comme ça la première procédure d'erreur n'est pas perturbée par des problèmes de réseau.
Tu as intérêt à implémenter ton gestionnaire d'erreur avec MZTools (http://www.mztools.com/) pour que l'appel de cette fonction soit systématique.
ça a l'air pas mal ce truc. Je ne l'ai pas encore installé car je suis en panne de sauvegardes, mais ça ne devrait guère tarder.
parci a écrit, le 31/10/2005 19:43 :
On Sun, 30 Oct 2005 23:44:45 +0100, Gloops <gloops@niark.fr> wrote:
C'est vrai qu'il y a la création d'un formulaire. Tu penses
que c'est le mieux alors ?
Pas vraiment.
Tu peux aussi écrire les erreurs dans une log et demander à
l'utilisateur de joindre ce fichier plutôt qu'une copie de l'écran.
Là aussi, tu peux écrire une fonction réutilisable dans toute appli
(le chemin du fichier log peut être fonction de App.Path et d'une
constante pour le nom du fichier, par exemple).
Effectivement, et j'irais même jusqu'à automatiser l'envoi du mail.
Bien entendu, il arrive un moment où il faut se calmer, parce que si une
erreur se produit pendant la procédure d'erreur, on n'est pas vraiment
avancé. D'ailleurs arrivé là il ne faut pas se louper, car il faut
penser à autoriser au niveau du pare-feu. J'imagine qu'il vaut mieux
faire les choses en plusieurs fois, et se contenter de faire apparaître
un bouton sur le formulaire de menu, qui transmettra le mail. Comme ça
la première procédure d'erreur n'est pas perturbée par des problèmes de
réseau.
Tu as intérêt à implémenter ton gestionnaire d'erreur avec MZTools
(http://www.mztools.com/) pour que l'appel de cette fonction soit
systématique.
ça a l'air pas mal ce truc. Je ne l'ai pas encore installé car je suis
en panne de sauvegardes, mais ça ne devrait guère tarder.
C'est vrai qu'il y a la création d'un formulaire. Tu penses que c'est le mieux alors ?
Pas vraiment. Tu peux aussi écrire les erreurs dans une log et demander à l'utilisateur de joindre ce fichier plutôt qu'une copie de l'écran. Là aussi, tu peux écrire une fonction réutilisable dans toute appli (le chemin du fichier log peut être fonction de App.Path et d'une constante pour le nom du fichier, par exemple).
Effectivement, et j'irais même jusqu'à automatiser l'envoi du mail. Bien entendu, il arrive un moment où il faut se calmer, parce que si une erreur se produit pendant la procédure d'erreur, on n'est pas vraiment avancé. D'ailleurs arrivé là il ne faut pas se louper, car il faut penser à autoriser au niveau du pare-feu. J'imagine qu'il vaut mieux faire les choses en plusieurs fois, et se contenter de faire apparaître un bouton sur le formulaire de menu, qui transmettra le mail. Comme ça la première procédure d'erreur n'est pas perturbée par des problèmes de réseau.
Tu as intérêt à implémenter ton gestionnaire d'erreur avec MZTools (http://www.mztools.com/) pour que l'appel de cette fonction soit systématique.
ça a l'air pas mal ce truc. Je ne l'ai pas encore installé car je suis en panne de sauvegardes, mais ça ne devrait guère tarder.
