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 Visual Basic Problème avec CreateProcess (VB6) et Windows XP

Problème avec CreateProcess (VB6) et Windows XP

16 réponses
Avatar
Hafe
J'ai un programme VB6 qui date de Windows NT puis Windows 2000.

Dans ce programme, pour appeler un exe externe et attendre la fin de son
exécution, j'utilisais la fonction CreateProcess et tout ce qui va avec (code
trouvé sur le site de Microsoft) : l'appel se fait correctement sous Windows
Nt et Windows 2000 (Pro et Server).

Depuis que je suis sous Windows XP, cela ne fonctionne plus du tout ! J'ai
bien trouvé un article sur le support Microsoft mais qui concerne uniquement
Windows 2003.

Quelqu'un a une idée ? Les autres méthodes à disposition ne sont pas trop
satisfaisantes.
Merci d'avance.
Signaler un problème avec ce contenu

6 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
X
Cher ami,

Heu, oui, certes! Mais bon, en lisant un peu partout, les API ont
quand même des inconvénients:
-- Portabilité (un exe vb, je crois bien avec adaptation, peut tourner sous
Unix ? Voire sous Mac)...
-- Taille des dll, ocx, si elles sont à rajouter, c'est gros, et souvent on
oublie la partie distribution éventuelle...
-- Absence de documentation globale des API (reste une sorte de demi-secret
détenu par MicroSoft)...
-- Complexité des API, du fait qu'elles sont écrites en C généralement, et
aussi qu'elle sont écrites en anglais, ce qui en français les rend encore
moins claires....
-- En cas d'erreur, plantage souvent définitif du programme, routine
d'erreur difficile à bien gérer (d'ailleurs on voit rarement une routine de
gestion d'erreur dans les programmes, y compris les miens, avec les API je
veux dire)...
-- La littérature, la doctrine donc, s'accorde à dire que c'est à utiliser
en dernier recours, quand la cause autrement est désespérée, or de plus en
plus ici, on peut voir des réponses où directement on passe à l'API...
-- J'en connais même un (que je ne cite pas), qui prend vb6, comme il
prendrait un éditeur Java, ou C, ou ce que tu veux, peu importe, et fait
tout à l'API, enfin, le plus possible, ce qui dénature le code, ça devient
un mélange inextricable d'API et de (Basic par intermittence)...
---------------
Ces raisons sont je présume suffisantes pour ne pas bourrer les programmes
d'API, et tenter préalablement de trouver une solution VB...
---------------
J'utilise les API aussi, mais quand je ne sais pas faire autrement...
---------------
La programmation système, de mémoire c'est la programmation utilisé par le
noyau (Windows, son noyau proprement dit, et ses dll etc)... Donc par
l'intermédiaire des API... Mais bon, le terme système n'est pas toujours
agréé pour les API...
---------------
Je ne sais pas ce qu'est le bidouillage ici...
Est-ce de mettre une API sans aucune routine d'erreur... Juste les API, la
question se pose alors, pourquoi prendre l'éditeur VB ??? Pourquoi ne pas
prendre un autre éditeur, ça marcherait aussi bien !!!
Ou de mettre en VB un accès au fichier que produit l'exe appelé, avec une
routine d'erreur et un Timer qui sort si le temps est trop lent pour ce
qu'on veut faire...
Certes, le côté "on attend 3 secondes" avant de sortir, ne fait pas assez
mathématique, j'en conviens, cependant après test et pour les processeurs
actuels, en faisant ainsi ça ne me semble pas être une hérésie...
D'autant que j'ai évoqué "Shell", mais qu'ensuite j'ai évoqué les API,
indiquant donc deux possibilités au choix de l'utilisateur...
---------------
Bon, ceci étant dit, pour te détendre je te propose un excellent roman "Le
serpent":
http://www.manuscritdepot.com/a.joseph-attila-pusztay.1.htm

Cordialement :o)

--
Site ROMANS édités
http://www.manuscritdepot.com/a.joseph-attila-pusztay.1.htm
Site LOGICIELS
http://irolog.free.fr
Mail
http://irolog.free.fr/ecrire/index.htm
------------------------------------------------------------------------------------
"Guy DETIENNE" a écrit dans le message de news:
%23Toi$


En effet, X aime bidouiller..., et c'est normal puisqu'il ne comprend pas
l'utilité des API's dans VB. Alors il reste la bidouille pour essayer de
s'en passer. Et tout bon programmeur qui se respecte sait qu'une bidouille
ne fonctionne que dans un contexte bien précis. Outre ce contexte,
bonjour les jolis plantages.



Et je crois que X ne comprend pas non plus l'utilité d'une API à travers
VB.

VB n'est pas suffisant que pour pouvoir effectuer une multitude de tâches,
qui pourtant sont essentielles sous Windows.



Que faut-il faire alors dans ce cas ? Se passer de ces fonctionnalités
sous prétexte de ne pas "dénaturer" VB ? Peut-être que ton niveau de
programmation n'exige pas l'emploi d'API's.

Me concernant, je ne pourrais pas faire autrement sinon peut-être passer à
un autre langage.



