Quel choix pour créer une Interface Utilisateur C++
12 réponses
Flo
Bonjour,
j´ai écris un programme en mode console avec Visual C++ 2008 (Directshow).
Tout marche comme il faut!
Maintenant je dois tout mettre sur une interface utilisateur! Je suis
débutant en programmation alors je pensais être sur la bonne voie avec les
Windows-forms. Mais j´ai toujours des erreurs inattendus. Je commence aussi
à avoir des doutes sur la compatibilité, déjà qu´il fallait que j´enleve
tous les smart pointers (ATL) pour que ca compile. En plus c´a à l´air
extrement lent au démarrage alors qu´en mode console ca fuse!
Quelle autre alternative y-a-t´il pour créer une IU assez facilement?
j´ai écris un programme en mode console avec Visual C++ 2008 (Directshow). Tout marche comme il faut! Maintenant je dois tout mettre sur une interface utilisateur! Je suis débutant en programmation alors je pensais être sur la bonne voie avec les Windows-forms. Mais j´ai toujours des erreurs inattendus. Je commence aussi à avoir des doutes sur la compatibilité, déjà qu´il fallait que j´enleve tous les smart pointers (ATL) pour que ca compile. En plus c´a à l´air extrement lent au démarrage alors qu´en mode console ca fuse! Quelle autre alternative y-a-t´il pour créer une IU assez facilement?
Tu peux tout faire en C/C++ et Win32 api, notamment avec le Dialog Editor Après, ça dépend de la complexité et de ton niveau en Win32. Pour ceux qui n'y connaissent rien, il y a des libs comme QT ou wxWidgets
Flo wrote:
Bonjour,
j´ai écris un programme en mode console avec Visual C++ 2008 (Directshow).
Tout marche comme il faut!
Maintenant je dois tout mettre sur une interface utilisateur! Je suis
débutant en programmation alors je pensais être sur la bonne voie avec les
Windows-forms. Mais j´ai toujours des erreurs inattendus. Je commence aussi
à avoir des doutes sur la compatibilité, déjà qu´il fallait que j´enleve
tous les smart pointers (ATL) pour que ca compile. En plus c´a à l´air
extrement lent au démarrage alors qu´en mode console ca fuse!
Quelle autre alternative y-a-t´il pour créer une IU assez facilement?
Tu peux tout faire en C/C++ et Win32 api, notamment avec le Dialog Editor
Après, ça dépend de la complexité et de ton niveau en Win32.
Pour ceux qui n'y connaissent rien, il y a des libs comme QT ou wxWidgets
j´ai écris un programme en mode console avec Visual C++ 2008 (Directshow). Tout marche comme il faut! Maintenant je dois tout mettre sur une interface utilisateur! Je suis débutant en programmation alors je pensais être sur la bonne voie avec les Windows-forms. Mais j´ai toujours des erreurs inattendus. Je commence aussi à avoir des doutes sur la compatibilité, déjà qu´il fallait que j´enleve tous les smart pointers (ATL) pour que ca compile. En plus c´a à l´air extrement lent au démarrage alors qu´en mode console ca fuse! Quelle autre alternative y-a-t´il pour créer une IU assez facilement?
Tu peux tout faire en C/C++ et Win32 api, notamment avec le Dialog Editor Après, ça dépend de la complexité et de ton niveau en Win32. Pour ceux qui n'y connaissent rien, il y a des libs comme QT ou wxWidgets
Flo
"Jerome" wrote:
Tu peux tout faire en C/C++ et Win32 api, notamment avec le Dialog Editor Après, ça dépend de la complexité et de ton niveau en Win32.
Merci pour ta réponse! Mon niveau... en fait j´ai même pas de niveau, c´est pour ca que je trouvais la toolbox de windows-form très pratique.
Pour ceux qui n'y connaissent rien, il y a des libs comme QT ou wxWidgets
J´ai jamais entendu parlé de ces libs! Je vais essayerca! Comment ce fait il que tu n´ais pas parlé de MFC? Est-ce mal adapté pour les débutants?
cordialement.
"Jerome" <jerome@park.com> wrote:
Tu peux tout faire en C/C++ et Win32 api, notamment avec le Dialog Editor
Après, ça dépend de la complexité et de ton niveau en Win32.
Merci pour ta réponse!
Mon niveau... en fait j´ai même pas de niveau, c´est pour ca que je trouvais
la toolbox de windows-form très pratique.
Pour ceux qui n'y connaissent rien, il y a des libs comme QT ou wxWidgets
J´ai jamais entendu parlé de ces libs! Je vais essayerca! Comment ce fait il
que tu n´ais pas parlé de MFC? Est-ce mal adapté pour les débutants?
Tu peux tout faire en C/C++ et Win32 api, notamment avec le Dialog Editor Après, ça dépend de la complexité et de ton niveau en Win32.
Merci pour ta réponse! Mon niveau... en fait j´ai même pas de niveau, c´est pour ca que je trouvais la toolbox de windows-form très pratique.
Pour ceux qui n'y connaissent rien, il y a des libs comme QT ou wxWidgets
J´ai jamais entendu parlé de ces libs! Je vais essayerca! Comment ce fait il que tu n´ais pas parlé de MFC? Est-ce mal adapté pour les débutants?
cordialement.
Jerome
Flo wrote:
"Jerome" wrote:
Pour ceux qui n'y connaissent rien, il y a des libs comme QT ou wxWidgets
J´ai jamais entendu parlé de ces libs! Je vais essayerca! Comment ce fait il que tu n´ais pas parlé de MFC? Est-ce mal adapté pour les débutants?
Les MFC sont juste un wrapper de l'api Win32, qu'il vaut mieux connaitre si on les utilise. Et puis elles sont plutot en fin de vie, remplacées par .NET et c#
Flo wrote:
"Jerome" <jerome@park.com> wrote:
Pour ceux qui n'y connaissent rien, il y a des libs comme QT ou wxWidgets
J´ai jamais entendu parlé de ces libs! Je vais essayerca! Comment ce fait il
que tu n´ais pas parlé de MFC? Est-ce mal adapté pour les débutants?
Les MFC sont juste un wrapper de l'api Win32, qu'il vaut mieux connaitre
si on les utilise.
Et puis elles sont plutot en fin de vie, remplacées par .NET et c#
Pour ceux qui n'y connaissent rien, il y a des libs comme QT ou wxWidgets
J´ai jamais entendu parlé de ces libs! Je vais essayerca! Comment ce fait il que tu n´ais pas parlé de MFC? Est-ce mal adapté pour les débutants?
Les MFC sont juste un wrapper de l'api Win32, qu'il vaut mieux connaitre si on les utilise. Et puis elles sont plutot en fin de vie, remplacées par .NET et c#
John Deuf
Flo :
Quelle autre alternative y-a-t´il pour créer une IU assez facilement?
Il y a des centaines de bibilothèques disponibles pour faire des GUI en C++.
Personnellement, ma préférée c'est eGUI : http://torjo.com/egui/index.html Car elle utilise bien toutes les possibilités du C++ moderne.
-- John Deuf
Flo :
Quelle autre alternative y-a-t´il pour créer une
IU assez facilement?
Il y a des centaines de bibilothèques disponibles pour faire des GUI en
C++.
Personnellement, ma préférée c'est eGUI :
http://torjo.com/egui/index.html
Car elle utilise bien toutes les possibilités du C++ moderne.
Quelle autre alternative y-a-t´il pour créer une IU assez facilement?
Il y a des centaines de bibilothèques disponibles pour faire des GUI en C++.
Personnellement, ma préférée c'est eGUI : http://torjo.com/egui/index.html Car elle utilise bien toutes les possibilités du C++ moderne.
-- John Deuf
Bertrand Lenoir-Welter
> Pour ceux qui n'y connaissent rien, il y a des libs comme QT ou wxWidgets
wxWidgets, c'est pas mal. Gratuit, plutôt bien maintenu, portable sur Linux et Mac (j'ai pas encore essayé), et ça encapsule OpenGL.
Personnellement, je trouve ça intéressant même si ça donne des boutons aux puristes de l'API (ils se reconnaîtront, ça va troller à mort). Ca permet de se focaliser sur le code applicatif. Mais forcément, ça a un inconvénient : on entre dans un cadre qu'on ne maîtrise pas. Bref, tout dépend de l'appli.
> Pour ceux qui n'y connaissent rien, il y a des libs comme QT ou wxWidgets
wxWidgets, c'est pas mal. Gratuit, plutôt bien maintenu, portable sur
Linux et Mac (j'ai pas encore essayé), et ça encapsule OpenGL.
Personnellement, je trouve ça intéressant même si ça donne des boutons
aux puristes de l'API (ils se reconnaîtront, ça va troller à mort). Ca
permet de se focaliser sur le code applicatif. Mais forcément, ça a un
inconvénient : on entre dans un cadre qu'on ne maîtrise pas. Bref, tout
dépend de l'appli.
> Pour ceux qui n'y connaissent rien, il y a des libs comme QT ou wxWidgets
wxWidgets, c'est pas mal. Gratuit, plutôt bien maintenu, portable sur Linux et Mac (j'ai pas encore essayé), et ça encapsule OpenGL.
Personnellement, je trouve ça intéressant même si ça donne des boutons aux puristes de l'API (ils se reconnaîtront, ça va troller à mort). Ca permet de se focaliser sur le code applicatif. Mais forcément, ça a un inconvénient : on entre dans un cadre qu'on ne maîtrise pas. Bref, tout dépend de l'appli.
Personnellement, je trouve ça intéressant même si ça donne des boutons aux puristes de l'API (ils se reconnaîtront, ça va troller à mort). Ca permet de se focaliser sur le code applicatif. Mais forcément, ça a un inconvénient : on entre dans un cadre qu'on ne maîtrise pas. Bref, tout dépend de l'appli.
Je comprends pas: si ca permet de se concentrer sur le code applicatif, mais que l´on entre dans un cadre que l´on connait pas. C´est un peu contradictoire!
Il faudrait vraiment que ce soit plus simple sinon ca n´a pas d´avantage sur les MFC et Windows-Form.
Personnellement, je trouve ça intéressant même si ça donne des boutons aux
puristes de l'API (ils se reconnaîtront, ça va troller à mort). Ca permet
de se focaliser sur le code applicatif. Mais forcément, ça a un
inconvénient : on entre dans un cadre qu'on ne maîtrise pas. Bref, tout
dépend de l'appli.
Je comprends pas: si ca permet de se concentrer sur le code applicatif, mais
que l´on entre dans un cadre que l´on connait pas. C´est un peu
contradictoire!
Il faudrait vraiment que ce soit plus simple sinon ca n´a pas d´avantage sur
les MFC et Windows-Form.
Personnellement, je trouve ça intéressant même si ça donne des boutons aux puristes de l'API (ils se reconnaîtront, ça va troller à mort). Ca permet de se focaliser sur le code applicatif. Mais forcément, ça a un inconvénient : on entre dans un cadre qu'on ne maîtrise pas. Bref, tout dépend de l'appli.
Je comprends pas: si ca permet de se concentrer sur le code applicatif, mais que l´on entre dans un cadre que l´on connait pas. C´est un peu contradictoire!
Il faudrait vraiment que ce soit plus simple sinon ca n´a pas d´avantage sur les MFC et Windows-Form.
Flo
"Jerome" Flo wrote:
Les MFC sont juste un wrapper de l'api Win32, qu'il vaut mieux connaitre si on les utilise. Et puis elles sont plutot en fin de vie, remplacées par .NET et c#
Donc si je comprends bien QT ou wxWidgets sont plus facile à utiliser que MFC et Windows-Form. Désolé si je repose la question, mais comme j´en ai chi... avec Directshow, moi ca me semble trop beau pour être vrai!
J´ai regardé quelque exemples de fenêtres QT et wxWidgets et j´avoue que ca m´a rappellé les fenetres windows 3.1. C´était surtout des exemples ou tutorials pour Linux, c´est peut être la raison du design plutôt "conservateur" (sans vouloir véxer les Linuxiens). J´ai aussi trouvé des exemples pour windows qui rappelle le style vista, mais ils sont rare et short!
Le choix du GUI s´appuie donc plutôt sur le nombre de literatures et tutos disponible (pour win XP et Vista). Pour le moment je pense sur QT 4. C´est là que j´ai trouvé le plus d´infos.
Franchement le .Net me sert à rien c´est juste embétant avec toutes ces erreurs puisque directshow n´utilise pas le CLR et puis je dois créer just cette application, elle n´a pas besoin d´être portable sur d´autre systeme que Windows. Il faut que ca aille vite maintenant!
Alors je suis vraiment reconnaissant d´avoir eu ces infos! Si vous avez des liens pour des exemples, je suis preneur! :)
Cordialement!
"Jerome" <jerome@park.com> Flo wrote:
Les MFC sont juste un wrapper de l'api Win32, qu'il vaut mieux connaitre
si on les utilise.
Et puis elles sont plutot en fin de vie, remplacées par .NET et c#
Donc si je comprends bien QT ou wxWidgets sont plus facile à utiliser que
MFC et Windows-Form. Désolé si je repose la question, mais comme j´en ai
chi... avec Directshow, moi ca me semble trop beau pour être vrai!
J´ai regardé quelque exemples de fenêtres QT et wxWidgets et j´avoue que ca
m´a rappellé les fenetres windows 3.1. C´était surtout des exemples ou
tutorials pour Linux, c´est peut être la raison du design plutôt
"conservateur" (sans vouloir véxer les Linuxiens). J´ai aussi trouvé des
exemples pour windows qui rappelle le style vista, mais ils sont rare et
short!
Le choix du GUI s´appuie donc plutôt sur le nombre de literatures et tutos
disponible (pour win XP et Vista). Pour le moment je pense sur QT 4. C´est
là que j´ai trouvé le plus d´infos.
Franchement le .Net me sert à rien c´est juste embétant avec toutes ces
erreurs puisque directshow n´utilise pas le CLR et puis je dois créer just
cette application, elle n´a pas besoin d´être portable sur d´autre systeme
que Windows. Il faut que ca aille vite maintenant!
Alors je suis vraiment reconnaissant d´avoir eu ces infos! Si vous avez des
liens pour des exemples, je suis preneur! :)
Les MFC sont juste un wrapper de l'api Win32, qu'il vaut mieux connaitre si on les utilise. Et puis elles sont plutot en fin de vie, remplacées par .NET et c#
Donc si je comprends bien QT ou wxWidgets sont plus facile à utiliser que MFC et Windows-Form. Désolé si je repose la question, mais comme j´en ai chi... avec Directshow, moi ca me semble trop beau pour être vrai!
J´ai regardé quelque exemples de fenêtres QT et wxWidgets et j´avoue que ca m´a rappellé les fenetres windows 3.1. C´était surtout des exemples ou tutorials pour Linux, c´est peut être la raison du design plutôt "conservateur" (sans vouloir véxer les Linuxiens). J´ai aussi trouvé des exemples pour windows qui rappelle le style vista, mais ils sont rare et short!
Le choix du GUI s´appuie donc plutôt sur le nombre de literatures et tutos disponible (pour win XP et Vista). Pour le moment je pense sur QT 4. C´est là que j´ai trouvé le plus d´infos.
Franchement le .Net me sert à rien c´est juste embétant avec toutes ces erreurs puisque directshow n´utilise pas le CLR et puis je dois créer just cette application, elle n´a pas besoin d´être portable sur d´autre systeme que Windows. Il faut que ca aille vite maintenant!
Alors je suis vraiment reconnaissant d´avoir eu ces infos! Si vous avez des liens pour des exemples, je suis preneur! :)
Cordialement!
Bertrand Lenoir-Welter
> Je comprends pas: si ca permet de se concentrer sur le code applicatif, mais que l´on entre dans un cadre que l´on connait pas. C´est un peu contradictoire!
Si tu n'attaches pas d'importance à la gestion de ta fenêtre cadre, menus, icones, boîtes de dialogue, etc., mais tu veux te concentrer sur ton code à toi, une librairie d'encapsulation style wxWidgets ou QT ou MFC et j'en passe t'intéresse. Si maintenant tu veux gérer toi-même de plus près le comportement de ta fenêtre, menus, etc., alors mieux vaut bosser directement avec l'API. Le code applicatif, c'est le contenu, ton code à toi au coeur de l'application, par opposition au code d'interface, le contenant, qui va gérer les fenêtres et autres en lien étroit avec l'API Windows.
Si tu utilises une librairie d'encapsulation de l'API, alors tu travailles avec une couche d'abstraction de cette API et tu perds donc le contact avec elle. Ca peut avoir des avantages : plus facile pour un débutant qui ne connaît pas l'API, portage sur des systèmes différents, ne pas réinventer la roue ; et des inconvénients : éventuellement des performances graphiques moindres, et surtout s'il y a un problème ou un conflit à cause ou au niveau de cette couche d'abstraction, bon courage pour trouver là où ça coince.
A toi d'en juger. Si ton code a besoin de pas mal bricoler dans les fenêtres et objets de contrôle, mieux vaut taper dans l'API pure et dure. Si ton code se suffit à lui-même et a juste besoin d'être encapsulé dans Windows, alors une librairie t'aidera à faire ça vite.
> Je comprends pas: si ca permet de se concentrer sur le code applicatif, mais
que l´on entre dans un cadre que l´on connait pas. C´est un peu
contradictoire!
Si tu n'attaches pas d'importance à la gestion de ta fenêtre cadre,
menus, icones, boîtes de dialogue, etc., mais tu veux te concentrer sur
ton code à toi, une librairie d'encapsulation style wxWidgets ou QT ou
MFC et j'en passe t'intéresse. Si maintenant tu veux gérer toi-même de
plus près le comportement de ta fenêtre, menus, etc., alors mieux vaut
bosser directement avec l'API. Le code applicatif, c'est le contenu, ton
code à toi au coeur de l'application, par opposition au code
d'interface, le contenant, qui va gérer les fenêtres et autres en lien
étroit avec l'API Windows.
Si tu utilises une librairie d'encapsulation de l'API, alors tu
travailles avec une couche d'abstraction de cette API et tu perds donc
le contact avec elle. Ca peut avoir des avantages : plus facile pour un
débutant qui ne connaît pas l'API, portage sur des systèmes différents,
ne pas réinventer la roue ; et des inconvénients : éventuellement des
performances graphiques moindres, et surtout s'il y a un problème ou un
conflit à cause ou au niveau de cette couche d'abstraction, bon courage
pour trouver là où ça coince.
A toi d'en juger. Si ton code a besoin de pas mal bricoler dans les
fenêtres et objets de contrôle, mieux vaut taper dans l'API pure et
dure. Si ton code se suffit à lui-même et a juste besoin d'être
encapsulé dans Windows, alors une librairie t'aidera à faire ça vite.
> Je comprends pas: si ca permet de se concentrer sur le code applicatif, mais que l´on entre dans un cadre que l´on connait pas. C´est un peu contradictoire!
Si tu n'attaches pas d'importance à la gestion de ta fenêtre cadre, menus, icones, boîtes de dialogue, etc., mais tu veux te concentrer sur ton code à toi, une librairie d'encapsulation style wxWidgets ou QT ou MFC et j'en passe t'intéresse. Si maintenant tu veux gérer toi-même de plus près le comportement de ta fenêtre, menus, etc., alors mieux vaut bosser directement avec l'API. Le code applicatif, c'est le contenu, ton code à toi au coeur de l'application, par opposition au code d'interface, le contenant, qui va gérer les fenêtres et autres en lien étroit avec l'API Windows.
Si tu utilises une librairie d'encapsulation de l'API, alors tu travailles avec une couche d'abstraction de cette API et tu perds donc le contact avec elle. Ca peut avoir des avantages : plus facile pour un débutant qui ne connaît pas l'API, portage sur des systèmes différents, ne pas réinventer la roue ; et des inconvénients : éventuellement des performances graphiques moindres, et surtout s'il y a un problème ou un conflit à cause ou au niveau de cette couche d'abstraction, bon courage pour trouver là où ça coince.
A toi d'en juger. Si ton code a besoin de pas mal bricoler dans les fenêtres et objets de contrôle, mieux vaut taper dans l'API pure et dure. Si ton code se suffit à lui-même et a juste besoin d'être encapsulé dans Windows, alors une librairie t'aidera à faire ça vite.
Si tu n'attaches pas d'importance à la gestion de ta fenêtre cadre, menus, icones, boîtes de dialogue, etc., mais tu veux te concentrer sur ton code à toi, une librairie d'encapsulation style wxWidgets ou QT ou MFC et j'en passe t'intéresse. Si maintenant tu veux gérer toi-même de plus près le comportement de ta fenêtre, menus, etc., alors mieux vaut bosser directement avec l'API. Le code applicatif, c'est le contenu, ton code à toi au coeur de l'application, par opposition au code d'interface, le contenant, qui va gérer les fenêtres et autres en lien étroit avec l'API Windows.
Non le code fonctionne comme il le faut, j´ai juste besoin d´une IU pour controler le tout et que ca ait l´air beau.
Si tu utilises une librairie d'encapsulation de l'API, alors tu travailles avec une couche d'abstraction de cette API et tu perds donc le contact avec elle. Ca peut avoir des avantages : plus facile pour un débutant qui ne connaît pas l'API, portage sur des systèmes différents, ne pas réinventer la roue ; et des inconvénients : éventuellement des performances graphiques moindres, et surtout s'il y a un problème ou un conflit à cause ou au niveau de cette couche d'abstraction, bon courage pour trouver là où ça coince.
J´en ai fait la douloureuse expérience avec les windows-forms! La performance était vraiment mauvaise ensuite une erreur inattendu... :(
A toi d'en juger. Si ton code a besoin de pas mal bricoler dans les fenêtres et objets de contrôle, mieux vaut taper dans l'API pure et dure. Si ton code se suffit à lui-même et a juste besoin d'être encapsulé dans Windows, alors une librairie t'aidera à faire ça vite.
En fait le plus dur c´est d´envoyer 2 rendus vidéo sur la surface dans les bons cadres. Apres la déco avec les buttons ca doit rester facile! Parce que j´aimerais bien finir ce programe!
Si tu n'attaches pas d'importance à la gestion de ta fenêtre cadre, menus,
icones, boîtes de dialogue, etc., mais tu veux te concentrer sur ton code
à toi, une librairie d'encapsulation style wxWidgets ou QT ou MFC et j'en
passe t'intéresse. Si maintenant tu veux gérer toi-même de plus près le
comportement de ta fenêtre, menus, etc., alors mieux vaut bosser
directement avec l'API. Le code applicatif, c'est le contenu, ton code à
toi au coeur de l'application, par opposition au code d'interface, le
contenant, qui va gérer les fenêtres et autres en lien étroit avec l'API
Windows.
Non le code fonctionne comme il le faut, j´ai juste besoin d´une IU pour
controler le tout et que ca ait l´air beau.
Si tu utilises une librairie d'encapsulation de l'API, alors tu travailles
avec une couche d'abstraction de cette API et tu perds donc le contact
avec elle. Ca peut avoir des avantages : plus facile pour un débutant qui
ne connaît pas l'API, portage sur des systèmes différents, ne pas
réinventer la roue ; et des inconvénients : éventuellement des
performances graphiques moindres, et surtout s'il y a un problème ou un
conflit à cause ou au niveau de cette couche d'abstraction, bon courage
pour trouver là où ça coince.
J´en ai fait la douloureuse expérience avec les windows-forms! La
performance était vraiment mauvaise ensuite une erreur inattendu... :(
A toi d'en juger. Si ton code a besoin de pas mal bricoler dans les
fenêtres et objets de contrôle, mieux vaut taper dans l'API pure et dure.
Si ton code se suffit à lui-même et a juste besoin d'être encapsulé dans
Windows, alors une librairie t'aidera à faire ça vite.
En fait le plus dur c´est d´envoyer 2 rendus vidéo sur la surface dans les
bons cadres. Apres la déco avec les buttons ca doit rester facile! Parce que
j´aimerais bien finir ce programe!
Si tu n'attaches pas d'importance à la gestion de ta fenêtre cadre, menus, icones, boîtes de dialogue, etc., mais tu veux te concentrer sur ton code à toi, une librairie d'encapsulation style wxWidgets ou QT ou MFC et j'en passe t'intéresse. Si maintenant tu veux gérer toi-même de plus près le comportement de ta fenêtre, menus, etc., alors mieux vaut bosser directement avec l'API. Le code applicatif, c'est le contenu, ton code à toi au coeur de l'application, par opposition au code d'interface, le contenant, qui va gérer les fenêtres et autres en lien étroit avec l'API Windows.
Non le code fonctionne comme il le faut, j´ai juste besoin d´une IU pour controler le tout et que ca ait l´air beau.
Si tu utilises une librairie d'encapsulation de l'API, alors tu travailles avec une couche d'abstraction de cette API et tu perds donc le contact avec elle. Ca peut avoir des avantages : plus facile pour un débutant qui ne connaît pas l'API, portage sur des systèmes différents, ne pas réinventer la roue ; et des inconvénients : éventuellement des performances graphiques moindres, et surtout s'il y a un problème ou un conflit à cause ou au niveau de cette couche d'abstraction, bon courage pour trouver là où ça coince.
J´en ai fait la douloureuse expérience avec les windows-forms! La performance était vraiment mauvaise ensuite une erreur inattendu... :(
A toi d'en juger. Si ton code a besoin de pas mal bricoler dans les fenêtres et objets de contrôle, mieux vaut taper dans l'API pure et dure. Si ton code se suffit à lui-même et a juste besoin d'être encapsulé dans Windows, alors une librairie t'aidera à faire ça vite.
En fait le plus dur c´est d´envoyer 2 rendus vidéo sur la surface dans les bons cadres. Apres la déco avec les buttons ca doit rester facile! Parce que j´aimerais bien finir ce programe!
Bertrand Lenoir-Welter
> En fait le plus dur c´est d´envoyer 2 rendus vidéo sur la surface dans les bons cadres. Apres la déco avec les buttons ca doit rester facile! Parce que j´aimerais bien finir ce programe!
Au fait, rien ne t'empêche d'utiliser une solution hybride avec une fenêtre cadre, boutons, dialogues, etc. dans une librairie d'encapsulation, et traiter la partie graphique rapide directement avec l'API. Tu demandes juste à la lib de te fournir un handle sur un DC et ensuite tu peux jouer avec comme tu veux sans passer par des couches intermédiaires. Du moins s'il y a une réelle différence de performances.
wxWidgets, QT et les autres font exactement comme MFC : une encapsulation C++ de l'API avec une couche intermédiaire plutôt mince, donc rapide et causant peu de soucis en général. Windows Forms, c'est tout à fait autre chose.
> En fait le plus dur c´est d´envoyer 2 rendus vidéo sur la surface dans les
bons cadres. Apres la déco avec les buttons ca doit rester facile! Parce que
j´aimerais bien finir ce programe!
Au fait, rien ne t'empêche d'utiliser une solution hybride avec une
fenêtre cadre, boutons, dialogues, etc. dans une librairie
d'encapsulation, et traiter la partie graphique rapide directement avec
l'API. Tu demandes juste à la lib de te fournir un handle sur un DC et
ensuite tu peux jouer avec comme tu veux sans passer par des couches
intermédiaires. Du moins s'il y a une réelle différence de performances.
wxWidgets, QT et les autres font exactement comme MFC : une
encapsulation C++ de l'API avec une couche intermédiaire plutôt mince,
donc rapide et causant peu de soucis en général. Windows Forms, c'est
tout à fait autre chose.
> En fait le plus dur c´est d´envoyer 2 rendus vidéo sur la surface dans les bons cadres. Apres la déco avec les buttons ca doit rester facile! Parce que j´aimerais bien finir ce programe!
Au fait, rien ne t'empêche d'utiliser une solution hybride avec une fenêtre cadre, boutons, dialogues, etc. dans une librairie d'encapsulation, et traiter la partie graphique rapide directement avec l'API. Tu demandes juste à la lib de te fournir un handle sur un DC et ensuite tu peux jouer avec comme tu veux sans passer par des couches intermédiaires. Du moins s'il y a une réelle différence de performances.
wxWidgets, QT et les autres font exactement comme MFC : une encapsulation C++ de l'API avec une couche intermédiaire plutôt mince, donc rapide et causant peu de soucis en général. Windows Forms, c'est tout à fait autre chose.
