Bonjour,  
Je debute en realisation avec Visual C++ et j'aimerai savoir comment faire un appel avec WinExec ou ShellExecute en cliquant sur un lien à la manière HTML ?  
 
Merci d'avance.

Pour faire un lien, tu récupères la position de ta souris (WM_MOUSEMOVE). Si elle se trouve sur un lien tu changes le curseur, la couleur, etc. Lors d'un clic (WM_LBUTTONUP), si c'est un lien, tu lances ton ShellExecute.
 
bon en gros :
 

 
et c'est la meme chose pour modifier l'aspect du lien avec l'évènement WM_MOUSEMOVE.

Bonsoir,
Merci pour ta réponsonse, C'est tout à fait ce que je recherchais !
Mais etant debutant avec Visual C++, n'y aurait il pas dans le soft un "controle ActiveX" qui gère cette gestion  de lien ?
 
Merci encore,
Thierry.

Sous XP tu as le controle SysLink. Sinon crée un STATIC avec le style SS_NOTIFY pour détecter qu'il est cliqué et gère WM_CTLCOLORSTATIC pour changer sa couleur en bleu par exemple. Faut faire un petit subclassing aussi je pense pour changer le curseur de la souris (SetClassLong( GCL_HCURSOR )).
 
En fait je viens de trouver ça:
http://www.wischik.com/lu/programm [...] emurl.html
ça devrait te simplifier la tâche.

Hello,
le lien est interressant, je vais tester ...
mais c'est pas gagné, le C++, je débute ...
merci du tuyau,
@+

Bon, j'ai regardé tout ça d'un peu plus pres, mais comment associer le code au static que j'ai mis sur le dialogue principal ?
Un peu de lecture, voici mon code ...
**********************************************************
 // app_urlDlg.cpp : implementation file
//
 
#include "stdafx.h"
#include "app_url.h"
#include "app_urlDlg.h"
 
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
 
/////////////////////////////////////////////////////////////////////////////
// CAboutDlg dialog used for App About
 
class CAboutDlg : public CDialog
{
public:
 CAboutDlg();
 
// Dialog Data
 //{{AFX_DATA(CAboutDlg)
 enum { IDD = IDD_ABOUTBOX };
 //}}AFX_DATA
 
 // ClassWizard generated virtual function overrides
 //{{AFX_VIRTUAL(CAboutDlg)
 protected:
 virtual void DoDataExchange(CDataExchange* pDX);    // DDX/DDV support
 //}}AFX_VIRTUAL
 
// Implementation
protected:
 //{{AFX_MSG(CAboutDlg)
 //}}AFX_MSG
 DECLARE_MESSAGE_MAP()
};
 
CAboutDlg::CAboutDlg() : CDialog(CAboutDlg::IDD)
{
 //{{AFX_DATA_INIT(CAboutDlg)
 //}}AFX_DATA_INIT
}
 
void CAboutDlg::DoDataExchange(CDataExchange* pDX)
{
 CDialog::DoDataExchange(pDX);
 //{{AFX_DATA_MAP(CAboutDlg)
 //}}AFX_DATA_MAP
}
 
BEGIN_MESSAGE_MAP(CAboutDlg, CDialog)
 //{{AFX_MSG_MAP(CAboutDlg)
  // No message handlers
 //}}AFX_MSG_MAP
END_MESSAGE_MAP()
 
/////////////////////////////////////////////////////////////////////////////
// CApp_urlDlg dialog
 
CApp_urlDlg::CApp_urlDlg(CWnd* pParent /*=NULL*/)
 : CDialog(CApp_urlDlg::IDD, pParent)
{
 //{{AFX_DATA_INIT(CApp_urlDlg)
  // NOTE: the ClassWizard will add member initialization here
 //}}AFX_DATA_INIT
 // Note that LoadIcon does not require a subsequent DestroyIcon in Win32
 m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME);
}
 
void CApp_urlDlg::DoDataExchange(CDataExchange* pDX)
{
 CDialog::DoDataExchange(pDX);
 //{{AFX_DATA_MAP(CApp_urlDlg)
  // NOTE: the ClassWizard will add DDX and DDV calls here
 //}}AFX_DATA_MAP
}
 