Je crois réellement que tu es allergique aux API's, sans doute à cause de
ta méconnaissance de celles-ci. Pour preuve, tu qualifies leur
utilisation de programmation « système » et même d'irrationnelle.



Qu'est-ce la programmation système pour toi ?



Et pour ta gouverne, VB n'est absolument pas portable ! Donc je ne
comprends pas ton argumentation concernant la portabilité.



Et puis le Shell avec un timer histoire d'attendre la fin de l'exécution
d'un programme, cela relève du grand art ! Dans ce cas, tu es perdu sans
API !



Connaissant le personnage (ancien pseudo : LE TROLL), inutile d'engager un
quelconque débat ici, cela risque de tourner au pugilat ;O) Mais se
serait-il assagi depuis ?



Allez bonne prog' et bonne bidouille en ce qui te concerne. Mais il est
dommage que certaines personnes posant des questions tombent parfois sur
des réponses comme les tiennes.

Je ne prétends pas tout savoir, mais à défaut de connaître la réponse, je
m'abstiens de dire des énormités.



Guy



"X" a écrit dans le message de news:
%

L'API dans un langage VB, c'est comme de l'assembleur en ligne (assembler
in line) dans du C, ce n'est pas une solution "propre", c'est de l'ultime
quand on ne peut rien faire d'autre de rationnel :o)
On voit de plus en plus des API ici, alors qu'on peut faire du VB, dans
ce cas, si on veut faire du langage système, il faut le faire en
assembleur, qui désormais, à part son code propre, utilise les API... Ce
n'est pas un forum de programmation système...

--
Site ROMANS édités
http://www.manuscritdepot.com/a.joseph-attila-pusztay.1.htm
Site LOGICIELS
http://irolog.free.fr
Mail
http://irolog.free.fr/ecrire/index.htm
------------------------------------------------------------------------------------
a écrit dans le message de news:

efectivement, chacun son tuc : solution propre ou bidouille...

"X" a écrit dans le message de
news:
Ben, 2, 3 secondes généralement c'est terminé, faut étalonner avec le


temps
que mets le second exe, plus une marge; ou encore en lisant le fichier
produit par l'exe 2 , tant que pas lu, et si pas plus de x seconde,
tente
une nouvelle lecture..
Mais bon, chacun son truc...

--
Site ROMANS édités
http://www.manuscritdepot.com/a.joseph-attila-pusztay.1.htm
Site LOGICIELS
http://irolog.free.fr
Mail
http://irolog.free.fr/ecrire/index.htm
--------------------------------------------------------------------------


----------
a écrit dans le message de news:

> Et tu vas faire comment pour savoir quand ton programme aura fini
> d'etre
> exécuté ?
> Dans son cas, Shell n'est pas adapté, c'est pour cela qu'il préfère
> utiliser
> un truc plus sur : CreateProcess().
>
>
> "X" a écrit dans le message de
> news:
>> On peut éventuellement temporiser derrière alors...
>>
>> --
>> Site ROMANS édités
>> http://www.manuscritdepot.com/a.joseph-attila-pusztay.1.htm
>> Site LOGICIELS
>> http://irolog.free.fr
>> Mail
>> http://irolog.free.fr/ecrire/index.htm

-------------------------------------------------------------------------




-
> ----------
>> a écrit dans le message de news:
>>
>> > La fonction Shell ne permet pas d'attendre la fin de l'exécution
>> > du
>> > programme, c'est pour cela qu'il utilise la fonction
>> > CreateProcess()
>> >
>> >
>> >
>> > "X" a écrit dans le message de
>> > news:
>> >> Bonjour,
>> >>
>> >> Pour appeler seulement, ça devrait suffire:
>> >>
>> >> Shell "explorer.exe http://www.ifrance.com/Irolog"
>> >>
>> >> Pour ouvrir et fermer, mais ce n'est pas en VB:
>> >>
>> >> Private Declare Function OpenProcess Lib "kernel32" ( _
>> >> ByVal dwDesiredAccess As Long, _
>> >> ByVal bInheritHandle As Long, _
>> >> ByVal dwProcessId As Long _
>> >> ) As Long
>> >> '
>> >> Private Declare Function TerminateProcess Lib "kernel32" ( _
>> >> ByVal hProcess As Long, _
>> >> ByVal uExitCode As Long _
>> >> ) As Long
>> >> Private Declare Function CloseHandle Lib "kernel32" ( _
>> >> ByVal hObject As Long) As Long
>> >> '
>> >> Private Const PROCESS_TERMINATE = &H1
>> >> Dim NumProcess As Long
>> >> Dim RC As Long
>> >> Dim hProcess As Long
>> >> '
>> >> Sub ouvrir()
>> >> NumProcess = Shell(Nom_fic, 1)
>> >> End sub
>> >> Sub fermer()
>> >> hProcess = OpenProcess(PROCESS_TERMINATE, -1&, NumProcess)
>> >> RC = TerminateProcess(hProcess, 0&)
>> >> RC = CloseHandle(hProcess)
>> >> End Sub
>> >>
>> >>
>> >> Sinon, j ne comprends pas pourqoi tout ça??? Un exe 1 peut
>> >> appeler
> l'exe
>> >> 2
>> >> par Shelle, ensuite l'exe 2 fait son travail, le balance dans un
> fichier
>> > et
>> >> se ferme tout seul, puis l'exe 1 reprend les donnée dans le


