Home |
Search |
Today's Posts |
#1
Posted to microsoft.public.excel.programming
|
|||
|
|||
VBA, 'implements', and occasional failure to upcast. [probably messyVBA internal bug?]
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 :P) ) 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. |
#2
Posted to microsoft.public.excel.programming
|
|||
|
|||
VBA, 'implements', and occasional failure to upcast. [probably messy VBA internal bug?]
Have you tried cleaning the code with say Rob Bovey's Code Cleaner
http://www.appspro.com/Utilities/Utilities.htm Regards, Peter T "lab27" wrote in message ... 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 :P) ) 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. |
Reply |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Forum | |||
vlookup failure & ctrl-f failure? | Excel Discussion (Misc queries) | |||
Will pay for need help and occasional advise on using excel .... | Excel Programming | |||
Will pay for need help and occasional advise on using excel .... | Excel Worksheet Functions | |||
Curious - What is Implements used for | Excel Programming | |||
implements statement | Excel Programming |