BEGIN_MESSAGE_MAP(CApp_urlDlg, CDialog)
 //{{AFX_MSG_MAP(CApp_urlDlg)
 ON_WM_SYSCOMMAND()
 ON_WM_PAINT()
 ON_WM_QUERYDRAGICON()
 ON_WM_MOUSEMOVE()
 //}}AFX_MSG_MAP
END_MESSAGE_MAP()
 
/////////////////////////////////////////////////////////////////////////////
// CApp_urlDlg message handlers
 
BOOL CApp_urlDlg::OnInitDialog()
{
 CDialog::OnInitDialog();
 
 // Add "About..." menu item to system menu.
 
 // IDM_ABOUTBOX must be in the system command range.
 ASSERT((IDM_ABOUTBOX & 0xFFF0) == IDM_ABOUTBOX);
 ASSERT(IDM_ABOUTBOX < 0xF000);
 
 CMenu* pSysMenu = GetSystemMenu(FALSE);
 if (pSysMenu != NULL)
 {
  CString strAboutMenu;
  strAboutMenu.LoadString(IDS_ABOUTBOX);
  if (!strAboutMenu.IsEmpty())
  {
   pSysMenu->AppendMenu(MF_SEPARATOR);
   pSysMenu->AppendMenu(MF_STRING, IDM_ABOUTBOX, strAboutMenu);
  }
 }
 
 // Set the icon for this dialog.  The framework does this automatically
 //  when the application's main window is not a dialog
 SetIcon(m_hIcon, TRUE);   // Set big icon
 SetIcon(m_hIcon, FALSE);  // Set small icon
 
 // TODO: Add extra initialization here
 
 return TRUE;  // return TRUE  unless you set the focus to a control
}
 
void CApp_urlDlg::OnSysCommand(UINT nID, LPARAM lParam)
{
 if ((nID & 0xFFF0) == IDM_ABOUTBOX)
 {
  CAboutDlg dlgAbout;
  dlgAbout.DoModal();
 }
 else
 {
  CDialog::OnSysCommand(nID, lParam);
 }
}
 
// If you add a minimize button to your dialog, you will need the code below
//  to draw the icon.  For MFC applications using the document/view model,
//  this is automatically done for you by the framework.
 
void CApp_urlDlg::OnPaint()  
{
 if (IsIconic())
 {
  CPaintDC dc(this); // device context for painting
 
  SendMessage(WM_ICONERASEBKGND, (WPARAM) dc.GetSafeHdc(), 0);
 
  // Center icon in client rectangle
  int cxIcon = GetSystemMetrics(SM_CXICON);
  int cyIcon = GetSystemMetrics(SM_CYICON);
  CRect rect;
  GetClientRect(&rect);
  int x = (rect.Width() - cxIcon + 1) / 2;
  int y = (rect.Height() - cyIcon + 1) / 2;
 
  // Draw the icon
  dc.DrawIcon(x, y, m_hIcon);
 }
 else
 {
  CDialog::OnPaint();
 }
}
 
// The system calls this to obtain the cursor to display while the user drags
//  the minimized window.
HCURSOR CApp_urlDlg::OnQueryDragIcon()
{
 return (HCURSOR) m_hIcon;
}
 

Ah t'es en MFC... ben va sur codeproject/codeguru tu trouveras des contrôles tout beau tout prêt.

Bonjour,
Aurais tu une adresse plus precise ?
Merci.

http://www.codeguru.com/  
http://www.codeproject.com/
 
A+,

OK, merci.
Mais comme je debute, j'ai cru comprendre qu'il y avait plusieurs maieres de programmer avec Visual C++ ?
On parle de MFC, WIN32 ...
Le plus lisible/comprensible c'est quoi ?
@+

Ca depend un peu de ce qu'on a a faire.
 
A+,

La base c'est WIn32, l'API C. Le code Win32 est normalement compilable par n'importe quel compilo sous Windows.
Après y'a des bibliothèques C++ qui encapsulent la bête. Les MFC en sont une, c'est la programmation Windows C++ selon Microsoft. Y'en a d'autres : la VCL chez Borland par exemple. Pour les 2, le code ne compile que sur leurs outils respectifs (VC++ et BCB) car ces derniers génèrent une partie du code via des assistants etc...

