Newsgroup: it.comp.programmare.win32
Titolo: ListView-ListCtrl, TreeView-TreeCtrl

Ciao a tutti.
Secondo voi c'e' una ragione particolare per cui gli oggetti CTreeView e
CListView non hanno una variabile membro che faccia riferimento al relativo
CTreeCtrl o CListCtrl?
Entrambi hanno una funzione del tipo GetTreeCtrl o GetListCtrl, ma non
capisco perche' non inserire un membro che permetta di eccedere direttamente
all'oggetto senza dover richiamare ogni volta la funzione relativa.
E' banale aggiungere una variabile membro alla mia classe derivata, ma dal
momento che non e' stato fatto mi chiedo se c'e' una ragione particolare...
Grazie, ciao e buon lavoro, Davide.
---------------------
Davide Piras
NRC - CNRC - CANADA
davide...@nrc.ca
---------------------
-- 
Posted from 
origin.vit.iit.nrc.ca
 [132.246.41.10] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG


E' una pura scelta progettuale, alquanto interessante direi.
In effetti il CListView non contiene il list-ctrl ma è il list-ctrl.
Se hai notato com'è implementata la funzione GetListCtrl (file afxcview.inl)
...
_AFXCVIEW_INLINE CListCtrl& CListView::GetListCtrl() const
 { return *(CListCtrl*)this; }
come puoi vedere con questo tipo di scelta non è necessaria alcun membro.
Lo stesso discorso è valido per il CTreeView
Porlock.

 { return *(CListCtrl*)this; }
Incuriosito da questa cosa, ho dato un occhio anche io ai sorgenti di MFC.
CListView non e` derivata da CListCtrl, bensi` da CCtrlView che a sua volta
deriva direttamente da CView. Quindi non mi e` chiaro come faccia a
funzionare il cast qui sopra, dato che non e` nemmeno stato definito
l'operatore (CListCtrl *) in modo che restituisca il puntatore giusto.
Come funziona questa cosa?
---
Bye! Lorenzo Lutti
http://antani.virtualave.net/

 Come funziona questa cosa?
Credo si possa considerare cattiva programmazione orientata gli oggetti.
Questo è il costruttore del CListView
_AFXCVIEW_INLINE CListView::CListView() : CCtrlView(WC_LISTVIEW,
 AFX_WS_DEFAULT_VIEW)
 { }
e questa è la PreCreateWindow del CCtrlView
BOOL CCtrlView::PreCreateWindow(CREATESTRUCT& cs)
{
 ASSERT(cs.lpszClass == NULL);
 cs.lpszClass = m_strClass;
 // initialize common controls
 VERIFY(AfxDeferRegisterClass(AFX_WNDCOMMCTLS_REG));
 AfxDeferRegisterClass(AFX_WNDCOMMCTLSNEW_REG);
 // map default CView style to default style
 // WS_BORDER is insignificant
 if ((cs.style | WS_BORDER) == AFX_WS_DEFAULT_VIEW)
  cs.style = m_dwDefaultStyle & (cs.style | ~WS_BORDER);
 return CView::PreCreateWindow(cs);
}
In pratica viene costruito un controllo di tipo list-ctrl ma invece di
utilizzare una wrapper class com CListCtrl viene utilizzata la CListView che
deriva da CCtrlView, ovviamente perché occorre la gestione dell'architettura
frame-view-document.
Avrebbero anche dovuto implementare nella classe CListView tutti i metodi
presenti nella classe CListCtrl.
Cosa che non hanno fatto, hanno semplicemente fornito il metodo
GetListCtrl() che realizza un tipico cast c-style.
Dal punto di vista della programmazione orientata agli oggetti è un oscenità
poiché gerarchicamente le due classi non sono in linea di discendenza.
Un'operazione del genere però funziona poiché tutti i metodi del list-ctrl
sono semplicemente delle SendMessage all'handle della finestra (m_hWnd).
Questo handle proviene dalla classe padre CWnd comune sia a CListView che a
CListCtrl e quindi non si riscontra nessun problema nell'acceso al membro
m_hWnd.
E' una soluzione interessante ma veramente poco ortodossa !
Porlock.
Ciao

 presenti nella classe CListCtrl.
Era sufficiente derivare CListView sia da CView che da CListCtrl, pero`
sembra che il divieto di usare l'ereditarieta` multipla sia un "dogma" per i
progettisti di MFC.
