WTL DDX with controls, really?
-
I just dont get it, WTL´s DDX facilities define a DDX_CONTROL() macro that take an ID for a control, and an object to attach it to. However, if i do something like this:
BEGIN_DDX_MAP(CMyDlg)DDX_CONTROL(IDC_MYEDIT, m_cEdit)END_DDX_MAP()where IDC_MYEDIT is (of course) and edit box on my dialog, and m_cEdit is a member variable of type CEdit, then this class wont complie! because SubClassWindow() (witch is called by ddx), is NOT a member of CEdit!, i suppose i could write a class derived from CWindowImpl and pass objects of it to DDX_CONTROL(), but i assumed that the whole purpuse of DDX was to make mi life easyer not harder!, it would be FAR more trouble to write a class for EVERY type of control i want to use DDX with, than just create control class member variables on my dialog, and just Attach() them to the "physical" controls on the dialog, early on my OnInitDialog() function! Im i missing something??? what is the purpuse of DDX_CONTROL() if it CANT be used "normally" with controls? -
I just dont get it, WTL´s DDX facilities define a DDX_CONTROL() macro that take an ID for a control, and an object to attach it to. However, if i do something like this:
BEGIN_DDX_MAP(CMyDlg)DDX_CONTROL(IDC_MYEDIT, m_cEdit)END_DDX_MAP()where IDC_MYEDIT is (of course) and edit box on my dialog, and m_cEdit is a member variable of type CEdit, then this class wont complie! because SubClassWindow() (witch is called by ddx), is NOT a member of CEdit!, i suppose i could write a class derived from CWindowImpl and pass objects of it to DDX_CONTROL(), but i assumed that the whole purpuse of DDX was to make mi life easyer not harder!, it would be FAR more trouble to write a class for EVERY type of control i want to use DDX with, than just create control class member variables on my dialog, and just Attach() them to the "physical" controls on the dialog, early on my OnInitDialog() function! Im i missing something??? what is the purpuse of DDX_CONTROL() if it CANT be used "normally" with controls?DDX_CONTROLrequires a class with a message map, that is, aCWindowImpl-derived class. The control wrappers are allCWindow-derived, so they can't be used with DDX. You need to do something like:class CEditImpl : public CWindowImpl<CEditImpl, CEdit>
{ public: DECLARE_EMPTY_MSG_MAP() };and use
CEditImplfor yourm_cEditvariable. Yes, it's a hassle. :( --Mike-- Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber Ericahist updated Aug 30! -
I just dont get it, WTL´s DDX facilities define a DDX_CONTROL() macro that take an ID for a control, and an object to attach it to. However, if i do something like this:
BEGIN_DDX_MAP(CMyDlg)DDX_CONTROL(IDC_MYEDIT, m_cEdit)END_DDX_MAP()where IDC_MYEDIT is (of course) and edit box on my dialog, and m_cEdit is a member variable of type CEdit, then this class wont complie! because SubClassWindow() (witch is called by ddx), is NOT a member of CEdit!, i suppose i could write a class derived from CWindowImpl and pass objects of it to DDX_CONTROL(), but i assumed that the whole purpuse of DDX was to make mi life easyer not harder!, it would be FAR more trouble to write a class for EVERY type of control i want to use DDX with, than just create control class member variables on my dialog, and just Attach() them to the "physical" controls on the dialog, early on my OnInitDialog() function! Im i missing something??? what is the purpuse of DDX_CONTROL() if it CANT be used "normally" with controls? -
I just dont get it, WTL´s DDX facilities define a DDX_CONTROL() macro that take an ID for a control, and an object to attach it to. However, if i do something like this:
BEGIN_DDX_MAP(CMyDlg)DDX_CONTROL(IDC_MYEDIT, m_cEdit)END_DDX_MAP()where IDC_MYEDIT is (of course) and edit box on my dialog, and m_cEdit is a member variable of type CEdit, then this class wont complie! because SubClassWindow() (witch is called by ddx), is NOT a member of CEdit!, i suppose i could write a class derived from CWindowImpl and pass objects of it to DDX_CONTROL(), but i assumed that the whole purpuse of DDX was to make mi life easyer not harder!, it would be FAR more trouble to write a class for EVERY type of control i want to use DDX with, than just create control class member variables on my dialog, and just Attach() them to the "physical" controls on the dialog, early on my OnInitDialog() function! Im i missing something??? what is the purpuse of DDX_CONTROL() if it CANT be used "normally" with controls?Thanks for your answers Michael & Li, i know i need a CWindowImpl derived class to do the job, but what i mean is, i dont understand the phylosofy (pardon my spelling if wrong, english is not my native language) of the creators of WTL in this issue, because what DDX_CONTROL is supposed to do, its easier done -without- DDX_CONTROL!. I find it "harder" (more time consuming) to have to write a class(even a small one) for every type of control i want to use, include the proper headers on my dialog class, add the ddx map entry, etc., than just declaring a member variable like CEdit m_MyEdit, or CListViewCtrl m_MyList, etc. and just attaching it via their Attach() method on my dialog´s OnInitDialog(), my point is ¿whats the design concept behind DDX_CONTROL? or in other words, ¿when do you actually use DDX_CONTROL because its easier to do so?
-
Thanks for your answers Michael & Li, i know i need a CWindowImpl derived class to do the job, but what i mean is, i dont understand the phylosofy (pardon my spelling if wrong, english is not my native language) of the creators of WTL in this issue, because what DDX_CONTROL is supposed to do, its easier done -without- DDX_CONTROL!. I find it "harder" (more time consuming) to have to write a class(even a small one) for every type of control i want to use, include the proper headers on my dialog class, add the ddx map entry, etc., than just declaring a member variable like CEdit m_MyEdit, or CListViewCtrl m_MyList, etc. and just attaching it via their Attach() method on my dialog´s OnInitDialog(), my point is ¿whats the design concept behind DDX_CONTROL? or in other words, ¿when do you actually use DDX_CONTROL because its easier to do so?
Ernesto D. wrote: declaring a member variable like CEdit m_MyEdit, or CListViewCtrl m_MyList, etc. and just attaching it via their Attach() method on my dialog´s OnInitDialog(), I would rather have a map in the header file, which is easy to find and edit, than calls to
Attach(GetDlgItem(IDC_FOO))over and over. The code to hook up all the controls at once with DDX is just one line,DoDataExchange(false);UsingAttach()will work just as well, if that's the way you prefer. --Mike-- Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber Ericahist updated Aug 30! -
I just dont get it, WTL´s DDX facilities define a DDX_CONTROL() macro that take an ID for a control, and an object to attach it to. However, if i do something like this:
BEGIN_DDX_MAP(CMyDlg)DDX_CONTROL(IDC_MYEDIT, m_cEdit)END_DDX_MAP()where IDC_MYEDIT is (of course) and edit box on my dialog, and m_cEdit is a member variable of type CEdit, then this class wont complie! because SubClassWindow() (witch is called by ddx), is NOT a member of CEdit!, i suppose i could write a class derived from CWindowImpl and pass objects of it to DDX_CONTROL(), but i assumed that the whole purpuse of DDX was to make mi life easyer not harder!, it would be FAR more trouble to write a class for EVERY type of control i want to use DDX with, than just create control class member variables on my dialog, and just Attach() them to the "physical" controls on the dialog, early on my OnInitDialog() function! Im i missing something??? what is the purpuse of DDX_CONTROL() if it CANT be used "normally" with controls?We converted some of our small-size projects to WTL previously. Now we are skeptical putting more effort on WTL, as Microsoft now seems don't even want to improve MFC/ATL beside keep pushing (implicitly forcing...) .nut for C/C++, which in our view, would eventually kill C/C++ on Windows. :mad: Anyone with any idea is WTL dead? :((
-
We converted some of our small-size projects to WTL previously. Now we are skeptical putting more effort on WTL, as Microsoft now seems don't even want to improve MFC/ATL beside keep pushing (implicitly forcing...) .nut for C/C++, which in our view, would eventually kill C/C++ on Windows. :mad: Anyone with any idea is WTL dead? :((
There was some talk of it going open-source, which would probably be enough to kill it effectively :laugh: but Nenad is supposedly working on 7.1 or 8, partly to improve the support out of the box for VS.NET 2003, which otherwise requires some tweaks. Steve S
-
There was some talk of it going open-source, which would probably be enough to kill it effectively :laugh: but Nenad is supposedly working on 7.1 or 8, partly to improve the support out of the box for VS.NET 2003, which otherwise requires some tweaks. Steve S
Steve S wrote: which otherwise requires some tweaks. Some? :rolleyes: COM Out-proc server are easy to fix, but COM DLL's and WTL is a hassle. I ended up writing an adapter class for the COM Module stuff. :sigh: -- You still have your old friend Zoidberg. You all have Zoidberg!
-
Steve S wrote: which otherwise requires some tweaks. Some? :rolleyes: COM Out-proc server are easy to fix, but COM DLL's and WTL is a hassle. I ended up writing an adapter class for the COM Module stuff. :sigh: -- You still have your old friend Zoidberg. You all have Zoidberg!