Donc, d'après toi il serait plus clair de developper en win32, soit sans les MFC ? Mais alors le squelette d'un prog reste le meme qi'en Win 16 bits et est compilable avec Visual C++ ?

Pourquoi nous parles tu de Win16 bits. C'est une couche geologique fossile, ça
A+,

Parceque n'ayant pas l'outil Visual C++ 32, je programmais qu'avec ça et c'etait pas si mal ... On voyait mieux le fonctionnement d'un programme, alors qu'avec le MFC, on ne voit plus rien, c'est une autre approche ...

Ca s'appelle l'encapsulation, c'est ce qui permet d'envisager de terminer un jour de gros programmes.
Pour ta question, je t'ai répondu sur l'autre forum

La prog avec l'API Win32, c'est comme celle en 16 bits (a la taille de qques parametres de fonctions pres) sauf que tu n'as plus a t'emmerder a faire de la gestion memoire avec des handles, des locks/unlocks...  
A+,

Mon conseil perso, qui n'engage que moi, mais qui n'est pas sans fondements: oublie les MFC, c'est dégueulasse et ça t'empêche de te concentrer sur ton projet.
T'auras plus vite qq chose d'utilisable avec une librairie comme Lgi par exemple. Sur le site, il y a des exemples d'applis écrites avec, avec le code source. Il suffit d'y jeter un oeil pour se rendre compte combien c'est bcp plus propre et immédiatement compréhensible que les MFC.

Ce genre de libs c'est sympa au début. Mais après quand il faut faire de l'automation ou utiliser des controles un peu plus complexes genre tableau / rich edit, trouver de la doc / de l'aide, correction de bug / update, etc... c'est moins rose. Surtout que ça m'a l'air pas mal dépendant de la bonne volonté d'un seul mec. A mon avis utiliser ce truc c'est le meilleur moyen de se retrouver piégé à moyen terme.
Donc si t'as un projet un peu sérieux, utilise des lib qui ont fait leurs preuves et laisse les autres essuyer les platres.
Les MFC ceci celà, mais faut reconnaitre que si t'as commencé à développer y'a 10 ans avec t'as bien rentabilisé ton investissement.
Les MFC c'est vieux. Aujourd'hui on se tourne plutot vers .Net. Quoique si c'est la prog Win32 bas niveau qui t'intéresse, alors les MFC devraient te plaire car c'est assez proche.

Bonjour à tous,
Moi ce que je shouaite rerouver c'est la methode classique de programmation où l'on retrouve la boucle message et où l'on met ses controles à l'endroit que l'on veut, tout en restant structuré bien sûr ...Et quansd j'ai découvert la  programmation MFC, j'ai été surpris de pas retrouver le bon vieux  CreateWindow, CreateDialog ou bien encore le switch (message) en debut de WndProc !
C'est dire à quelle programmation je fais allusion !
@+

Ben Win32 pur et dur alors. A toi de structurer comme tu veux.

Oui !
D'ailleurs, sans trop deborder du sujet traité, j'ai essayé un truc :
C'est un peu ton pseudo qui m'a inspiré !
j'ai repris un squelette que j'avais. ça passe en compil avec Visual C++, mais pas au buid ...
Voici le code :
 
#include <windows.h>
 
int APIENTRY WinMain(HINSTANCE hInstance,  
                     HINSTANCE hPrevInstance,  
                     LPSTR     lpCmdLine,  
                     int       nCmdShow)  
{  
 
     static char szAppName[] = "HelloWin" ;
     HWND        hwnd ;
     MSG         msg ;
     WNDCLASS    wndclass ;
 
     if (!hPrevInstance)
   {
   wndclass.style         = CS_HREDRAW | CS_VREDRAW ;
//--> erreur de compil
//   wndclass.lpfnWndProc   = WndProc ;
   wndclass.cbClsExtra    = 0 ;
   wndclass.cbWndExtra    = 0 ;
   wndclass.hInstance     = hInstance ;
   wndclass.hIcon         = LoadIcon (NULL, IDI_APPLICATION) ;
   wndclass.hCursor       = LoadCursor (NULL, IDC_ARROW) ;
//--> erreur de compil
//   wndclass.hbrBackground = GetStockObject (WHITE_BRUSH) ;
   wndclass.lpszMenuName  = NULL ;
   wndclass.lpszClassName = szAppName ;
 
   RegisterClass (&wndclass) ;
   }
   
     hwnd = CreateWindow (szAppName,         // nom de la classe
      "Le programme Hello",    // titre de la fenetre
      WS_OVERLAPPEDWINDOW,     // style de la fenetre
      CW_USEDEFAULT,           // position initiale en x
      CW_USEDEFAULT,           // position initiale en y
      CW_USEDEFAULT,           // largeur initiale
      CW_USEDEFAULT,           // hauteur initiale
      NULL,                   // handle de la fenetre mere
      NULL,                // handle du menu de la fenetre
      hInstance,               // handle de l'instance
      NULL) ;                  // parametres de creation
 
     ShowWindow (hwnd, nCmdShow) ;
     UpdateWindow (hwnd) ;
 
     while (GetMessage (&msg, NULL, 0, 0))
   {
   TranslateMessage (&msg) ;
   DispatchMessage (&msg) ;
   }
     return msg.wParam ;
     }
 
