L
lab27
Hi -
I've occasionally observed the following behaviour, and wonder if
anyone has a /proper/ explanation for it....
(I'm currently using excel 2003, but I've seen this on 2000)
(I'm not asking about upcasting and implements in general - this stuff
works fine - & I haven't provided any code samples because this stuff
works perfectly almost all the time, and then code which is working
will fail as described below.... (and this is NOT related to external
factors
) )
base class clsB
several derived classes ( 'implementing' clsB ) clsD1, clsD2, clsD3,
of varying complexity - some with members, some with constructors (ok,
cls_initialise ;P ).
Occasionally, perfectly sensible upcasts which were working fail with
"type mismatch" (and continue to fail even when the process is
restarted). (without having edited any code for the above classes).
dim b as clsB
set b = new clsD1 <-- fails with "type mismatch", really should work,
and has been working - no changes to B/D1
Not all derived classes fail to upcast, the ones without initialisers
worked... (!)
The last time this happened, forcing a recompile by editing an
unrelated .bas and recompiling the vba did not fix the issue, nor did
just tickling one of the affected classes and forcing a recompile, /
however/ (and this is basically voodoo) reordering the functions in
one of the affected classes to put the base functions first fixed it.
(there's no reason why this should have....)
Does anyone have any documentation for what's going on here? My guess
(and this REALLY is guessing) is that VBA probably behaves very much
like com here (it would have to, for these objects to be passed as
IUnknown) - allocating IIDs on the fly for classes (and 1:1
class:interface), at some point the IID for the base class(/interface)
has been regenerated (given that it's not actually important to keep
it fixed), and VBA has failed to propagate this change to the cached
pcode for the derived classes.
However, I can't find any good internal documentation to back up this
utterly vaporous guesswork
- and I'm hoping someone out there can
point me at some to preserve my peace of mind.
Cheers,
Lee.
I've occasionally observed the following behaviour, and wonder if
anyone has a /proper/ explanation for it....
(I'm currently using excel 2003, but I've seen this on 2000)
(I'm not asking about upcasting and implements in general - this stuff
works fine - & I haven't provided any code samples because this stuff
works perfectly almost all the time, and then code which is working
will fail as described below.... (and this is NOT related to external
factors
) )base class clsB
several derived classes ( 'implementing' clsB ) clsD1, clsD2, clsD3,
of varying complexity - some with members, some with constructors (ok,
cls_initialise ;P ).
Occasionally, perfectly sensible upcasts which were working fail with
"type mismatch" (and continue to fail even when the process is
restarted). (without having edited any code for the above classes).
dim b as clsB
set b = new clsD1 <-- fails with "type mismatch", really should work,
and has been working - no changes to B/D1
Not all derived classes fail to upcast, the ones without initialisers
worked... (!)
The last time this happened, forcing a recompile by editing an
unrelated .bas and recompiling the vba did not fix the issue, nor did
just tickling one of the affected classes and forcing a recompile, /
however/ (and this is basically voodoo) reordering the functions in
one of the affected classes to put the base functions first fixed it.
(there's no reason why this should have....)
Does anyone have any documentation for what's going on here? My guess
(and this REALLY is guessing) is that VBA probably behaves very much
like com here (it would have to, for these objects to be passed as
IUnknown) - allocating IIDs on the fly for classes (and 1:1
class:interface), at some point the IID for the base class(/interface)
has been regenerated (given that it's not actually important to keep
it fixed), and VBA has failed to propagate this change to the cached
pcode for the derived classes.
However, I can't find any good internal documentation to back up this
utterly vaporous guesswork
- and I'm hoping someone out there canpoint me at some to preserve my peace of mind.
Cheers,
Lee.