Hello à tous !
 
J'ai codé voici quelque temps un petit convertisseur euro (dispo dans ma signature) qui permet de convertir en euro tout montant saisi dans une TextBox standard de Windows. Faites le test dans la zone de saisie d'URL d'IE, ou dans Démarrer/Exécuter, ça marche nickel (appuyez sur Pause pour convertir le montant saisi en Euro).
 
Par contre, impossible de convertir un montant saisi dans la zone de saisie de Mozilla.
 
Pour récupérer le contenu de la TextBox, je lui envoie un WM_GETTEXT via la fonction SendMessage(), tout simplement. Apparemment, les controles de Mozilla ne reçoivent jamais ce message.
J'ai vérifié le controle utilisé avec Winspector, il semble que ce controle n'en soit pas un, et fasse partie d'un controle global regroupant toute la fenêtre de Mozilla, appelé MozillaWindowClass. Du coup, le controle n'existant pas en tant que controle, il ne reçoit pas mon message et aucune conversion se fait.
 
Avez vous une piste pour pouvoir contourner le problème, en Win 32, afin d'éviter de devoir passer obligatoirement par une extension spécifique à Mozilla écrite en XUL ?

Ça serait une bonne occasion de te mettre à XPFE

dans le même genre, aucun "service" de Mac OS X ne fonctionne dans mozilla.

ET oui, les toolkits genre GTK ou Qt c'est bien sympat à utiliser, mais voilà ce que cela fait. C'est pour cela que je suis pas fan du look custom, surtout quand ce look custom est accompagné d'un feel custom (au passage petit râlage contre cette même zone de texte Mozilla qui ne se comporte pas pareil que les autres applis Win32 quand on clique sur le texte).
J'ai une bonne et une mauvaise nouvelle : la bonne c'est que c'est pas ta faute, la mauvaise, je crois pas que tu puisses faire grand chose...

gm_superstar a écrit a écrit : Ça serait une bonne occasion de te mettre à XPFE

c'est quoi ?
 

on se demande à quoi ça sert que des ingénieurs compétents se cassent le cul à réaliser un OS des plus sympas et fonctionnels si des équipes de développement passent outre et décident de créer leur propre système de fenétrage...
 

Ca dépend si le toolkit encapsule Win32 ou non. C'est le cas pour la VCL, MFC ou Winform (heureusement d'ailleurs), mais je sais pas si ça l'est pour QT ou GTK.
Carton rouge à Mozilla sur ce coup. Réinventer la roue pour des raisons plus que discutables (qui peut me dire le véritable intérêt du XUL ?), voila à quoi ça mène.  
Je crois effectivement qu'il n'y a rien à faire de plus, malheureusement, si ce n'est dire à mon utilisateur d'utiliser IE...

Pour Qt ça ne l'est pas d'après ce que j'ai entendu dire (d'ailleurs ça se sent à l'utilisation).
 
edit: pas basé sur Win32

Je voudrais bien vous y voir à écrire des GUI cross plateforme sans avoir à se recoder toute la partie GUI à chaque plateforme. Des trucs comme GTK, wxWindows, QT, XUL permettent de faire gagner un temps fou.

ben dans le cas de wxWindows, il me semble qu'il se base sur ce que l'OS propose, donc en Win32, on a des contrôles Win32.

 
Et pourquoi l'implémentation du toolkit ne pourrait-elle pas utiliser les éléments natifs de l'OS ?

 
Probablement parceque c'est très difficile à faire de façon cross plateforme.

bin wxWindows le fait bien

y'a quand meme a craindre que le comportement des composants natifs ne soit pas strictement identique d'un OS a l'autre, j'imagine

ça vaudrait le coup de décortiquer le source de Mozilla, et de voir s'il fait beaucoup d'appels Win32 ou pas.
parce que vous allez pas me dire qu'il est réalisé entièrement en C++/STL et portable sans aucune modif du source

certainement, mais j'ai pas encore eu le temps de regarder, je suppose qu'ils ont quand même prévu le coup

 
J'aime pas wxWindow. Le peux que j'ai essayé de l'utilisé me rappelait vraiment Win32 avec ses DC et ses limitations à la noix ( comment ça on ne peut pas mettre des images de plus de 256 lignes dans ce controle ? )
 
Et s'ils n'avaient pas la facheuse manie de changer l'API un peut trop souvent ...

 
XUL lui même est plein de code specifique, mais au dela de ça c'est  bien independant de la plateforme. Pour preuve, il est possible d'écrire des applications en XUL qui sont bien cross plateforme à la fin

Non.
Soit tu as des composants similaires sur chaque plateforme et tu cree un objet commun dans ton GUI multiplateforme, soit un composant qui t'es necessaire n'a pas d'equivalent sur une plateforme et c'est a toi d'en ecrire une implem.
Bon, c'est pas un truc de debutant, mais c'est pas la mort non plus, ca demande juste du temps.
Il y a IMHO des choses bien plus difficiles a programmer, par exemple, implementer un GC efficace.
EDIT: j'ai dit GUI, j'aurais du parler de Framework.
A+,