long  WndProc (HWND hwnd, UINT message, UINT wParam,  LONG lParam)
     {
     HDC         hdc ;
     PAINTSTRUCT ps ;
     RECT        rect ;
 
     switch (message)
   {
   case WM_PAINT:
        hdc = BeginPaint (hwnd, &ps) ;
 
        GetClientRect (hwnd, &rect) ;
 
        DrawText (hdc, "Hello, Windows !", -1, &rect,
    DT_SINGLELINE | DT_CENTER | DT_VCENTER) ;
 
        EndPaint (hwnd, &ps) ;
        return 0 ;
 
   case WM_DESTROY:
        PostQuitMessage (0) ;
        return 0 ;
   }
 
     return DefWindowProc (hwnd, message, wParam, lParam) ;
     }

Utilise la balise cpp pour ton code.
Tu utilises WndProc avant de l'avoir déclarée. Ajoute au moins une déclaratino de WndProc avant WinMain, ou remonte WndProc en haut.
Pour hbrBackground faut caster en HBRUSH.

J'ai fait comme tu as dit, j'ai declaré WndProc plus haut comme suit :

Mais j'ai toujours une erreur sur  

Quand au link, il me parle de unresolved external symbol _main

Il faut créer un projet Win32 et non pas un projet console. C'est quoi l'erreur ?

C'est fait et ça ira peut etre mieux ...
et comment caster

Normalement y'a pas besoin.

Bon j'avais une petite erreur de compil
mais j'ai trouvé un petit tuto sympa pour redebuter ...
http://win32.planet-d.net/tut_w/chap1.htm
 
Merci encore pour tes reponses et ta patience
@+

C'est le même problème avec les MFC, voire pire, il faut tout faire soi-même, et c'est d'ailleurs ce qu'est en train de faire dd92. Vu la propreté du code, qui est réellement objet et encapsulé, je pense que c'est plus facile d'écrire un widget pour Lgi qu'en MFC, parce que c'est du vrai C++, et non une surcouche d'un truc qui n'a jamais été pensé en objet.

Mais la différence c'est que t'as des sites comme codeproject ou codeguru qui regorgent de super controles, que tu as une très grosse communauté, des outils, des bouquins, etc... Les défenseurs des MFC te diront qu'une appli c'est pas qu'une IHM et que y'a des choses comme la sérialization, l'impression, l'aide intégrée, etc... qui sont des petits trucs à la con sur lequel tu peux passer beaucoup de temps si tu dois tout faire à la main. Sans parler des classes annexes genre socket, doc/view, etc... C'est mal fouttu certes, mais ça a le mérite d'exister.

Je sais bien et je suis d'accord. Simplement pour une pile TCP, il n'y a pas besoin des MFC, pour faire du Corba non plus. Pour l'impression, je ne connais pas, mais je suppose que c'est un composant indépendant, pour une aide en ligne potable, on peut aussi se passer des MFC, etc.  
Bref, ça ne me parait pas si bloquant que ça de se passer des MFC. Lgi intègre déjà pas mal de choses quand même. Il y a des sockets, du multithreading, de l'unicode, des arbres façon Explorateur windows, des événements, SMTP, un widget de recherche/remplacement, de manip de fichiers, des timers, des barres de progression, une classe d'édition de texte des sliders, une classe "system tray", etc.  
 
