Re: ATL generates bad code for Firing events with [out] arguments
From: Alexander Nickolov (agnickolov_at_mvps.org)
Date: 08/07/04
- Next message: Alexander Nickolov: "Re: Can ATL source be "expanded"?"
- Previous message: Alexander Nickolov: "Re: Does an event sink need to support QI on the implemented interface, or just IDispatch?"
- In reply to: DavidB: "Re: ATL generates bad code for Firing events with [out] arguments"
- Next in thread: david hurkle: "Re: ATL generates bad code for Firing events with [out] arguments"
- Reply: david hurkle: "Re: ATL generates bad code for Firing events with [out] arguments"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 6 Aug 2004 17:31:42 -0700
This is not a bug, it's a missing feature. Consider it "by design".
BTW, VT_PI4 is not a valid vartype for a VARIANT. It's not
a question of not being supported - it's a question of being
conformant.
-- ===================================== Alexander Nickolov Microsoft MVP [VC], MCSD email: agnickolov@mvps.org MVP VC FAQ: http://www.mvps.org/vcfaq ===================================== "DavidB" <davidb3@Ihatespam.hurkle.com> wrote in message news:c3VQc.37018$K53.24219@news-server.bigpond.net.au... > Thanks! > > I'm sure what I need could easily be fixed. Operator=() already nearly > supports all the common types: the main exceptions are BOOL and CY. Using > non-supported symbols like VT_PI4 is just plain silly -- all that is needed > is to either define those symbols or stick to the VT_BYREF equivalents. > > I can fix the second by adding defines to my code, but the first means > changing MS source code, which is not a good thing. > > This is the second significant bug I've found (the other is LONGLONG to BSTR > conversion). Is there anywhere to notify these things so they get fixed some > time? Or will it just happen? > > DavidB > > "Alexander Nickolov" <agnickolov@mvps.org> wrote in message > news:eXelOX9eEHA.3348@TK2MSFTNGP12.phx.gbl... > > Yes, it's a known problem. The workaround is to type in > > the correct code. Note that CComVariant does not explicitly > > support VT_BYREF, which is the intrinsic problem why the > > wizard cannot support it either... Of course you can have > > a CComVariant initialized with VT_BYREF - it derives from > > VARIANT after all - but you have to deal with this manually. > > > > -- > > ===================================== > > Alexander Nickolov > > Microsoft MVP [VC], MCSD > > email: agnickolov@mvps.org > > MVP VC FAQ: http://www.mvps.org/vcfaq > > ===================================== > > > > "DavidB" <davidb3@Ihatespam.hurkle.com> wrote in message > > news:EjNQc.36437$K53.25720@news-server.bigpond.net.au... > > > ATL generates this heap of proxy code that allows you to conveniently > fire > > > events, rather than dealing with a raw IConnectionPointImpl. Very nice, > > when > > > it works. > > > > > > For procedures with [out] arguments, it generates bad initialisers for > > > CComVariant and generates codes using symbols like VT_PI4, which just > > don't > > > exist anywhere. I assume it's supposed to be (VT_I4 | VT_BYREF). > > > > > > Is this a known problem? Is there any way around it? > > > > > > DavidB > > > > > > > > > > > >
- Next message: Alexander Nickolov: "Re: Can ATL source be "expanded"?"
- Previous message: Alexander Nickolov: "Re: Does an event sink need to support QI on the implemented interface, or just IDispatch?"
- In reply to: DavidB: "Re: ATL generates bad code for Firing events with [out] arguments"
- Next in thread: david hurkle: "Re: ATL generates bad code for Firing events with [out] arguments"
- Reply: david hurkle: "Re: ATL generates bad code for Firing events with [out] arguments"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|