Reprise du message précédent :
Vazkor >> je sais pas si c'était nécessaire d'en rajouter une couche (même si je suis du même avis que toi)... T'as lu le topic en entier ?

tiens Harkonnen tu tombes bien (au fait.. t'aurais pas un peu oublier mon topic sur le pseudo client FTP asynchrone sous forme de contrôle activeX   ?), j'ai un ptit prob... je voudrai ajouter une fonction qui gère un message que j'ai défini dans mon contrôle activeX mais le problème est que mon fichier ".h" ressemble à ça:
 
"class CNTVFTPActiveXCtrl : public COleControl
{
 DECLARE_DYNCREATE(CNTVFTPActiveXCtrl)
 
// Constructor
public:
 CNTVFTPActiveXCtrl();
 
 // gestion évenement
 LRESULT OnFTPCommandFinished(WPARAM wParam,  LPARAM lParam);
 
// Overrides
 // ClassWizard generated virtual function overrides
 //{{AFX_VIRTUAL(CNTVFTPActiveXCtrl)
 public:
 virtual void OnDraw(CDC* pdc, const CRect& rcBounds, const CRect& rcInvalid);
 virtual void DoPropExchange(CPropExchange* pPX);
 virtual void OnResetState();
 virtual DWORD GetControlFlags();
 //}}AFX_VIRTUAL
 
// Implementation
protected:
 DWORD CurrentCommand;
 CString Param1;
 CString Param2;
 CString Result;
 BOOL Param5;
 
 ~CNTVFTPActiveXCtrl();
 
 DECLARE_OLECREATE_EX(CNTVFTPActiveXCtrl)    // Class factory and guid
 DECLARE_OLETYPELIB(CNTVFTPActiveXCtrl)      // GetTypeInfo
 DECLARE_PROPPAGEIDS(CNTVFTPActiveXCtrl)     // Property page IDs
 DECLARE_OLECTLTYPE(CNTVFTPActiveXCtrl)  // Type name and misc status
 
// Message maps
 //{{AFX_MSG(CNTVFTPActiveXCtrl)
 //}}AFX_MSG
 DECLARE_MESSAGE_MAP()
"
 
et je veux ajouter une fonction OnFTPCommandFinished qui gère le message WM_FTPCOMMANDFINISHED (défini en WM_USER + 101)
 
et donc je fais les changements suivants ans le ".h" avec un "LRESULT OnFTPCommandFinished(WPARAM wParam,  LPARAM lParam);" qui traine :
 
"
// Message maps
   BEGIN_MESSAGE_MAP(CNTVFTPActiveXCtrl, COleControl)
 //{{AFX_MSG(CNTVFTPActiveXCtrl)
 //}}AFX_MSG
 DECLARE_MESSAGE_MAP()
 ON_MESSAGE(WM_TRAYMESSAGE, OnFTPCommandFinished)
 END_MESSAGE_MAP()
"
 
j'obtiens l'erreur suivante : "syntax error : '{'"
à la ligne correspondant à "BEGIN_MESSAGE_MAP(CNTVFTPActiveXCtrl, COleControl)" et comme je comprend rien à la signification de ses macros, je pensais que tu pourrais m'aider ...

oups, effectivement, je t'ai oublié pour ton client FTP    
le pb c'est que mon systeme était en vrac, et comme j'ai tout reformaté j'ai perdu les cookies, donc je n'avais plus rien dans mes messages auxquels j'avais participé.... patapai    
 
sinon, pour ton pb, déja tu déclares la fonction OnFTPCommandFinished au mauvais endroit. il faut la déclarer ici :
 
// Generated message map functions
//{{AFX_MSG(CNTVFTPActiveXCtrl)
// Messages traitant les évènements de ta classe
//}}AFX_MSG
afx_msg LRESULT OnFTPCommandFinished WPARAM wParam, LPARAM lParam);
DECLARE_MESSAGE_MAP()
 
Ensuite, je vois pas pourquoi il te fait une erreur sur un "{" alors qu'il n'y en a pas sur la ligne concernée...    
Il doit manquer un ";" ou une " )" quelque part. Essaie de poster l'intégralité de ton .h  
 
 

merci pour  ton aide, en fait il y a un '{' (et même plusieurs) dans la définition de la macro "BEGIN_MESSAGE_MAP", la voici:
"#ifdef _AFXDLL
#define BEGIN_MESSAGE_MAP(theClass, baseClass) \
 const AFX_MSGMAP* PASCAL theClass::_GetBaseMessageMap() \
  { return &baseClass::messageMap; } \
 const AFX_MSGMAP* theClass::GetMessageMap() const \
  { return &theClass::messageMap; } \
 AFX_COMDAT AFX_DATADEF const AFX_MSGMAP theClass::messageMap = \
 { &theClass::_GetBaseMessageMap, &theClass::_messageEntries[0] }; \
 AFX_COMDAT const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = \
 { \
 
#else
#define BEGIN_MESSAGE_MAP(theClass, baseClass) \
 const AFX_MSGMAP* theClass::GetMessageMap() const \
  { return &theClass::messageMap; } \
 AFX_COMDAT AFX_DATADEF const AFX_MSGMAP theClass::messageMap = \
 { &baseClass::messageMap, &theClass::_messageEntries[0] }; \
 AFX_COMDAT const AFX_MSGMAP_ENTRY theClass::_messageEntries[] = \
 { \
 
#endif"
 
c le '{' avant le "#else" qui semble poser problème...
 
voici la déclaration de ma classe:
 
"
class CNTVFTPActiveXCtrl : public COleControl
{
 DECLARE_DYNCREATE(CNTVFTPActiveXCtrl)
 
// Constructor
public:
 CNTVFTPActiveXCtrl();
 
 
// Overrides
 // ClassWizard generated virtual function overrides
 //{{AFX_VIRTUAL(CNTVFTPActiveXCtrl)
 public:
 virtual void OnDraw(CDC* pdc, const CRect& rcBounds, const CRect& rcInvalid);
 virtual void DoPropExchange(CPropExchange* pPX);
 virtual void OnResetState();
 virtual DWORD GetControlFlags();
 //}}AFX_VIRTUAL
 
// Implementation
protected:
 
 // variables pour la gestion des commandes ftp
 DWORD CurrentCommand;
 CString Param1;
 CString Param2;
 CString Result;
 BOOL Param5;
 
 ~CNTVFTPActiveXCtrl();
 
 DECLARE_OLECREATE_EX(CNTVFTPActiveXCtrl)    // Class factory and guid
 DECLARE_OLETYPELIB(CNTVFTPActiveXCtrl)      // GetTypeInfo
 DECLARE_PROPPAGEIDS(CNTVFTPActiveXCtrl)     // Property page IDs
 DECLARE_OLECTLTYPE(CNTVFTPActiveXCtrl)  // Type name and misc status
 
// Message maps
   BEGIN_MESSAGE_MAP(CNTVFTPActiveXCtrl, COleControl)
 //{{AFX_MSG(CNTVFTPActiveXCtrl)
 //}}AFX_MSG
 DECLARE_MESSAGE_MAP()
 /**/afx_msg LRESULT OnFTPCommandFinished WPARAM wParam, LPARAM lParam);
 ON_MESSAGE(WM_TRAYMESSAGE, OnFTPCommandFinished)
 END_MESSAGE_MAP()
 
// Dispatch maps
 //{{AFX_DISPATCH(CNTVFTPActiveXCtrl)
            ......
            .....
 //}}AFX_DISPATCH
 DECLARE_DISPATCH_MAP()
 
// Event maps
 //{{AFX_EVENT(CNTVFTPActiveXCtrl)
 void FireFTPCommandFinished(long RVal, long NumCommand, LPCTSTR ResultParam)
  {FireEvent(eventidFTPCommandFinished,EVENT_PARAM(VTS_I4  VTS_I4  VTS_BSTR), RVal, NumCommand, ResultParam);}
 //}}AFX_EVENT
 DECLARE_EVENT_MAP()
 
// Dispatch and event IDs
public:
 enum {
 //{{AFX_DISP_ID(CNTVFTPActiveXCtrl)
         .......
         .......
//}}AFX_DISP_ID
 };
private:
// OLE_HANDLE hwnd;
 BOOL EndThread;
 CFtp MyFtp;
 HANDLE hThread;
 
#ifdef _DEBUG
 FILE* file;
#endif
 
 
friend DWORD WINAPI ThreadProc(LPVOID lpParameter);
};"
 
 
wala, etj'ai toujous le même prob donc...

[jfdsdjhfuetppo]--Message édité par ZZZzzz le 16-05-2002 à 15:26:01--[/jfdsdjhfuetppo]

qlq un peut m expliquer pk la creation d une bete socket (winsock2) ne marche pas???

 
Il est ou le "}" correspondant ??? Même chose pour celui situé avant le #endif !

 
Dans ce thread ca parle trop de MFC, enfin soyons sérieux, MS mise sur .NET pas MFC. MS à déjà abandonné VB6 (VB.NET est un outil différent non compatible VB6), MS ne vas pas de géner pour abandonner MFC d'ici quelques temps.
 
Alors se mettre aux MFC maintenant je ne trouve pas cela très judicieux, comme dirais un de mes copains "comique", "MFC c'est une LIB compliqué pour faire des choses simples" (CLR aussi d'ailleurs) , je dirais se mettre ajourd'hui à .NET ou à VCL/CLX oui. A MFC BOF.

[jfdsdjhfuetppo]--Message édité par Vazkor le 16-05-2002 à 16:29:09--[/jfdsdjhfuetppo]

borland avec sa clx est pas mal....
il pourrait bien la porter sous d'autre os...
j'avais lu des rumeurs pour porter delphi sous solaris et macos X...
 
ta pensé à c++ builder?
tu peux programmer avec les mfc, vcl/clx...
tu pourras rendre tes programmes compatible avec linux bientôt...
 
pour moi mfc =  passé
futur = java, vcl/clx, .net.... mais je toucherais pas au .net durant ma formation et c'est tant mieux....

[jfdsdjhfuetppo]--Message édité par os2 le 16-05-2002 à 17:38:58--[/jfdsdjhfuetppo]

futur = VCL ?
 
     

Bah VCL c'est déjà nettement plus une logique objet que MFC je trouve...  
ça fait moins vieux machin...

certes, mais elle a qd meme quelques années d'existence derriere elle...
on va dire qu'elle sera encore valable à court/moyen terme, mais à long terme, ça me parait beaucoup plus incertain

Tu te trompe harkonen...
 
Parce que meme la CLR ne fait pas 20% de ce que fait la VCL.
 
C'est meme pas un avis à moi, dans le dernier programmez de Mai 2002, lis le test de C++Builder, le testeur manifestement compétant, et ayant testé à la fois VS.net et C++Builder 6 à écrit : "C++Builder 6 - Un produit formidable qui apporte une productivité sans équivalent dans le monde du C++"
 
Comparatif VS.NET versus C++Builder 6 : "C++Builder remporte la palme haut la main... La richesse exhubérante de la palette de composants de C++Builder (VCL/CLX) et le savoir faire étendu de son wizard tourne ceux de .net en ridicule...C++Builder 6 atteint une belle maturité et nous semble plus que jamais etre le meilleur outil de développement C++ sous Windows"
 
Que VCL (ou CLX) apporte une productivité de 10 à 100 fois supérieure à MFC cela on le savait déjà, mais la révolution VS.NET se fait toujours atteindre, puisque C++Builder garde toujours une (très) large avance en productivité sur VS.NET
 
De plus Borland à annoncé le support direct de .net dans ses futures versions, ce qui fait que si tu part sur C++Builder , tu à accès a toutes les libs et toutes les technologies (C++Builder inclus MFC aussi).
 
Au total avec C++Builder : MFC, OWL, STL, VCL, CLX, SOAP, XML, CORBA, ...
 
Bref tu as le choix. Et c'est portable sous Linux si tu te sert de STL ou CLX.

[jfdsdjhfuetppo]--Message édité par Vazkor le 16-05-2002 à 18:02:26--[/jfdsdjhfuetppo]

 

 
En gros, tant qu'il y aurait un support pour Windows Millenium, les MFC seront encore d'actualité.

Je suis bien d'accord pour dire que C++ Builder (ou plutot la VCL) est plus opérationnelle que .NET
 
Mais ne trouves tu pas cela normal, étant donné la jeunesse de .NET ?
 
La CLR est sortie il y a même pas 1 an, alors que la VCL existe depuis bien plus longtemps, il est donc normal que .NET sois beaucoup moins évolué car reposant sur une plate forme bien trop jeune encore.
 
Tu compares un produit qui a fait ses preuves face à un produit qui à encore tout à prouver, de par sa jeunesse.
 
Quant au débat MFC/VCL, je pense que tout le monde aura compris que je suis pro MFC. Je le sais, j'utilise les 2 : Builder 5 au boulot et VC++ 6 chez moi. Et je trouve la VCL, certes très complète et fonctionnelle, mais également très lourde.
 
Je prends un exemple : les sockets.
 
En MFC, la classe CAsyncSocket te suffit pour n'importe quelle application client ou serveur, alors que la VCL propose 2 classes distinctes : TServerSocket et TClientSocket.
 
Certes, cette distinction peut augmenter la productivité en t'évitant de tester des booléens pour savoir si tu es client ou serveur, mais si tu souhaites transformer ton programme client en application serveur par exemple, tu dois modifier toutes les instances de classe.
 
Je me suis aussi essayé au C#, et je dois dire que ce langage, même si lui aussi présente quelques défauts, est prometteur.
 
En résumé, laissons le temps à .NET d'évoluer, cette plate forme pourrait bien nous surprendre, tout comme Java en son temps.
 
Edit : et je pense pas que les MFC vont être abandonnées par M$ si rapidement que ça étant donné le nombre conséquent de développeurs VC++ dans le monde.

[jfdsdjhfuetppo]--Message édité par Harkonnen le 16-05-2002 à 18:19:56--[/jfdsdjhfuetppo]

En parlant de composants réseaux, tu as vu les composants Indy ou les composants ICS pour Delphi et C++Builder  : http://www.developpez.com/internet.htm
 
Ces composants existent en CLX (Windows et Linux) et ce sont les plus balaisent qui existent à mons avis, et ils sont gratuits tous les deux...

 
Indy est même OpenSource

He, restez dans le sujet, le pauv gars vous a dit qu'il utilise GTK et qu'il a un problème avec les Winsocks
 
Pour info, les Winsocks sont presque POSIX compliant ( donc comme sous Unix ) mais il y a une difference majeure : il faut initialiser la lib ! En fait, une vielle apli Unix que j'avais fait à été portée en 10 minutes pour windows ( une fois la couche graphique faite bien sur ) grace à cette quasi compatibilité. Evidemment, les 10 minutes ont été passées à comprendre pourquoi ca marchais pas

Kristoph> j'ai dépanné tomate77 dans un autre topic, il avait une erreur 10093 en créant son socket => il avait pas appelé WSAStartup
 
Pour ce qui est des composants, VC++ n'est pas en reste, et on voit la le gros avantage des MFC : elles sont modulables.
 
Va voir sur codeguru ou codeproject, il y a une quantité affolante de classes en tout genre permettant de faire tout et n'importe quoi.
 
Avantage sur les composants que tu décris : ce sont des classes prêtes à compiler, donc on a accès au source et on peut les modifier comme on le souhaite

Harkonnen> "il est ou le "}" correspondant ??? Même chose pour celui situé avant le #endif ! "
 
 
>ben il est dans la définition du END_MESSAGE_MAP. faut bien voir que dans le ".h" c écrit comme ça:
 
BEGIN_MESSAGE_MAP // correspondance '{'
.....
END_MESSAGE_MAP   // correspondance '}'

YUP !

avec l'arrivé de xp, millenium va mourir très bientôt...
je me demande même s'il n'est pas mort né cet os

Tetragrammaton IHVH a écrit a écrit :       En gros, tant qu'il y aurait un support pour Windows Millenium, les MFC seront encore d'actualité.