Toutes ces conneries, il faut se les palucher à la main avec les MFC, ou les récupérer sur le net et les adapter pour les faire fonctionner ensemble dans son appli : des journées voire des semaines entières de pur bonheur. Alors si dans Lgi il manque un contrôle, vu le temps gagné par ailleurs, ça ne me parait pas être une catastrophe.
Je ne dis pas qu'on réécrit Excel facilement avec une lib comme Lgi, mais dans la plupart des applis où l'IHM a une part importante, et si tu n'as pas besoin de choses purement Microsoft comme des ActiveX, cette librairie tient plutôt la route. De plus, c'est bien écrit, donc pour un débutant en C++, étudier le code de Lgi est très intéressant, contrairement aux MFC.
 
Sur son site, l'auteur donne des exemples d'applis non triviales réalisées avec le code source (un client FTP, un filemanager, un éditeur Hexa, un éditeur d'images photos, etc) dont une de qualité professionnelle (le client mail, qui n'a rien à envier à ce qui existe, sans le source, celui-là). Bon j'arrête la pub, mais les MFC, ça n'est vraiment pas intéressant à utiliser alors commencer à programmer avec ça, c'est vraiment ce que j'appelle du gâchis. Sans parler du fait que  ça n'est pas portable.

Ca me fait bizarre quand même de défendre les MFC, surtout que je connais mal la bête mais bon.
 

C'est ce qui distingue une lib graphique d'un framework. Dans un framework tu as tout ça : c'est le cas des MFC. Avec une lib on développe un bout d'application, avec un framework in fait une application tout entière.
 

CSocket, CWinThread, CTreeView, CFindReplaceDialog, CProgressCtrl, CFile, CRichEditCtrl, CSplitterWnd, ...
A ce niveau y'a pas bcp de libs qui peuvent rivaliser avec les MFC:
http://msdn.microsoft.com/library/ [...] _Chart.asp
Et y'a des classes tierces très très utiles, genre une grille (en ce qui me concerne c'est un critère important de jugement d'un toolkit : a-t-il une classe grille, ça dénote une certaine maturité selon moi). Un truc comme CRichEditCtrl c'est pas de la rigolade à coder, et pourtant c'est super utile.
 

c'est tout l'intérêt d'un framework face à 36 libs : une pour l'IHM, une pour le réseau, une pour le CORBA, une pour l'impression, etc...
 

Ca dépend du controle.  
 

Y'a beaucoup de libs qui tiennent la route. Lgi a l'air sympa, sans plus.

Je rajouterais que si à terme il veut chercher un job dans ce secteur, avoir taté (sérieusement) des MFC, c'est une référence. Tout le monde sait ce que c'est, tout le monde sait comment c'est foutu (pas besoin de dessin). Un gars qui sait se demerder avec MFC, il a forcément une certaine adaptabilité (en plus de l'experience d'une API Microsoft de bonne taille).

J'ai pas osé le mettre : MFC sur un CV c'est mieux. Déjà que j'avais mis wxWidgets on m'a dit "heu qu'est-ce que c'est ?".
Les libs de ce genre c'est bien par curiosité ou pour des petits projets persos.

C'est effectivement l'argument massue contre lequel je ne peux rien dire. L'employeur ne connaissant rien à part MFC, préfère faire perdre leur temps à ses ingénieurs. Tant qu'il  y a marqué Microsoft dessus, il ne risque rien (si ce n'est des retards monumentaux). De toutes les libs de taille importante existantes, c'est sans doute et de loin la moins productive (à part peut-être Motif). Personnellement, à part HelloWorld, je ne connais personne qui ne soit dégoûté après avoir utilisé les MFC de façon extensive pendant 2 ans. Donc voilà, si on veut être amené à faire du code chiant et moche dans sa vie professionnelle, si on veut passer autant de temps voire plus sur l'interface que sur le coeur de l'appli, oui, apprenons les MFC.
Bon j'arrête, c'est mon dernier post sur le sujet.

On s'est mal compris. Je te dit que face à Qt ou la VCL les MFC font pas le poids. Mais face à des libs genre ce que tu as cité, c'est une autre histoire.

Ok. Peace, brother