fichier...
>> >> Enfin, pour les cas généraux...
>> >>
>> >> --
>> >> Site ROMANS édités
>> >> http://www.manuscritdepot.com/a.joseph-attila-pusztay.1.htm
>> >> Site LOGICIELS
>> >> http://irolog.free.fr
>> >> Mail
>> >> http://irolog.free.fr/ecrire/index.htm
>>

------------------------------------------------------------------------






-
> -
>> > ----------
>> >> "Hafe" a écrit dans le message
>> >> de
> news:
>> >>
>> >> > J'ai un programme VB6 qui date de Windows NT puis Windows 2000.
>> >> >
>> >> > Dans ce programme, pour appeler un exe externe et attendre la
>> >> > fin


de
>> >> > son
>> >> > exécution, j'utilisais la fonction CreateProcess et tout ce qui
>> >> > va
> avec
>> >> > (code
>> >> > trouvé sur le site de Microsoft) : l'appel se fait correctement


sous
>> >> > Windows
>> >> > Nt et Windows 2000 (Pro et Server).
>> >> >
>> >> > Depuis que je suis sous Windows XP, cela ne fonctionne plus du


tout
>> >> > !
>> > J'ai
>> >> > bien trouvé un article sur le support Microsoft mais qui
>> >> > concerne
>> >> > uniquement
>> >> > Windows 2003.
>> >> >
>> >> > Quelqu'un a une idée ? Les autres méthodes à disposition ne
>> >> > sont


pas
>> > trop
>> >> > satisfaisantes.
>> >> > Merci d'avance.
>> >> >
>> >> >
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>
















Avatar
Picalausa François
Hello,

Heu, oui, certes! Mais bon, en lisant un peu partout, les API ont
quand même des inconvénients:
-- Portabilité (un exe vb, je crois bien avec adaptation, peut tourner
sous Unix ? Voire sous Mac)...



Pas l'exe, mais bien le code source qui après une conversion vers un autre
langage peut fonctionner.
L'exe pourra être éxécuté via un émulateur (qui émule précisément les
fonctions offertes par le système)!

Dans l'optique de portabilité, j'emploierais plutôt:
-Java
-C#
-C++ avec les libs appropriées (par exemple, Qt pour l'interface
graphique... ou encore wxWidgets)
Mais certainement pas VB6 qui colle à COM et aux API windows autant que
possible tout en le masquant aux utilisateurs!

-- Taille des dll, ocx, si elles sont à rajouter, c'est gros, et souvent
on oublie la partie distribution éventuelle...



D'où l'intéret des API windows... par de dll à redistribuer pour faire une
tâche qu'avec un ocx externe il faudrait fournir

-- Absence de documentation globale des API (reste une sorte de
demi-secret détenu par MicroSoft)...



http://msdn.microsoft.com/library
et/ou le Platform SDK (qui ne possède pas son nom pour rien)
Il y a eu un effort de traduction (principalement pour la plateforme .Net,
si je me souviens bien), mais le fait est que dans le monde de
l'informatique la pratique de l'anglais est loin d'être un luxe!
Tout n'est pas

-- Complexité des API, du fait qu'elles sont écrites en C généralement, et
aussi qu'elle sont écrites en anglais, ce qui en français les rend encore
moins claires....



La qualité d'une solution n'est souvent pas proportionelle à sa simplicité!
La complexitié est un reproche souvent fait aux APIs Windows mais,
faute de connaitre beaucoup d'autres modèles d'API système (unix, mac, ...)
je dirais juste qu'il existe beaucoup d'exemple qui permettent d'en aborder
le fonctionnement de manière très simple.
Ce que je constate par contre, c'est que nombre de développeurs voudraient
pouvoir appeler une fonction plutôt que d'écrire un logiciel. Réinventer la
roue n'est certes pas la chose la plus utile pour la communauté, mais
comprendre ce que l'on fait (ou ce que VB fait derrière notre dos) est
souvent utile d'un point de vue personnel!

-- En cas d'erreur, plantage souvent définitif du programme, routine
d'erreur difficile à bien gérer (d'ailleurs on voit rarement une routine
de gestion d'erreur dans les programmes, y compris les miens, avec les API
je veux dire)...



En cas d'erreur avec un composant COM, plantage souvent définitif de
l'application, d'où l'importance d'avoir des méthodes de gestion d'erreurs
standardisées et bien définies.
Pour les APIs, il suffit de wrapper et de Err.Raise. Il n'y a pas plus de
problème.
Les plantages de l'IDE peuvent survenir dans les cas de sous-classement sans
intermédiaire... mais ce n'est pas parce que ce cas est problématique qu'il
faut forcément dire API = mauvais