Se passer de l'OS pour un tk ça permet d'assurer une portabilié parfaite, sans pblm. Si on utilise les controls de l'OS y'a des coomportement spécifiques forcément. C'est ce qui a motivé Sun a développer SWING, alors qu'ils avaient AWT.
Pour les Winforms je ne crois pas que ce soit mappé sur Win32. J'en suis même presque sûr. D'un côté c'est mieux car les contrôles sont plus évolués, et comme c'est fait par MS ben ça reste Win32 like, mais de l'autre y'a pas le look XP...

ben les Winforms sont basées sur .NET et Win32 est condamné à disparaître, donc aucun intérêt de les mapper sur Win32 a priori.

mais que va devenir la programmation en assembleur sous Windows ?

 
Et quand les 2 OS est des composants similaires mais au comportement different ? Il deviens alors facile de créer des applis qui ne marchent que sur un OS à cause de ces differences de comportement. Tout cela rallonge enormement les phases de validation. Alors avec un bon toolkit qui certifie un comportement uniforme entre les plateformes on gagne du temps.
 
De toute façon, le monde informatique ira beaucoup mieux quand tout le monde utilisera QT ou GTK2 ou ...

Inutile, comme ceux qui la pratiquent. Dis, je peux te mettre dans la poubelle moi-même dis ?

n'y pense même pas ! je suis sur qu'une ame charitable va sortir un Asm .NET

langage d'assemblage équivalent -> CLR

Des programmeurs assembleur MSIL ?

ah zut c'est ça que je voulais dire

http://csharpcomputing.com/Tutorials/Lesson2.htm

Cela dit, tant que longhorn n'est pas sorti on a un petit répis.

On rentre dans la classique dichotomie :
doit-on favoriser l'éditeur du logiciel ou l'utilisateur ?
 
Si on utilise un toolkit abstrait qui possède son propre look-and-feel (Xwindow, GTK, QT, mozilla etc.) alors c'est facile de porter d'une plateforme à l'autre, mais pour l'utilisateur c'est chierie, l'intégration est naze (pas les icones sous win, pas d'intégration dans le dock OS X, menu au movais endroit sous OS X etc.), le look-and-feel pas naturel, les raccourcis claver changent etc.  
Si on utilise un toolkit qui repose sur les toolkits natifs alors il faut faire une partie de code spécifique pour chaque plateforme, parfois-même modifier l'interface pour respecter les normes de GUI de la plateforme etc. Et l'utilisateur il est même pas content : c'est normal quand on installe au application elle n'ait rien d'exotique, il est pas là pour se faire chier avec ces trucs, il est là pour bosser. Mais on peut se satisfaire du fait qu'il n'est pas énervé.
 
Perso, je pense que la première solution est une grosse connerie, qui fait partie des choses qui ont mis l'informatique en crise (faire chier l'utilisateur avec des connerie).

en CIL normalisé par l'ecma ce serait un peu plus intelligent, mais c'est une caractéristique étrangère aux assembleux.
 
Pour la poubelle, c'est vraiment pas négociable ? Et si je jette un amiga dans la poubelle avant ?

+1
ça fait chier non seulement l'utilisateur, mais aussi le programmeur, la preuve...

nan ! je commencerais à l'envisager si tu balances un Atari ST ou un Falcon à la place

Merde j'ai encore confondu Amiga et Atari : rien ne ressemble plus à une déchet qu'un autre déchet.

XPFE c'est l'association de XUL, JavaScript et des CSS pour créer des applications qui étendent l'interface de Mozilla.
Et à mon avis ça suffit pour faire un convertisseur euro. Pas la peine de sortir l'artillerie lourde XPCOM et de créer un composant à part entière.
 

Mozilla n'est pas qu'un bête navigateur web. Mozilla c'est une plateforme à part entière. Donc XUL (et tout le bazard XPFE, XPCOM) existe pour :
 - être multiplateforme
 - permettre au développeur web moyen de créer de véritables applications sur la plateforme Mozilla comme il ferait des pages web (c'est le même genre de démarche qu'a adopté Microsoft avec son XAML)

surtout que Amiga est le nom d'une gamme d'ordinateurs alors qu'Atari est une société

Tu veux dire quand les composants sont homologues mais les  fonctionalites differentes?
C'est la que joue toute l'experience du designer de la Framework. Faire un Look & Feel homogene quelque soit la plate forme, ou bien se rapprocher des guidelines pour chaque OS (Les guidelines Windows, Motif et MacOs par exemple) La premiere solution est generalement la plus simple, mais pas necessairement celle qui convient a l'utilisateur final.
A+,

Je viens de lire le post de nraynaud  et je vois qu' il avait deja repondu (plus clairement bien sur) ce que je viens de poster.
A+,

trop facile pour moi.

 
moi j'y connais rien mais le prog de harko est super et c trop dommage qu'il ne fonctionne pas sous mozilla...
 
qq1 saurait le faire sous forme d'extension ?
http://xulfr.org/
http://linuxfr.org/2003/10/22/14347.html
http://www-106.ibm.com/developerwo [...] a-appmozx/
 
ou au pire en HTML...?
 
Tiens, y a une différence entre Firebird et Moz Ap Suite quand même :
"Changement du navigateur intégré basé sur XPFE pour le navigateur indépendant Mozilla Firebird. Note : l'interface utilisateur du nouveau navigateur est définie entièrement avec XUL. En le choisissant, nous montrons combien XUL est une base solide pour des applications rapides et multi-plateformes telles que Mozilla Firebird."
http://www.mozilla-france.org/sect [...] le&artid=3