Re: ATL generates bad code for Firing events with [out] arguments

From: david hurkle (david)
Date: 08/09/04 

Date: Mon, 9 Aug 2004 11:40:46 +1000

Now you've lost me.

Why is it "by design" to implement CComVariant operator=() for short,
short*, int, int*, LONG, LONGLONG*, float, float*, etc, etc and then
implement CY but not CY* and bool but not bool*? Just looks like an
oversight to me, easily remedied.

Yes, I know VT_PI4 is not valid, but it's what the Wizard generates. It's
perfectly obvious that what is needed is (VT_I4 | VT_BYREF). I can (and
have) fixed this by adding my own #define symbols for VT_PI4 and all the
others. It would be dead easy to fix, either in the Wizard or by adding
those symbols somewhere.

Both fixes are very, very easy, break nothing and have no down side. Don't
you agree?

DavidB

"Alexander Nickolov" <agnickolov@mvps.org> wrote in message
news:uKsPtXBfEHA.1604@TK2MSFTNGP11.phx.gbl...
> 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
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Relevant Pages