Cela étant, les gestions d'erreurs dans les exemples sur ce groupe sont
omises car le but n'est pas de montrer comment fonctionne une gestion
d'erreur... inutile d'encombrer un _exemple_. (Evidement, si tu veux fournir
un programme complet, ce n'est alors plus un point à omettre)

-- La littérature, la doctrine donc, s'accorde à dire que c'est à utiliser
en dernier recours, quand la cause autrement est désespérée, or de plus en
plus ici, on peut voir des réponses où directement on passe à l'API...



Faux! (ou du moins, je ne lis pas de telle littérature)
On passe par les API lorsqu'il est impossible de résoudre proprement (sans
méthode douteuse/bricolages) un problème a cause des (trop nombreuses)
limitations de VB, ce qui arrive (très) souvent.
On passe aussi par les APIs lorsque l'on désire limiter le nombre de
composants COM eux-même wrappers d'APIs (par exemple le set WMI, ou encore
le contrôle sysinfo).
Finalement, VB a la fâcheuse tendance d'être très lent sur certaines
opérations car il offre celles-ci avec une interface assez générale, ce qui
force la runtime a des tests inutiles (voire dérangeants) dans le programme
réalisé.

Les APIs sont effectivement parfois utilisées par méconnaissance de
certaines méthodes/propriétés de VB et c'est à ce moment qu'il peut être
utile d'indiquer à l'auteur de la réponse qu'il existe plus simple et non
bricolé...

-- J'en connais même un (que je ne cite pas), qui prend vb6, comme il
prendrait un éditeur Java, ou C, ou ce que tu veux, peu importe, et fait
tout à l'API, enfin, le plus possible, ce qui dénature le code, ça devient
un mélange inextricable d'API et de (Basic par intermittence)...



Rien que pour comprendre l'API Windows c'est une très bonne démarche (et
comprendre c'est ce qu'on tente de faire sur ce forum!).
Pour une application de prod, ce n'est évidement pas l'idéal.

---------------
Ces raisons sont je présume suffisantes pour ne pas bourrer les programmes
d'API, et tenter préalablement de trouver une solution VB...



Si ce n'est pas une solution bricolée, oui!

---------------
Je ne sais pas ce qu'est le bidouillage ici...



Attendre un temps définit pour l'exécution d'un programme qui se passe sur
un temps indéfini!
C'est typiquement le genre de choses qui n'est pas portable parce que si le
programme met soudainement plus longtemps à se lancer ou à s'exécuter pour
raison x ou y (par exemple le changement de plateforme) ton programme
plantera lamentablement.

Est-ce de mettre une API sans aucune routine d'erreur...


La plupart du code fournit sur ce forum est sans gestion d'erreur simplement
parce que le but n'est pas de fournir une réponse complète mais l'élément de
réponse qui pourra éventuellement permettre de continuer. La gestion
d'erreur est une chose qui est standardisée et intégrée par la suite par les
développeurs. Il en va de même pour le test des code de retours des APIs.

Juste les API, la question se pose alors, pourquoi prendre l'éditeur VB
??? Pourquoi ne pas prendre un autre éditeur, ça marcherait aussi bien !!!



Simplement pour ne pas se farcir ce que VB peut faire proprement! De même on
a tendance à wrapper en C ce qui est nécessaire, lorsque C est plus
approprié.

Ou de mettre en VB un accès au fichier que produit l'exe appelé, avec une
routine d'erreur et un Timer qui sort si le temps est trop lent pour ce
qu'on veut faire...



Ca c'est déjà plus propre... si l'exe appelé écrit (ou peut être modifié de
sorte à écrire) un fichier.

Certes, le côté "on attend 3 secondes" avant de sortir, ne fait pas assez
mathématique, j'en conviens, cependant après test et pour les processeurs
actuels, en faisant ainsi ça ne me semble pas être une hérésie...



Si le programme doit être distribué, quelqu'un aura toujours LA
configuration qui fait que ça ne marche pas. Autant éviter les risques
inutiles et faire en sorte que ça marche partout!

D'autant que j'ai évoqué "Shell", mais qu'ensuite j'ai évoqué les API,
indiquant donc deux possibilités au choix de l'utilisateur...



J'éviterai de discuter de la pertinence de la réponse, ce sujet précis ne me
concernant pas.

---------------
Bon, ceci étant dit, pour te détendre je te propose un excellent roman "Le
serpent":
http://www.manuscritdepot.com/a.joseph-attila-pusztay.1.htm



Ce genre de publicité qui a encore moins de rapport avec VB que la
"programmation système" est elle par contre TRES mal venue ici!

Je n'ai pas le temps de relire donc mes excuses pour les imprécisions que
j'ai pu commettre!
--
Picalausa François
Avatar
T'as trouvé une solution sous Xp ?


"Hafe" a écrit dans le message de
news:
J'ai un programme VB6 qui date de Windows NT puis Windows 2000.

Dans ce programme, pour appeler un exe externe et attendre la fin de son
exécution, j'utilisais la fonction CreateProcess et tout ce qui va avec


(code
trouvé sur le site de Microsoft) : l'appel se fait correctement sous


Windows
Nt et Windows 2000 (Pro et Server).

