Title: RE: [windev] Enum/typedef namespace bug with #import
Because the client code is already written and I don't want to rewrite anything I don't have to. Having the wrapper classes available means I can get by with adapting existing code using only minor modifications. Besides, it's a compiler facility and should work.
 
Ciao,
Dee
-----Original Message-----
From: Tony Capps [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 23, 2003 3:52 AM
To: 'Dee Holtsclaw'; Windev; MSVC List
Subject: RE: [windev] Enum/typedef namespace bug with #import

If the control is yours, why not simply include the (midl generated) .h file.  I gave up using #import years ago (unless absolutely forced to).  It was just too much pain.

Tony

-----Original Message-----
From: Dee Holtsclaw [mailto:[EMAIL PROTECTED]]
Sent: 22 October 2003 16:05
To: Windev; MSVC List
Subject: [windev] Enum/typedef namespace bug with #import


I'm hoping someone out in the ether has a workaround for the enum #import bug in VC++6. I really need to keep the namespace to avoid naming clashes. In the process of all this, I've noticed the following:

1. If the typedef'd name is the same as the enumeration tag, it's referenced as 'enum X', otherwise just 'X'. In this later case, the compiler also gets lost and nukes upon encountering the first such unqualified (and thereby

unknown) type.

2. No enum tags or typedefs are qualified with the namespace tag but interfaces and coclasses are.

3. Manually editing the '.tli' causes the compiler to immediately regenerate it.

4. Adding a 'using namespace' fixes these errors but, regretfully, causes other problems (such as a multitude of 'ambiguous symbol' errors).

The control being #imported is completely under my control so I can muck with it's IDL as much as needed. It's been tested in VB and appears fine so I'd prefer not to break that but now I'm inserting it into the client apps and really need it to be done using the import rather than dragging the .h file. Manually editing the .tlh & .tli also needs to be avoided since I expect to be making modifications to the control as I integrate the client code (I could build a SED script but...).

<RANT>
On a personal note, I'd like to add that Microsoft must have been aware of this problem for years. If it's not been fixed (and I saw no indication of this last night on their web pages), the responsible party should be terminated with prejudice. There is NO excuse for this kind of sloppy product, especially after so many service packs. I was going to add a bug report but that part of the site was broken (surprise!). </RANT>

TIA!

Ciao,
Dee

--
Windev mailing list at [EMAIL PROTECTED]

Lost your password?  Need to unsubscribe or change your delivery options? 
Go to http://www.lesher.ws/mailman/listinfo/windev
--
Search the Windev Archives - www.windev.org

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ________________________________________________________________________



********************************************************
Attachments in this message have been swept
by NAIs TVD (version 4.0.4299) for the presence
of known computer viruses.
********************************************************

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

Reply via email to