Discussion :

[ValyGator]

Bonjour,

J'ai un programme ecrit en C++ pour Windows qui affiche une barre de pub. La barre elle-meme affiche une banniere GIF, et quand l'utilisateur clique sur la banniere, le programme ouvre le navigateur par defaut qui se connecte a l'adresse attachee a la banniere.

Ma ligne de code pour ouvrir le navigateur par defaut est simplement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
ShellExecute(NULL,"open",AdresseSite,NULL,NULL,SW_SHOWNORMAL);

Alors, ca marche tres bien. Et de plus plus la barre de pub a le bon gout de fonctionner a 99% sous Linux par l'intermediaire du logiciel Wine. Le pourcent manquant vient justement de cette commande ShellExecute qui semble ne pas fonctionner. Ma question est donc la suivante: Existe-t-il une autre commande qui permette d'ouvrir le navigateur par defaut et qui soit independante du systeme?

[LittleWhite]

Bonjour,

Faut juste installer internet explorer sous wine. Car le programme, ne pourra jamais sortir du contexte de wine.

Sinon, pour les trucs plus multiplateforme, je dirai, utilisez Qt.

[ValyGator]

Faut juste installer internet explorer sous wine. Car le programme, ne pourra jamais sortir du contexte de wine.

Ok, alors ceci m'amene a une autre question. Comment puis-je dans mon programme detecter si Internet Explorer est installe? Car dans le cas contraire mon programme doit se fermer en demandant a l'utilisateur d'installer IE sous wine.

[LittleWhite]

Hul, là c'est de la programmation windows.
Devrait y avoir une commande je pense ( recherche msdn ). Sinon, voir dans la base de registre ( ce qui serai pas étonnant sous windows ). Sinon, je peux rien dire de plus :s

[white_tentacle]

Je pense que tu peux tester le retour de ShellExecute/ShellExecuteEx. Voir la doc pour plus d'infos, mais normalement, GetLastError doit te donner une explication en cas d'échec.

[koala01]

Salut,

En toute honnêteté, le passage par wine ne me semble pas *vraiment* être la meilleure solution à envisager si tu souhaite faire du multi plateformes...

Ne serait-ce que parce qu'il y a encore énormément de chances qu'un utilisateur de linux ne dispose absolument pas de wine, et, dans ce cas, tu peux dire adieu à tout ce qui touche de près ou de loin aux possibilités propres à windows (shellExecute en premier, vu que tu en parle, mais, aussi tout le coté graphique, à moins que tu n'utilise Qt ou wxWidget, j'en passe, et de meilleures)

Bref, j'aurais tendance à dire que, avant de t'inquiéter à la minorité qui pourrait souhaiter faire tourner ton application sous wine, il est sans doute des plus intéressant de faire en sorte qu'elle tourne correctement sous windows, quitte, une fois que ce sera stable de ce point de vue, à essayer de le porter réellement sous linux, mais, comme je l'ai dit, cela risque de passer par la refonte au minimum de toute la partie graphique

[camboui]

Je me souviens, il y a bien longtemps, j'avais développé une petite application pour Windows.
Mais le client: "c'est bien mais il faut que ça tourne aussi sous Mac".

Bon, qu'à cela ne tienne, c'était fait sous Visual C++ 4.0. Et à l'époque il y avait une extension, un cross-compiler pour Mac. Non seulement on pouvait compiler des binaires natifs pour Mac-PowerPC depuis un PC (avec remote debugging fonctionnel), mais en plus on le faisait comme si on était sous Windows. L'API Windows était traduite au runtime en appel ad-hoc pour Mac. Une seule source pour deux plateformes.

Ça n'existe plus ce genre d'outil ?

[koala01]

Si on respecte le standard, il existe toujours des cross compilateurs, je te rassure

Mais dés qu'il est question de travailler avec des threads ou avec des sockets, ou pire, d'accéder à du hardware, cela devient directement beaucoup plus compliqué.

Tu me dira qu'il existe pthread qui fournit une interface "posix" pour les thread, et qu'il existe de très bonnes bibliothèques (portables, ce qui ne gache rien) pour travailler avec les sockets, mais on s'éloigne dans ce cas fortement de ce qui est fournit "de base" sous windows

De même, il existe des bibliothèques graphiques (qui en profitent d'ailleurs pour fournir plein d'autres services) portables, comme Qt ou WxWidget, mais, à ma connaissance du moins, les bibliothèques de chez microsoft ne le sont absolument pas.

La raison tient, essentiellement, au fait que depuis plusieurs années maintenant microsoft tend à tout faire converger vers sont framework .NET.

Il existe bien un projet, cocoa, je crois qui tente de fournir un semblant de portabilité de ce framework sous linux, mais, la dernière fois que je m'y suis intéressé (cela fait longtemps, je l'avoue), ce n'était pas encore vraiment utilisable en prod

Et puis, il reste LE problème que je tendais de pointer du doigt: Tant bien même il existerait une fonction (autre que system) similaire à ShellExecute sous windows, la pratique en elle-même a de quoi me rebuter car elle tend à s'appuyer beaucoup trop sur la présence supposée d'un exécutable ou l'autre: Tant que l'exécutable en question sera présent, cela devrait fonctionner plus ou moins correctement, mais, si, un jour, on tombe sur "une des rares machines" sur lesquelles il n'est pas présent, cela coincera séverement

[white_tentacle]

Et puis, il reste LE problème que je tendais de pointer du doigt: Tant bien même il existerait une fonction (autre que system) similaire à ShellExecute sous windows, la pratique en elle-même a de quoi me rebuter car elle tend à s'appuyer beaucoup trop sur la présence supposée d'un exécutable ou l'autre: Tant que l'exécutable en question sera présent, cela devrait fonctionner plus ou moins correctement, mais, si, un jour, on tombe sur "une des rares machines" sur lesquelles il n'est pas présent, cela coincera séverement

Tu m'y fais penser avec cette remarque, mais ShellExecute est fait pour lancer l'application enregistrée, si on lui donne un fichier html par exemple. Et il me semble que wine sait lancer un navigateur avec gecko comme moteur dans ce genre de cas. Ça peut être une solution ici.