Depuis que je suis sous Windows XP, cela ne fonctionne plus du tout ! J'ai
bien trouvé un article sur le support Microsoft mais qui concerne


uniquement
Windows 2003.

Quelqu'un a une idée ? Les autres méthodes à disposition ne sont pas trop
satisfaisantes.
Merci d'avance.





Avatar
Jean-marc
Hello,

simple question:

pourquoi pas shell + WaitForSingleObject?

C'est comme ca que je fais depuis des années, sous Windows 2000,2003 et XP.

C'est propre, ça tient en 3 lignes de code, c'est "portable"
win2000,2003,XP.

http://vb-helper.com/howto_shell_wait.html

Un problème avec cette solution?

--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;


a écrit dans le message de news:
eBXb%
T'as trouvé une solution sous Xp ?


"Hafe" a écrit dans le message de
news:
J'ai un programme VB6 qui date de Windows NT puis Windows 2000.

Dans ce programme, pour appeler un exe externe et attendre la fin de son
exécution, j'utilisais la fonction CreateProcess et tout ce qui va avec


(code
trouvé sur le site de Microsoft) : l'appel se fait correctement sous


Windows
Nt et Windows 2000 (Pro et Server).

Depuis que je suis sous Windows XP, cela ne fonctionne plus du tout !
J'ai
bien trouvé un article sur le support Microsoft mais qui concerne


uniquement
Windows 2003.

Quelqu'un a une idée ? Les autres méthodes à disposition ne sont pas trop
satisfaisantes.
Merci d'avance.









Avatar
X
Bonjour,

De ceux qui ont répondus, dont toi, je les juge supérieur à moi en
programmation, ainsi j'écoute la pertinence de leur observations, et je les
en remercie...

Nonobstant, la discussion est partie d'un exe appelant qui demanderait à
un exe appelé, de faire un fichier, puis de se fermer, l'exe appelant lisait
ensuite le fichier, condition sine qua non...
J'indiquais donc à ce sujet, qu'on pouvait passer par l'API ShellExecut ou
par VB avec Shell...
Suite à ceci, on me dit non, "bidouillage", il faut passer par l'API car on
a un retour x = API...

Ben oui, on a un retour, mais moi je proposait une temporisation, à mon
sens les deux solutions sont de même nature dans l'absolu, car avec l'API on
a certes un retour, mais si rien n'est ouvert, il faut bien y retourner, car
on a besoin du fichier, alors pour y retourner, soit on va faire un tant
que... soit une boucle 1 to x, soit un Timer, soit un goto... Jusqu'à, soit
décider de sortir en erreur définitive, soit d'avoir le fichier...

Le problème ici est élémentaire, on fait un appel, on attend ainsi une
réaction spécifique, si on n'a pas cette réaction et qu'on en a besoin, ben
il faut refaire l'action (boucle, tan que, Timer)... Quelle que soit la
façon de programmer, il faudra bien décider d'un nombre, d'onc d'un temps
relatif avant de considérer qu'il y a erreur, je ne vois en ceci aucun
bidouillage... D'ailleurs, pour me conforter, je pense à Windows, qui au
bout d'un certain temps, selon la priorité de la tâche, va considérer que
"le programme ne répond plus", et d'ailleurs parfois il se trompe (cas d'une
très longue compilation par exemple)... Donc au niveau de l'OS lui même, et
ça me réconforte, il bidouille comme moi, en considérant qu'au delà d'un
temps jugé probable pour accomplir une action, on sort en erreur
arbitraire...

Il en découle que je ne comprends pas cette façon de programmer en
parlant de bidouille, d'autant qu'après nous aurons l'ouverture du fichier à
gérer, et que là de toute façon, s'il n'existe pas, il faudra bien y
retourner ou fermer le programme, ainsi l'erreur de l'API n'a aucune utilité
puisque de toute façon elle sera traité plus loin avec le fichier produit
par l'exe appelé, en plus je ne suis même pas certain qu'une erreur sur un
ShelleExecut plante l'application (à vérifier), il en découle que le Shell
est bien suffisant, ce qui signifie une programmation VB exclusivement
ici...

Désolé d'écrire beaucoup, j'aime bien, c'est mon côté romancier :o)

Cordialement.

--
Site ROMANS édités
http://www.manuscritdepot.com/a.joseph-attila-pusztay.1.htm
Site LOGICIELS
http://irolog.free.fr
Mail
http://irolog.free.fr/ecrire/index.htm
------------------------------------------------------------------------------------
"Picalausa François" a écrit dans le message de news:

Hello,

Heu, oui, certes! Mais bon, en lisant un peu partout, les API ont
quand même des inconvénients:
-- Portabilité (un exe vb, je crois bien avec adaptation, peut tourner
sous Unix ? Voire sous Mac)...



Pas l'exe, mais bien le code source qui après une conversion vers un autre
langage peut fonctionner.
L'exe pourra être éxécuté via un émulateur (qui émule précisément les
fonctions offertes par le système)!

