Creer des menus.

On Sun, 20 Jan 2008 13:01:56 +0100, Dan <antispam@mediacd.fr> wrote:

Bonjour à tous.
Je débute sur ce nouveau langage.
J'ai développé précédemment en Visual Basic et je voudrais convertir mes
applications en C ou C++.
Pourriez-vous m'indiquer un site dans lequel serait expliqué la création
de menu et de boutons clicable pour que je puisse mesurer la difficulté
de la tâche.
Maintenant s'il existe un logiciel capable de convertir mes applications
et des en langage C ou C++ je suis évidemment preneur dans un premier
temps, mon but est de toutes façons de comprendre la procédure.
Dans Visual Basic la boîte à outils permet de créer des fenêtres avec
des boutons, je ne trouve rien de cela dans Microsoft Visual studio six
que je possède.
D'avance merci de votre aide

En C++ il n'y à rien de standart pour créer de GUI.
Il fautte tourner vers des blibliothèques spécialisé tel Qt ou WxWidgets

bonjour,

Je débute sur ce nouveau langage.

bonne chance & bienvenue ici

J'ai développé précédemment en Visual Basic et je voudrais convertir mes
applications en C ou C++.

il faut choisir C ou C++. Je te conseille C++, venant de visual basic.

Pourriez-vous m'indiquer un site dans lequel serait expliqué la création
de menu et de boutons clicable pour que je puisse mesurer la difficulté de
la tâche.

pas directement, car ça dépend de ton environnement, de la bibliothèque de
tu utilises, etc...

Maintenant s'il existe un logiciel capable de convertir mes applications
et des en langage C ou C++ je suis évidemment preneur dans un premier
temps, mon but est de toutes façons de comprendre la procédure.

ça faut pas réver

Dans Visual Basic la boîte à outils permet de créer des fenêtres avec des
boutons, je ne trouve rien de cela dans Microsoft Visual studio six que je
possède.

normal : il n'y en a pas.
Si tu veux un EDI C++ avec "boite à outils" pour programmer sous windows en
C++, VC++6 ne conviendra pas : penche toi plutot sur C++ Builder ou les
versions .NET de Visual Studio C++.

D'avance merci de votre aide

alex wrote on 20/01/2008 17:25:

Dans Visual Basic la boîte à outils permet de créer des fenêtres avec
des boutons, je ne trouve rien de cela dans Microsoft Visual studio
six que je possède.

normal : il n'y en a pas.
Si tu veux un EDI C++ avec "boite à outils" pour programmer sous windows
en C++, VC++6 ne conviendra pas : penche toi plutot sur C++ Builder ou
les versions .NET de Visual Studio C++.

?!? Studio 6 (98) contient évidemment un éditeur de ressources
permettant la réalisation d'interfaces aussi pointues qu'une "fenêtre
avec des boutons"; le "classwizard" saura même créer et prototyper les
méthodes appelées sur tel clic ou tel évent.

si l'objectif est de faire des petites appli. avec une interface
basique, Studio6 suffira (et les appli. tournenront très bien sous XP ou
vista).
si le but est de maitriser /son/ interface graphique, il sera également
possible de créer, via les primitives win32 sa propre toolbox ou
d'utiliser telles quelles ou revisitées les libs citées (Qt, WxWidgets).

concernant /les/ versions ".net", seule la version 2003 porte ce nom,
elle est à peu près inutilisable - compilo aussi peu conforme que celui
de 98 dans un environnement inutilement compliqué.

reste pour tester les versions express de 2005 (j'ai du gardé ma version
Pro. - license dév. MSDN - 15 jours avant de tout virer), voire la
version 2008 (que j'ai gardé 3 jours et qui n'existe peut être pas
encore en 'express').

Sylvain.

On Sun, 20 Jan 2008 13:01:56 +0100, "Dan" <antispam@mediacd.fr>:

J'ai développé précédemment en Visual Basic et je voudrais convertir mes
applications en C ou C++.

Mauvaise idée AMHA.
Recréer une application existante est une activité passablement
frustrante : on a de bonnes chances de passer beaucoup de temps pour
se retrouver avec une application qui fonctionne moins bien que la
précédente. Cf aussi
<http://www.joelonsoftware.com/articles/fog0000000027.html>.

Par contre, tu peux écrire certaines fonctions en C++, les mettre dans
des DLL, et les appeler depuis Visual Basic. Ça te permettra de
commencer à porter une partie de ton application en C++, tout en
gardant l'éditeur graphique de Visual Basic.

