| T O P I C R E V I E W |
| 191919 |
Posted - May 28 2010 : 05:28:20 AM
In an ATL/WTL project (without MFC support), if I use a WTL class which
(1) is enabled by "using namespace WTL;"
(2) has an MFC homonymic sibling.
VA failed to recognized it as a WTL class (it is regarded as an MFC class).
WTL::CMenu::GetSubMenu returns a CMenu object, but MFC::CMenu::GetSubMenu returns a CMenu* object.
|
| 5 L A T E S T R E P L I E S (Newest First) |
| accord |
Posted - Jun 16 2010 : 2:05:23 PM
Tricky 
I have added your thoughts to the case.
For now, I can offer a little better workaround: if you go
VA Options -> Projects -> C/C++ Directories
and switch the platform to custom you will be able to remove the ...atlmfc\\include dir without affecting the compiler. |
| drac |
Posted - Jun 16 2010 : 05:09:50 AM
I second the request.
I've tried putting WTL include directory as first include in system
include directories, but VAX still picks up MFC headers.
VAX should at least respect the order of the system include headers.
One workaround is to use Visual C++'s intellisense (F12) to go to
the header file and hunt for the method.
Edit: removing $(VCInstallDir)atlmfc\\include made VAX to properly
recognize WTL headers, but then the project didn't compile anymore 
Going further I've put back $(VCInstallDir)atlmfc\\include and removed
all "afx*" files from $(VCInstallDir)atlmfc\\include. This fixed VAX
WTL intellisense problem, and the WTL project compiled successfully
afterwards.
Please fix this, I don't think removing MFC is a workaround one can
suggest to customers.
|
| accord |
Posted - Jun 14 2010 : 12:30:59 PM
I've added your vote to the case. |
| barto |
Posted - Jun 13 2010 : 09:46:24 AM
I second the request. Is there an update already? The current behavior is driving me nuts.
My test-case is currently a member variable of type "CTabView", and when trying to get intellisense "m_tab." it lists all the members of MFC's CTabView and not WTL's...
VA_X.dll file version 10.6.1823.0 built 2010.05.06
|
| accord |
Posted - May 28 2010 : 1:05:00 PM
We are planning to improve this at some point:
case=6948 |