Dans l'optique de portabilité, j'emploierais plutôt:
-Java
-C#
-C++ avec les libs appropriées (par exemple, Qt pour l'interface
graphique... ou encore wxWidgets)
Mais certainement pas VB6 qui colle à COM et aux API windows autant que
possible tout en le masquant aux utilisateurs!

-- Taille des dll, ocx, si elles sont à rajouter, c'est gros, et souvent
on oublie la partie distribution éventuelle...



D'où l'intéret des API windows... par de dll à redistribuer pour faire une
tâche qu'avec un ocx externe il faudrait fournir

-- Absence de documentation globale des API (reste une sorte de
demi-secret détenu par MicroSoft)...



http://msdn.microsoft.com/library
et/ou le Platform SDK (qui ne possède pas son nom pour rien)
Il y a eu un effort de traduction (principalement pour la plateforme .Net,
si je me souviens bien), mais le fait est que dans le monde de
l'informatique la pratique de l'anglais est loin d'être un luxe!
Tout n'est pas

-- Complexité des API, du fait qu'elles sont écrites en C généralement,
et aussi qu'elle sont écrites en anglais, ce qui en français les rend
encore moins claires....



La qualité d'une solution n'est souvent pas proportionelle à sa
simplicité!
La complexitié est un reproche souvent fait aux APIs Windows mais,
faute de connaitre beaucoup d'autres modèles d'API système (unix, mac,
...) je dirais juste qu'il existe beaucoup d'exemple qui permettent d'en
aborder le fonctionnement de manière très simple.
Ce que je constate par contre, c'est que nombre de développeurs voudraient
pouvoir appeler une fonction plutôt que d'écrire un logiciel. Réinventer
la roue n'est certes pas la chose la plus utile pour la communauté, mais
comprendre ce que l'on fait (ou ce que VB fait derrière notre dos) est
souvent utile d'un point de vue personnel!

-- En cas d'erreur, plantage souvent définitif du programme, routine
d'erreur difficile à bien gérer (d'ailleurs on voit rarement une routine
de gestion d'erreur dans les programmes, y compris les miens, avec les
API je veux dire)...



En cas d'erreur avec un composant COM, plantage souvent définitif de
l'application, d'où l'importance d'avoir des méthodes de gestion d'erreurs
standardisées et bien définies.
Pour les APIs, il suffit de wrapper et de Err.Raise. Il n'y a pas plus de
problème.
Les plantages de l'IDE peuvent survenir dans les cas de sous-classement
sans intermédiaire... mais ce n'est pas parce que ce cas est problématique
qu'il faut forcément dire API = mauvais

Cela étant, les gestions d'erreurs dans les exemples sur ce groupe sont
omises car le but n'est pas de montrer comment fonctionne une gestion
d'erreur... inutile d'encombrer un _exemple_. (Evidement, si tu veux
fournir un programme complet, ce n'est alors plus un point à omettre)

-- La littérature, la doctrine donc, s'accorde à dire que c'est à
utiliser en dernier recours, quand la cause autrement est désespérée, or
de plus en plus ici, on peut voir des réponses où directement on passe à
l'API...



Faux! (ou du moins, je ne lis pas de telle littérature)
On passe par les API lorsqu'il est impossible de résoudre proprement (sans
méthode douteuse/bricolages) un problème a cause des (trop nombreuses)
limitations de VB, ce qui arrive (très) souvent.
On passe aussi par les APIs lorsque l'on désire limiter le nombre de
composants COM eux-même wrappers d'APIs (par exemple le set WMI, ou encore
le contrôle sysinfo).
Finalement, VB a la fâcheuse tendance d'être très lent sur certaines
opérations car il offre celles-ci avec une interface assez générale, ce
qui force la runtime a des tests inutiles (voire dérangeants) dans le
programme réalisé.

Les APIs sont effectivement parfois utilisées par méconnaissance de
certaines méthodes/propriétés de VB et c'est à ce moment qu'il peut être
utile d'indiquer à l'auteur de la réponse qu'il existe plus simple et non
bricolé...

-- J'en connais même un (que je ne cite pas), qui prend vb6, comme il
prendrait un éditeur Java, ou C, ou ce que tu veux, peu importe, et fait
tout à l'API, enfin, le plus possible, ce qui dénature le code, ça
devient un mélange inextricable d'API et de (Basic par intermittence)...



Rien que pour comprendre l'API Windows c'est une très bonne démarche (et
comprendre c'est ce qu'on tente de faire sur ce forum!).
Pour une application de prod, ce n'est évidement pas l'idéal.

---------------
Ces raisons sont je présume suffisantes pour ne pas bourrer les
programmes d'API, et tenter préalablement de trouver une solution VB...



Si ce n'est pas une solution bricolée, oui!

---------------
Je ne sais pas ce qu'est le bidouillage ici...



Attendre un temps définit pour l'exécution d'un programme qui se passe sur
un temps indéfini!
C'est typiquement le genre de choses qui n'est pas portable parce que si
le programme met soudainement plus longtemps à se lancer ou à s'exécuter
pour raison x ou y (par exemple le changement de plateforme) ton programme
plantera lamentablement.

Est-ce de mettre une API sans aucune routine d'erreur...