je ne trouve rien de cela dans Microsoft Visual studio six

Visual C++ 6 est un vieux compilateur, qui n'accepte pas le code C++
récent. Si tu veux programmer en C++, la moindre des choses est
d'avoir un compilateur qui fonctionne, comme Visual C++ 2005 express.
(MinGW conviendrait aussi, mais si tu es habitué aux clicodromes MS,
mieux vaut rester sur Visual.)

Dans Visual Basic la boîte à outils permet de créer des fenêtres avec des
boutons,

D'une manière générale, pour créer une interface graphique, il y a
plusieurs possibilités :

1- Un outil WYSIWYG (cf Google si tu ne connais pas l'acronyme), qui
va générer un fichier dans un format binaire (non éditable à la main).
Flash et Visual Basic en sont des exemples.

2- Un outil WYSIWYG, qui va générer du code lisible et modifiable,
soit dans un langage propriétaire (éventuellement basé sur un autre
langage) [Borland C++ Builder et (je crois) Visual C# sont dans ce
cas.], soit dans un langage "standard" (les moins mauvais des éditeurs
HTML sont dans ce cas).

3- À la main : au lieu du clicodrome, on tape quelque chose comme
bouton= new TButton (this, ID_BOUTON, x, y, largeur, hauteur);
ou
<input type=button name=bouton value=Valider>
pour obtenir l'affichage d'un bouton.


Macromedia Flash (racheté par Adobe) est un outil destiné aux
infographistes, avec, rajouté par-dessus, la possibilité de
programmer. Du coup, il n'est pas étonnant de le voir placé dans la
catégorie (1).

HTML est un langage prévu pour être écrit par un humain ; du coup, un
éditeur HTML WYSIWYG se place généralement quelque part entre
"décevant" et "catastrophique".

C++ est un langage créé par des programmeurs, pour des programmeurs.
Du coup, s'il y a plusieurs bibliothèques très efficaces pour
construire des interfaces graphiques "à la main", les outils
graphiques purement C++ sont moins courants.
Je crois que Qt a ce qu'il faut (mais je n'ai jamais essayé, et je ne
sais pas si leur éditeur WYSIWYG est gratuit) ; Borland avait un
éditeur de boîtes de dialogues limité mais décent (Borland C++ 4.5 et
5.02), mais a préféré partir sur des extensions au C++ (et un mélange
avec Delphi) pour C++ Builder ; Microsoft a trouvé le moyen d'inventer
non pas un nouveau langage, mais deux, et du coup ils ne sont pas trop
motivés pour pondre quelque chose qui fonctionne en C++...


En attendant de voir comment tout ça évoluera, je suis passé à la
programmation d'applications web : un mélange de C++ et de PHP sur le
serveur, pond du HTML et du Javascript, et laisse le navigateur
s'occuper de l'affichage graphique. Ce serait le paradis s'il ne
fallait pas se battre contre les innombrables bugs d'Internet
Explorer.

Dan wrote:

Bonjour à tous.
Je débute sur ce nouveau langage.
J'ai développé précédemment en Visual Basic et je voudrais convertir mes
applications en C ou C++.

Si tu commences tout juste à apprendre le c++, la réalisation
d'interface graphique est très ambitieux.

Je pense que, dans un premier temps, il te serait plus utile d'apprendre
les bases du language en faisant des petites applications en mode
console. Et ensuite une fois que tu maîtrises les bases, tu devras
choisir une bibliothèque qui gérera tes interfaces graphiques.

Pourriez-vous m'indiquer un site dans lequel serait expliqué la création
de menu et de boutons clicable pour que je puisse mesurer la difficulté
de la tâche.

Je te conseille :
http://www.gtkmm.org/

Maintenant s'il existe un logiciel capable de convertir mes applications
et des en langage C ou C++ je suis évidemment preneur dans un premier
temps, mon but est de toutes façons de comprendre la procédure.

Je ne connais pas de tel programme, et ça m'étonnerais qu'ils existent.
Il y a trop de différence entre le c et le vb.

Dans Visual Basic la boîte à outils permet de créer des fenêtres avec
des boutons, je ne trouve rien de cela dans Microsoft Visual studio six
que je possède.
D'avance merci de votre aide

Si tu utilise gtkmm, tu as la possibilité de créer tes interfaces à la
façons vb avec le logiciel glade.

Mais encore une fois, le mieux est que tu commences par apprendre les bases.

Je te conseille :
http://www.gtkmm.org/

