Class does not support automation...
| Author |
Message |
|
Nick Dawso
#1 / 9
|
 Class does not support automation... Hi, I have two projects in VB6 - one .exe and one active x dll.
Lets say I make a change in the DLL, and re-compile it. Change does NOT
break binary compatibility in any way.
So, in theory, I should still be able to double click my .exe and it would
run fine.
However- It tells me that "Class does not support automation or expected
interface"
So, I load the .exe up in the IDE and Ctrl-F5 it and it runs fine. Then,
re-make the .EXE and I can now double click it and it runs fine.
Any ideas what is going on here?! - It makes debugging very slow and
painful!
Thanks
Nick
|
| Sat, 24 Jan 2004 16:49:45 GMT |
|
 |
|
Kip Fryma
#2 / 9
|
Class does not support automation... Yup.. exact same problem I have with my MTS componants, and nobody here has been able to help me.. hopefully, someone can provide some more insight..
BTW I have not had that problem with non MTS componants...
Quote: > Hi, > I have two projects in VB6 - one .exe and one active x dll.
> Lets say I make a change in the DLL, and re-compile it. Change does NOT
> break binary compatibility in any way.
> So, in theory, I should still be able to double click my .exe and it would
> run fine.
> However- It tells me that "Class does not support automation or expected
> interface"
> So, I load the .exe up in the IDE and Ctrl-F5 it and it runs fine. Then,
> re-make the .EXE and I can now double click it and it runs fine.
> Any ideas what is going on here?! - It makes debugging very slow and
> painful!
> Thanks
> Nick
|
| Sat, 24 Jan 2004 21:56:00 GMT |
|
|
|
Ken Halte
#3 / 9
|
Class does not support automation... Sounds like you *are* breaking compatibility. If you create a component and compile it against another version of that component, it'll be compatible with apps that use the one that you're compiling against... but.. if you add an interface (public method / property), you'll get into trouble if the one you're compiling against doesn't contain that new interface.. sounds confusing but... V1.00 has a method called "Frog"
you find a bug in V1.00, fix it and it's now V1.10
V1.10 points to V1.00 while compiling so any app that needs "Frog" will
still work
the new exe you just compiled will still work...
V1.20 has a method called "Dog".
V1.20 points to V1.00 while compiling so any app that needs "Frog" will
still work
the new exe you just compiled will still work...
you find a bug in V1.20, fix it and it's now V1.21
V1.21 points to V1.00 while compiling so any app that needs "Frog" will
still work
the exe that worked with V1.20 now bombs..
This is because you told VB to be compatible with V1.00 that contains only
the "Frog" method. VB generates new interface information for the "Dog"
method each time you compile... no apps that contain "Dog" will work because
the interface info is lost. You'd need to point to V1.20 while compiling
because it has all public interfaces defined.
To make a short story long, each time you add a new public interface, you'll
need to update the binary compatibility model you're pointing to at compile
time..
Quote: > Hi, > I have two projects in VB6 - one .exe and one active x dll.
> Lets say I make a change in the DLL, and re-compile it. Change does NOT
> break binary compatibility in any way.
> So, in theory, I should still be able to double click my .exe and it would
> run fine.
> However- It tells me that "Class does not support automation or expected
> interface"
> So, I load the .exe up in the IDE and Ctrl-F5 it and it runs fine. Then,
> re-make the .EXE and I can now double click it and it runs fine.
> Any ideas what is going on here?! - It makes debugging very slow and
> painful!
> Thanks
> Nick
|
| Sat, 24 Jan 2004 22:41:37 GMT |
|
|
|
Ken Halte
#4 / 9
|
Class does not support automation... Forgot to mention... VB won't and can't warn you about this type of compatibility problem... because, as far as VB's concerned, it's doing its job by remaining compatible with the model you're pointing to.
Quote: > Sounds like you *are* breaking compatibility. If you create a component and > compile it against another version of that component, it'll be compatible > with apps that use the one that you're compiling against... but.. if you add > an interface (public method / property), you'll get into trouble if the one > you're compiling against doesn't contain that new interface.. sounds > confusing but... > V1.00 has a method called "Frog"
> you find a bug in V1.00, fix it and it's now V1.10
> V1.10 points to V1.00 while compiling so any app that needs "Frog" will
> still work
> the new exe you just compiled will still work...
> V1.20 has a method called "Dog".
> V1.20 points to V1.00 while compiling so any app that needs "Frog" will
> still work
> the new exe you just compiled will still work...
> you find a bug in V1.20, fix it and it's now V1.21
> V1.21 points to V1.00 while compiling so any app that needs "Frog" will
> still work
> the exe that worked with V1.20 now bombs..
> This is because you told VB to be compatible with V1.00 that contains only
> the "Frog" method. VB generates new interface information for the "Dog"
> method each time you compile... no apps that contain "Dog" will work
because
> the interface info is lost. You'd need to point to V1.20 while compiling
> because it has all public interfaces defined.
> To make a short story long, each time you add a new public interface,
you'll
> need to update the binary compatibility model you're pointing to at
compile
> time..
> > Hi,
> > I have two projects in VB6 - one .exe and one active x dll.
> > Lets say I make a change in the DLL, and re-compile it. Change does NOT
> > break binary compatibility in any way.
> > So, in theory, I should still be able to double click my .exe and it
would
> > run fine.
> > However- It tells me that "Class does not support automation or expected
> > interface"
> > So, I load the .exe up in the IDE and Ctrl-F5 it and it runs fine. Then,
> > re-make the .EXE and I can now double click it and it runs fine.
> > Any ideas what is going on here?! - It makes debugging very slow and
> > painful!
> > Thanks
> > Nick
|
| Sat, 24 Jan 2004 22:49:50 GMT |
|
|
|
Nick Dawso
#5 / 9
|
Class does not support automation... I'll certainly look at your scenario, because, as you say VB doesn't warn you so I assumed (Maybe wrongly) that I wasn't breaking compatibility. Thanks for your response
Quote: > Forgot to mention... VB won't and can't warn you about this type of > compatibility problem... because, as far as VB's concerned, it's doing its > job by remaining compatible with the model you're pointing to.
> > Sounds like you *are* breaking compatibility. If you create a component
> and
> > compile it against another version of that component, it'll be
compatible
> > with apps that use the one that you're compiling against... but.. if you
> add
> > an interface (public method / property), you'll get into trouble if the
> one
> > you're compiling against doesn't contain that new interface.. sounds
> > confusing but...
> > V1.00 has a method called "Frog"
> > you find a bug in V1.00, fix it and it's now V1.10
> > V1.10 points to V1.00 while compiling so any app that needs "Frog" will
> > still work
> > the new exe you just compiled will still work...
> > V1.20 has a method called "Dog".
> > V1.20 points to V1.00 while compiling so any app that needs "Frog" will
> > still work
> > the new exe you just compiled will still work...
> > you find a bug in V1.20, fix it and it's now V1.21
> > V1.21 points to V1.00 while compiling so any app that needs "Frog" will
> > still work
> > the exe that worked with V1.20 now bombs..
> > This is because you told VB to be compatible with V1.00 that contains
only
> > the "Frog" method. VB generates new interface information for the "Dog"
> > method each time you compile... no apps that contain "Dog" will work
> because
> > the interface info is lost. You'd need to point to V1.20 while compiling
> > because it has all public interfaces defined.
> > To make a short story long, each time you add a new public interface,
> you'll
> > need to update the binary compatibility model you're pointing to at
> compile
> > time..
> > > Hi,
> > > I have two projects in VB6 - one .exe and one active x dll.
> > > Lets say I make a change in the DLL, and re-compile it. Change does
NOT
> > > break binary compatibility in any way.
> > > So, in theory, I should still be able to double click my .exe and it
> would
> > > run fine.
> > > However- It tells me that "Class does not support automation or
expected
> > > interface"
> > > So, I load the .exe up in the IDE and Ctrl-F5 it and it runs fine.
Then,
> > > re-make the .EXE and I can now double click it and it runs fine.
> > > Any ideas what is going on here?! - It makes debugging very slow and
> > > painful!
> > > Thanks
> > > Nick
|
| Sat, 24 Jan 2004 23:04:26 GMT |
|
|
|
Kip Fryma
#6 / 9
|
Class does not support automation... Is it reccomended to compile over top of your binary compatability file? Therefore the latest compile is always compatable with the compile previous to it.... I am guessing yes because I have used this method... of course always
backing up the compiled version.....
Quote: > Forgot to mention... VB won't and can't warn you about this type of > compatibility problem... because, as far as VB's concerned, it's doing its > job by remaining compatible with the model you're pointing to.
> > Sounds like you *are* breaking compatibility. If you create a component
> and
> > compile it against another version of that component, it'll be
compatible
> > with apps that use the one that you're compiling against... but.. if you
> add
> > an interface (public method / property), you'll get into trouble if the
> one
> > you're compiling against doesn't contain that new interface.. sounds
> > confusing but...
> > V1.00 has a method called "Frog"
> > you find a bug in V1.00, fix it and it's now V1.10
> > V1.10 points to V1.00 while compiling so any app that needs "Frog" will
> > still work
> > the new exe you just compiled will still work...
> > V1.20 has a method called "Dog".
> > V1.20 points to V1.00 while compiling so any app that needs "Frog" will
> > still work
> > the new exe you just compiled will still work...
> > you find a bug in V1.20, fix it and it's now V1.21
> > V1.21 points to V1.00 while compiling so any app that needs "Frog" will
> > still work
> > the exe that worked with V1.20 now bombs..
> > This is because you told VB to be compatible with V1.00 that contains
only
> > the "Frog" method. VB generates new interface information for the "Dog"
> > method each time you compile... no apps that contain "Dog" will work
> because
> > the interface info is lost. You'd need to point to V1.20 while compiling
> > because it has all public interfaces defined.
> > To make a short story long, each time you add a new public interface,
> you'll
> > need to update the binary compatibility model you're pointing to at
> compile
> > time..
> > > Hi,
> > > I have two projects in VB6 - one .exe and one active x dll.
> > > Lets say I make a change in the DLL, and re-compile it. Change does
NOT
> > > break binary compatibility in any way.
> > > So, in theory, I should still be able to double click my .exe and it
> would
> > > run fine.
> > > However- It tells me that "Class does not support automation or
expected
> > > interface"
> > > So, I load the .exe up in the IDE and Ctrl-F5 it and it runs fine.
Then,
> > > re-make the .EXE and I can now double click it and it runs fine.
> > > Any ideas what is going on here?! - It makes debugging very slow and
> > > painful!
> > > Thanks
> > > Nick
|
| Sun, 25 Jan 2004 01:25:18 GMT |
|
|
|
Trevor Benedict
#7 / 9
|
Class does not support automation...
If you need to go a lot of testing, then recompiling the Exe could be a lot of work. If there's not much change in the Exe then you can try using the Createobject instead of Early binding. This way you'll not have to recompile the dll allthough intellisense will not come into practise here.
Trevor Benedict R
Software Consultant
Western Digital Malaysia Sdn Bhd
Hi,
I have two projects in VB6 - one .exe and one active x dll.
Lets say I make a change in the DLL, and re-compile it. Change does NOT
break binary compatibility in any way.
So, in theory, I should still be able to double click my .exe and it would
run fine.
However- It tells me that "Class does not support automation or expected
interface"
So, I load the .exe up in the IDE and Ctrl-F5 it and it runs fine. Then,
re-make the .EXE and I can now double click it and it runs fine.
Any ideas what is going on here?! - It makes debugging very slow and
painful!
Thanks
Nick
|
| Sun, 25 Jan 2004 17:28:00 GMT |
|
|
|
Ken Halte
#8 / 9
|
Class does not support automation... Might not hurt anything as long as you're backing up the original.. but in general, you'd try to avoid that by creating a subfolder called "Release" or "Compat" or similar and placing your model there. Some even rename the model to something like.. MyDll.cmp to make sure it's not over-written. I like to keep several models... when we ship a dll, I like to take a copy of that and name it something similar to "Released V1.xx.xx MyDLL.dll" and then point to that while compiling.. even though I've never needed to back up to a previous model for any reason, I can if I want... hard drive space is cheap these days ;) 15gigs $49.00.. wow! I paid that much for my first box of 10 single sided - single density floppies.. and even then, that's only 1800k of storage. Now I feel old.. I'm going to go take a nap.
Quote: > Is it reccomended to compile over top of your binary compatability file? > Therefore the latest compile is always compatable with the compile previous > to it.... > I am guessing yes because I have used this method... of course always
> backing up the compiled version.....
> > Forgot to mention... VB won't and can't warn you about this type of
> > compatibility problem... because, as far as VB's concerned, it's doing
its
> > job by remaining compatible with the model you're pointing to.
> > > Sounds like you *are* breaking compatibility. If you create a
component
> > and
> > > compile it against another version of that component, it'll be
> compatible
> > > with apps that use the one that you're compiling against... but.. if
you
> > add
> > > an interface (public method / property), you'll get into trouble if
the
> > one
> > > you're compiling against doesn't contain that new interface.. sounds
> > > confusing but...
> > > V1.00 has a method called "Frog"
> > > you find a bug in V1.00, fix it and it's now V1.10
> > > V1.10 points to V1.00 while compiling so any app that needs "Frog"
will
> > > still work
> > > the new exe you just compiled will still work...
> > > V1.20 has a method called "Dog".
> > > V1.20 points to V1.00 while compiling so any app that needs "Frog"
will
> > > still work
> > > the new exe you just compiled will still work...
> > > you find a bug in V1.20, fix it and it's now V1.21
> > > V1.21 points to V1.00 while compiling so any app that needs "Frog"
will
> > > still work
> > > the exe that worked with V1.20 now bombs..
> > > This is because you told VB to be compatible with V1.00 that contains
> only
> > > the "Frog" method. VB generates new interface information for the
"Dog"
> > > method each time you compile... no apps that contain "Dog" will work
> > because
> > > the interface info is lost. You'd need to point to V1.20 while
compiling
> > > because it has all public interfaces defined.
> > > To make a short story long, each time you add a new public interface,
> > you'll
> > > need to update the binary compatibility model you're pointing to at
> > compile
> > > time..
> > > > Hi,
> > > > I have two projects in VB6 - one .exe and one active x dll.
> > > > Lets say I make a change in the DLL, and re-compile it. Change does
> NOT
> > > > break binary compatibility in any way.
> > > > So, in theory, I should still be able to double click my .exe and it
> > would
> > > > run fine.
> > > > However- It tells me that "Class does not support automation or
> expected
> > > > interface"
> > > > So, I load the .exe up in the IDE and Ctrl-F5 it and it runs fine.
> Then,
> > > > re-make the .EXE and I can now double click it and it runs fine.
> > > > Any ideas what is going on here?! - It makes debugging very slow and
> > > > painful!
> > > > Thanks
> > > > Nick
|
| Mon, 26 Jan 2004 01:50:37 GMT |
|
|
|
Kip Fryma
#9 / 9
|
Class does not support automation... I think this is how I will do it.. Just over writing the original binar compatable compile. It is redundant and therefore I won't accidently do a compile against a version of my componant that is 4 revisions back.... I back up to CD frequently so I can't see this being a big big problem..
$49.99 is very cheap, but I need to buy a desktop for it.. I love my laptop
right now though
I feel so young
Quote: > Might not hurt anything as long as you're backing up the original.. but in > general, you'd try to avoid that by creating a subfolder called "Release" or > "Compat" or similar and placing your model there. Some even rename the model > to something like.. MyDll.cmp to make sure it's not over-written. I like to > keep several models... when we ship a dll, I like to take a copy of that and > name it something similar to "Released V1.xx.xx MyDLL.dll" and then point to > that while compiling.. even though I've never needed to back up to a > previous model for any reason, I can if I want... hard drive space is cheap > these days ;) 15gigs $49.00.. wow! I paid that much for my first box of 10 > single sided - single density floppies.. and even then, that's only 1800k of > storage. Now I feel old.. I'm going to go take a nap.
> > Is it reccomended to compile over top of your binary compatability file?
> > Therefore the latest compile is always compatable with the compile
> previous
> > to it....
> > I am guessing yes because I have used this method... of course always
> > backing up the compiled version.....
> > > Forgot to mention... VB won't and can't warn you about this type of
> > > compatibility problem... because, as far as VB's concerned, it's doing
> its
> > > job by remaining compatible with the model you're pointing to.
> > > > Sounds like you *are* breaking compatibility. If you create a
> component
> > > and
> > > > compile it against another version of that component, it'll be
> > compatible
> > > > with apps that use the one that you're compiling against... but.. if
> you
> > > add
> > > > an interface (public method / property), you'll get into trouble if
> the
> > > one
> > > > you're compiling against doesn't contain that new interface.. sounds
> > > > confusing but...
> > > > V1.00 has a method called "Frog"
> > > > you find a bug in V1.00, fix it and it's now V1.10
> > > > V1.10 points to V1.00 while compiling so any app that needs "Frog"
> will
> > > > still work
> > > > the new exe you just compiled will still work...
> > > > V1.20 has a method called "Dog".
> > > > V1.20 points to V1.00 while compiling so any app that needs "Frog"
> will
> > > > still work
> > > > the new exe you just compiled will still work...
> > > > you find a bug in V1.20, fix it and it's now V1.21
> > > > V1.21 points to V1.00 while compiling so any app that needs "Frog"
> will
> > > > still work
> > > > the exe that worked with V1.20 now bombs..
> > > > This is because you told VB to be compatible with V1.00 that
contains
> > only
> > > > the "Frog" method. VB generates new interface information for the
> "Dog"
> > > > method each time you compile... no apps that contain "Dog" will work
> > > because
> > > > the interface info is lost. You'd need to point to V1.20 while
> compiling
> > > > because it has all public interfaces defined.
> > > > To make a short story long, each time you add a new public
interface,
> > > you'll
> > > > need to update the binary compatibility model you're pointing to at
> > > compile
> > > > time..
> > > > > Hi,
> > > > > I have two projects in VB6 - one .exe and one active x dll.
> > > > > Lets say I make a change in the DLL, and re-compile it. Change
does
> > NOT
> > > > > break binary compatibility in any way.
> > > > > So, in theory, I should still be able to double click my .exe and
it
> > > would
> > > > > run fine.
> > > > > However- It tells me that "Class does not support automation or
> > expected
> > > > > interface"
> > > > > So, I load the .exe up in the IDE and Ctrl-F5 it and it runs fine.
> > Then,
> > > > > re-make the .EXE and I can now double click it and it runs fine.
> > > > > Any ideas what is going on here?! - It makes debugging very slow
and
> > > > > painful!
> > > > > Thanks
> > > > > Nick
|
| Mon, 26 Jan 2004 09:29:55 GMT |
|
| |
|