La plupart du code fournit sur ce forum est sans gestion d'erreur
simplement parce que le but n'est pas de fournir une réponse complète mais
l'élément de réponse qui pourra éventuellement permettre de continuer. La
gestion d'erreur est une chose qui est standardisée et intégrée par la
suite par les développeurs. Il en va de même pour le test des code de
retours des APIs.

Juste les API, la question se pose alors, pourquoi prendre l'éditeur VB
??? Pourquoi ne pas prendre un autre éditeur, ça marcherait aussi bien
!!!



Simplement pour ne pas se farcir ce que VB peut faire proprement! De même
on a tendance à wrapper en C ce qui est nécessaire, lorsque C est plus
approprié.

Ou de mettre en VB un accès au fichier que produit l'exe appelé, avec une
routine d'erreur et un Timer qui sort si le temps est trop lent pour ce
qu'on veut faire...



Ca c'est déjà plus propre... si l'exe appelé écrit (ou peut être modifié
de sorte à écrire) un fichier.

Certes, le côté "on attend 3 secondes" avant de sortir, ne fait pas assez
mathématique, j'en conviens, cependant après test et pour les processeurs
actuels, en faisant ainsi ça ne me semble pas être une hérésie...



Si le programme doit être distribué, quelqu'un aura toujours LA
configuration qui fait que ça ne marche pas. Autant éviter les risques
inutiles et faire en sorte que ça marche partout!

D'autant que j'ai évoqué "Shell", mais qu'ensuite j'ai évoqué les API,
indiquant donc deux possibilités au choix de l'utilisateur...



J'éviterai de discuter de la pertinence de la réponse, ce sujet précis ne
me concernant pas.

---------------
Bon, ceci étant dit, pour te détendre je te propose un excellent roman
"Le serpent":
http://www.manuscritdepot.com/a.joseph-attila-pusztay.1.htm



Ce genre de publicité qui a encore moins de rapport avec VB que la
"programmation système" est elle par contre TRES mal venue ici!

Je n'ai pas le temps de relire donc mes excuses pour les imprécisions que
j'ai pu commettre!
--
Picalausa François




Avatar
Guy DETIENNE
Merci François pour cette réponse des plus précises !
Il et bon de remettre de temps en temps l'église au milieu du village ;O)

Mais quand certains parlent de doctrine en programmation...

Guy

"Picalausa François" a écrit dans le message de news:

Hello,

Heu, oui, certes! Mais bon, en lisant un peu partout, les API ont
quand même des inconvénients:
-- Portabilité (un exe vb, je crois bien avec adaptation, peut tourner
sous Unix ? Voire sous Mac)...



Pas l'exe, mais bien le code source qui après une conversion vers un autre
langage peut fonctionner.
L'exe pourra être éxécuté via un émulateur (qui émule précisément les
fonctions offertes par le système)!

Dans l'optique de portabilité, j'emploierais plutôt:
-Java
-C#
-C++ avec les libs appropriées (par exemple, Qt pour l'interface
graphique... ou encore wxWidgets)
Mais certainement pas VB6 qui colle à COM et aux API windows autant que
possible tout en le masquant aux utilisateurs!

-- Taille des dll, ocx, si elles sont à rajouter, c'est gros, et souvent
on oublie la partie distribution éventuelle...



D'où l'intéret des API windows... par de dll à redistribuer pour faire une
tâche qu'avec un ocx externe il faudrait fournir

-- Absence de documentation globale des API (reste une sorte de
demi-secret détenu par MicroSoft)...



http://msdn.microsoft.com/library
et/ou le Platform SDK (qui ne possède pas son nom pour rien)
Il y a eu un effort de traduction (principalement pour la plateforme .Net,
si je me souviens bien), mais le fait est que dans le monde de
l'informatique la pratique de l'anglais est loin d'être un luxe!
Tout n'est pas

-- Complexité des API, du fait qu'elles sont écrites en C généralement,
et aussi qu'elle sont écrites en anglais, ce qui en français les rend
encore moins claires....



La qualité d'une solution n'est souvent pas proportionelle à sa
simplicité!
La complexitié est un reproche souvent fait aux APIs Windows mais,
faute de connaitre beaucoup d'autres modèles d'API système (unix, mac,
...) je dirais juste qu'il existe beaucoup d'exemple qui permettent d'en
aborder le fonctionnement de manière très simple.
Ce que je constate par contre, c'est que nombre de développeurs voudraient
pouvoir appeler une fonction plutôt que d'écrire un logiciel. Réinventer
la roue n'est certes pas la chose la plus utile pour la communauté, mais
comprendre ce que l'on fait (ou ce que VB fait derrière notre dos) est
souvent utile d'un point de vue personnel!

-- En cas d'erreur, plantage souvent définitif du programme, routine
d'erreur difficile à bien gérer (d'ailleurs on voit rarement une routine
de gestion d'erreur dans les programmes, y compris les miens, avec les
API je veux dire)...