Je rebondis car le choix d'une API graphique est typiquement une de
mes préoccupations du moment. Je ne trouves rien qui me conviennes.
Enfin si, mais BeOS est mort, et Haiku n'est pas encore exploitable. Et
puis ce ne serait pas portable...

Existe-t-il un API graphique permettant le genre de chose suivantes :

class MyWindow : public gapi::Windows
{
virtual void onclose() ;
}

Et que onclose soit la méthode appelée lorsque la fenêtre est fermée,
et ne pas avoir à utiliser une syntaxe lourdingue, à savoir connecter la
fonction à un événement. En C je comprends qu'il n'y ait pas le choix,
mais en C++, on a quand même une syntaxe permettant de faire facilement
de l'orienté objet.

J'ai regardé FLTK, Gtkmm, Qt, wxwidgets, et à chaque fois c'est la
même chanson : il faut connecter. Il n'y a que wxWidget qui semble avoir
un comportement comme je le souhaite, mais il faut quand même user d'une
macro qui lie les fonctions avec le gestionnaire d'événements. Je ne
parles pas des API Ms Windows, car je ne les connais pas et que ce n'est
pas portable.

Est-ce moi qui ait une vision biaisée en raison de la Be API, ou
est-ce que cette habitude de connecter est la bonne ?
--
Mickaël Wolff aka Lupus Michaelis
http://lupusmic.org

On Fri, 25 Jan 2008 04:53:19 +0100, Mickaël Wolff
<mickael.wolff@laposte.net>:

est-ce que cette habitude de connecter est la bonne ?

Je pense que ça vient surtout d'un problème d'optimisation.
Une application reçoit énormément de messages (pense à "mouse move"
par exemple, mais je crois me rappeler qu'il y en a d'autres).
Du coup, si toutes les applications doivent gérer un appel de fonction
virtuelle dès que le curseur de la souris se décale d'un pixel, ça
risque de ralentir le système.
Ou du moins, c'était probablement le cas sur les vieux systèmes. Et,
par habitude, tout le monde recopiant les uns sur les autres, le
principe est resté.

On Jan 25, 6:11 am, Fabien LE LEZ <grams...@gramster.com> wrote:

On Fri, 25 Jan 2008 04:53:19 +0100, Mickaël Wolff
<mickael.wo...@laposte.net>:

est-ce que cette habitude de connecter est la bonne ?

Je pense que ça vient surtout d'un problème d'optimisation.
Une application reçoit énormément de messages (pense à "mouse
move" par exemple, mais je crois me rappeler qu'il y en a
d'autres). Du coup, si toutes les applications doivent gérer
un appel de fonction virtuelle dès que le curseur de la souris
se décale d'un pixel, ça risque de ralentir le système. Ou du
moins, c'était probablement le cas sur les vieux systèmes. Et,
par habitude, tout le monde recopiant les uns sur les autres,
le principe est resté.

Je ne crois pas. De toute façon, de tels évenemments de bas
niveau doivent être traités quelque part, avec j'imagine de
toute façon un appel indirect -- virtuel ou à travers un
pointeur à une fonction.

L'avantage d'un enrégistrement d'une action (modèle stratégie,
en somme), plutôt qu'une fonction virtuelle dans la base (modèle
template), c'est qu'on peut changer l'action dynamiquement.
Donc, par exemple, ne s'intéresse à un évenement qu'aux certains
moments, ou changer le comportement suite à un évenement
dynamiquement, en fonction de l'état.

Un autre avantage, c'est de pouvoir gérer les évenements de
l'extérieur de l'objet. On pourrait donc travailler directement
avec Framework::Window, sans avoir besoin d'hériter. Dans le cas
de Window, c'est un avantage mineur, parce que typiquement, tu
n'aurais qu'un ou deux types de Window dans une application.
Mais exiger une classe dérivée différente pour chaque Button qui
a une action différente ? C'est un peu le principe de MVC.

Évidemment, rien n'empêche de supporter les deux. Une fonction
virtuelle qu'on peut supplanter, mais qui dans la classe de base
gère une liste d'actions, qui serait appelées quand l'évenement
arrive. Mais je ne sais pas si c'est une bonne idée ; si on
s'attend à pouvoir enrégistrer des actions, supplanter la
fonction avec une qui ignore les actions enrégistrer serait une
violation flagrante de LSP.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

In article <47995d36$0$17766$426a34cc@news.free.fr>,
Mickaël Wolff <mickael.wolff@laposte.net> wrote:

Je rebondis car le choix d'une API graphique est typiquement une de
mes préoccupations du moment. Je ne trouves rien qui me conviennes.
Enfin si, mais BeOS est mort, et Haiku n'est pas encore exploitable. Et
puis ce ne serait pas portable...

Existe-t-il un API graphique permettant le genre de chose suivantes :

class MyWindow : public gapi::Windows
{
virtual void onclose() ;
}

Et que onclose soit la méthode appelée lorsque la fenêtre est fermée,
et ne pas avoir à utiliser une syntaxe lourdingue, à savoir connecter la
fonction à un événement. En C je comprends qu'il n'y ait pas le choix,
mais en C++, on a quand même une syntaxe permettant de faire facilement
de l'orienté objet.

Sauf que l'oriente objet ne se reduit pas forcement a un design pattern.
Ce que tu veux, c'est de l'interface graphique basee sur le pattern
Template Method: une classe abstraite qui decrit ce qui peut se produire,
et tu specialises dans ta classe a toi.

Ca peut fonctionner, mais c'est relativement peu souple. La plupart
des bibliotheques d'interface graphique C++ se reposent sur d'autres
patterns, pour la plupart issus de Smalltalk.

D'une part le tres connu MVC (un peu trop meme), mais surtout, le modele
d'evenements a la smalltalk, sur une base d'evenements/observateurs de
l'evenement.

J'ai regardé FLTK, Gtkmm, Qt, wxwidgets, et à chaque fois c'est la
même chanson : il faut connecter. Il n'y a que wxWidget qui semble avoir
un comportement comme je le souhaite, mais il faut quand même user d'une
macro qui lie les fonctions avec le gestionnaire d'événements. Je ne
parles pas des API Ms Windows, car je ne les connais pas et que ce n'est
pas portable.

Oui, c'est le modele `fluide'. C'est un modele dynamique, par opposition
a Template Method, qui va te pondre des interfaces rigides.

C'est plus concu sur une base reactive, ou tu vas avoir ton petit ensemble
de widgets interconnecte, qui `se voit' de l'exterieur comme un jeu
d'evenements specifiques (avec toutes les interconnexions absorbes), et sur
lequel tu greffes tes propres observateurs.

L'inconvenient, c'est que c'est *un peu* complique pour les interfaces
simples. L'avantage, c'est que ca passe tres bien a l'echelle, quelle
que soit la taille de l'application, et que ca reagit tres bien aux
changements lies a l'evolution du logiciel... et c'est quand meme plutot
le but de l'oriente objet.

Si une bibliotheque te fournit du Template Method, il est normal que ca
soit implemente au-dessus des primitives de la bibliotheque (event-based)
plutot que l'inverse (qui serait difficile... qui peut le plus, peut le
moins, mais pas le contraire).

Je ne connais pas l'interface de BeOs... s'ils ont fait du pur template
method, c'est quand meme tres limitant.

Il n'y a que recemment que les gens ont commence a comprendre suffisamment
C++ et ses templates pour pouvoir faire un modele reactif `entierement' en C++.
C'est pour ca que tu as encore un preprocesseur specifique dans Qt.
Et c'est pour ca aussi que des interfaces comme MacOSX sont partiellement
en C++, partiellement en objective C.

Il ne reste malheureusement pas grand chose en smalltalk.

est-ce que cette habitude de connecter est la bonne ?

Je pense que ça vient surtout d'un problème d'optimisation.
Une application reçoit énormément de messages (pense à "mouse move"
par exemple, mais je crois me rappeler qu'il y en a d'autres).
Du coup, si toutes les applications doivent gérer un appel de fonction
virtuelle dès que le curseur de la souris se décale d'un pixel, ça
risque de ralentir le système.
Ou du moins, c'était probablement le cas sur les vieux systèmes. Et,
par habitude, tout le monde recopiant les uns sur les autres, le
principe est resté.

Je ne pense pas que l'argument des performances ait joué, même
dans le passé.

La cadence des évènements est d'un tout autre ordre que celle du
processeur. Les évènements souris, par exemple, sont typiquement
générés 50 fois par secondes, alors qu'un appel virtuel prend
environ 1ns, ce qui fait un rapport de 20 millions. Même dans
le passé, ce ratio était suffisamment important pour qu'on ait
pas à s'en soucier.

L'argument est plus celui qu'explique James, si une fenêtre
possède 20 boutons, chacun associé à une action différente,
il est plus simple d'écrire 20 fonctions que 20 classes
différentes.

--
Sylvain Togni