En cas d'erreur avec un composant COM, plantage souvent définitif de
l'application, d'où l'importance d'avoir des méthodes de gestion d'erreurs
standardisées et bien définies.
Pour les APIs, il suffit de wrapper et de Err.Raise. Il n'y a pas plus de
problème.
Les plantages de l'IDE peuvent survenir dans les cas de sous-classement
sans intermédiaire... mais ce n'est pas parce que ce cas est problématique
qu'il faut forcément dire API = mauvais

Cela étant, les gestions d'erreurs dans les exemples sur ce groupe sont
omises car le but n'est pas de montrer comment fonctionne une gestion
d'erreur... inutile d'encombrer un _exemple_. (Evidement, si tu veux
fournir un programme complet, ce n'est alors plus un point à omettre)

-- La littérature, la doctrine donc, s'accorde à dire que c'est à
utiliser en dernier recours, quand la cause autrement est désespérée, or
de plus en plus ici, on peut voir des réponses où directement on passe à
l'API...



Faux! (ou du moins, je ne lis pas de telle littérature)
On passe par les API lorsqu'il est impossible de résoudre proprement (sans
méthode douteuse/bricolages) un problème a cause des (trop nombreuses)
limitations de VB, ce qui arrive (très) souvent.
On passe aussi par les APIs lorsque l'on désire limiter le nombre de
composants COM eux-même wrappers d'APIs (par exemple le set WMI, ou encore
le contrôle sysinfo).
Finalement, VB a la fâcheuse tendance d'être très lent sur certaines
opérations car il offre celles-ci avec une interface assez générale, ce
qui force la runtime a des tests inutiles (voire dérangeants) dans le
programme réalisé.

Les APIs sont effectivement parfois utilisées par méconnaissance de
certaines méthodes/propriétés de VB et c'est à ce moment qu'il peut être
utile d'indiquer à l'auteur de la réponse qu'il existe plus simple et non
bricolé...

-- J'en connais même un (que je ne cite pas), qui prend vb6, comme il
prendrait un éditeur Java, ou C, ou ce que tu veux, peu importe, et fait
tout à l'API, enfin, le plus possible, ce qui dénature le code, ça
devient un mélange inextricable d'API et de (Basic par intermittence)...



Rien que pour comprendre l'API Windows c'est une très bonne démarche (et
comprendre c'est ce qu'on tente de faire sur ce forum!).
Pour une application de prod, ce n'est évidement pas l'idéal.

---------------
Ces raisons sont je présume suffisantes pour ne pas bourrer les
programmes d'API, et tenter préalablement de trouver une solution VB...



Si ce n'est pas une solution bricolée, oui!

---------------
Je ne sais pas ce qu'est le bidouillage ici...



Attendre un temps définit pour l'exécution d'un programme qui se passe sur
un temps indéfini!
C'est typiquement le genre de choses qui n'est pas portable parce que si
le programme met soudainement plus longtemps à se lancer ou à s'exécuter
pour raison x ou y (par exemple le changement de plateforme) ton programme
plantera lamentablement.

Est-ce de mettre une API sans aucune routine d'erreur...


La plupart du code fournit sur ce forum est sans gestion d'erreur
simplement parce que le but n'est pas de fournir une réponse complète mais
l'élément de réponse qui pourra éventuellement permettre de continuer. La
gestion d'erreur est une chose qui est standardisée et intégrée par la
suite par les développeurs. Il en va de même pour le test des code de
retours des APIs.

Juste les API, la question se pose alors, pourquoi prendre l'éditeur VB
??? Pourquoi ne pas prendre un autre éditeur, ça marcherait aussi bien
!!!



Simplement pour ne pas se farcir ce que VB peut faire proprement! De même
on a tendance à wrapper en C ce qui est nécessaire, lorsque C est plus
approprié.

Ou de mettre en VB un accès au fichier que produit l'exe appelé, avec une
routine d'erreur et un Timer qui sort si le temps est trop lent pour ce
qu'on veut faire...



Ca c'est déjà plus propre... si l'exe appelé écrit (ou peut être modifié
de sorte à écrire) un fichier.

Certes, le côté "on attend 3 secondes" avant de sortir, ne fait pas assez
mathématique, j'en conviens, cependant après test et pour les processeurs
actuels, en faisant ainsi ça ne me semble pas être une hérésie...



Si le programme doit être distribué, quelqu'un aura toujours LA
configuration qui fait que ça ne marche pas. Autant éviter les risques
inutiles et faire en sorte que ça marche partout!

D'autant que j'ai évoqué "Shell", mais qu'ensuite j'ai évoqué les API,
indiquant donc deux possibilités au choix de l'utilisateur...



J'éviterai de discuter de la pertinence de la réponse, ce sujet précis ne
me concernant pas.

---------------
Bon, ceci étant dit, pour te détendre je te propose un excellent roman
"Le serpent":
http://www.manuscritdepot.com/a.joseph-attila-pusztay.1.htm



Ce genre de publicité qui a encore moins de rapport avec VB que la
"programmation système" est elle par contre TRES mal venue ici!

Je n'ai pas le temps de relire donc mes excuses pour les imprécisions que
j'ai pu commettre!
--
Picalausa François




1 2