Creating objects (by assignment) in VB6

Bartholomew Simpson · Joined: 04 Oct 2007 Posts: 7

I wrote a C++ library that I want to use in VB6. I have exported a C API
(via a win32 DLL) that may be used in VB6 using the 'Declare Function'
syntax.

However, I need to group related functions together (in VB6), by
wrapping them together in a VB6 class.

Assuming CreateNewObject is an exposed C function that returns a pointer
to a C++ object is declared in VB6 as follows:

Declare function CreateNewObject lib "mylib" () as long

Using the plain API (without wrapping the C++ objects in a VB6 class), I
would have code that looks like this :

dim lngPtr as long
lngPtr = CreateNewObject() 'calls Dll function

With the exposed C functions wrapped up in VB6 classes, the code looks
something like this:

dim objVBWrapper as MyVBWrapperClass

// which of these statements are correct?
objVBWrapper = CreateNewObject() //OR
Set objVBWrapper = CreateNewObject()

The key difference here is that I am creating the object by assignment.
Since there is no explicit copy constructor in VB6 I'm not sure how this
may be implemented. Ideas please ...

Archived from group: microsoft>public>vb>enterprise

Ralph · Joined: 04 Oct 2007 Posts: 4148

"Bartholomew Simpson" wrote in message@bt.com...
> I wrote a C++ library that I want to use in VB6. I have exported a C API
> (via a win32 DLL) that may be used in VB6 using the 'Declare Function'
> syntax.
>
> However, I need to group related functions together (in VB6), by
> wrapping them together in a VB6 class.
>
> Assuming CreateNewObject is an exposed C function that returns a pointer
> to a C++ object is declared in VB6 as follows:
>
> Declare function CreateNewObject lib "mylib" () as long
>
> Using the plain API (without wrapping the C++ objects in a VB6 class), I
> would have code that looks like this :
>
> dim lngPtr as long
> lngPtr = CreateNewObject() 'calls Dll function
>
>
> With the exposed C functions wrapped up in VB6 classes, the code looks
> something like this:
>
> dim objVBWrapper as MyVBWrapperClass
>
> // which of these statements are correct?
> objVBWrapper = CreateNewObject() //OR
> Set objVBWrapper = CreateNewObject()
>
> The key difference here is that I am creating the object by assignment.
> Since there is no explicit copy constructor in VB6 I'm not sure how this
> may be implemented. Ideas please ...
>

It took me a while to figure out what you are trying to do. Still not sure,
but here is my best guess for a reply.

You can NOT deliver a valid Reference to a VB Class from a Regular Dll, ie,
you cannot "create" an object by assignment.

Thus ...
> dim lngPtr as long
> lngPtr = CreateNewObject() 'calls Dll function
.... might deliver some value to VB, but there is nothing VB can do with it
except store it or pass it back.

If you have a VB Class called "MyVBWrapperClass" which is using the services
of the Dll, you can create an instance of the VB class by using...
Dim objVBWrapper As MyVBWrapperClass
Set objVBWrapper = New MyVBWrapperClass

Why do you need to assign a reference to a C++ class? Perhaps an ActiveX Dll
might be a better solution?

-ralph

Bartholomew Simpson · Joined: 04 Oct 2007 Posts: 7

Ralph wrote:

> "Bartholomew Simpson" wrote in message
> @bt.com...
>
>>I wrote a C++ library that I want to use in VB6. I have exported a C API
>>(via a win32 DLL) that may be used in VB6 using the 'Declare Function'
>>syntax.
>>
>>However, I need to group related functions together (in VB6), by
>>wrapping them together in a VB6 class.
>>
>>Assuming CreateNewObject is an exposed C function that returns a pointer
>>to a C++ object is declared in VB6 as follows:
>>
>>Declare function CreateNewObject lib "mylib" () as long
>>
>>Using the plain API (without wrapping the C++ objects in a VB6 class), I
>>would have code that looks like this :
>>
>>dim lngPtr as long
>>lngPtr = CreateNewObject() 'calls Dll function
>>
>>
>>With the exposed C functions wrapped up in VB6 classes, the code looks
>>something like this:
>>
>>dim objVBWrapper as MyVBWrapperClass
>>
>>// which of these statements are correct?
>>objVBWrapper = CreateNewObject() //OR
>>Set objVBWrapper = CreateNewObject()
>>
>>The key difference here is that I am creating the object by assignment.
>>Since there is no explicit copy constructor in VB6 I'm not sure how this
>> may be implemented. Ideas please ...
>>
>
>
> It took me a while to figure out what you are trying to do. Still not sure,
> but here is my best guess for a reply.
>
> You can NOT deliver a valid Reference to a VB Class from a Regular Dll, ie,
> you cannot "create" an object by assignment.
>
> Thus ...
>
>>dim lngPtr as long
>>lngPtr = CreateNewObject() 'calls Dll function
>
> ... might deliver some value to VB, but there is nothing VB can do with it
> except store it or pass it back.
>
> If you have a VB Class called "MyVBWrapperClass" which is using the services
> of the Dll, you can create an instance of the VB class by using...
> Dim objVBWrapper As MyVBWrapperClass
> Set objVBWrapper = New MyVBWrapperClass
>
> Why do you need to assign a reference to a C++ class? Perhaps an ActiveX Dll
> might be a better solution?
>

I dont really need to assign a reference to a C++ class. Basically, I
want to be able to use my objects in VB. I am writing an OO toolkit, and
I want to expose these objects to people using the toolkit. Some
functions/methods return objects and this is why I wanted to know how I
could be able to instantiate an object from the return value of a
function (if that makes sense).

i.e. I wanted coders using my toolkit to be able to write something like
this:

Set objFunkObject = SomeObject.CreateFuncObject(param1, param2)

I think you are on the right track though, I think I will have to create
ActiveX DLL classes that wrap around the C fucntion calls.

Its a long time since I used VB though and I dont remember if it is
possible to 'set' an object to another object returned by a function/method.

So my questions are;

1). Is it able to 'set' an object to an object returned by a
function/method (I think the answer to this is yes)

If yes, what happens if the object was already set to another object?
(in C++ for example, you can take care of freeing memory etc in an
overloaded assignment operator) - I don't know how it is possible to
prevent memory leaks in VB if there is code like this :

dim obj as myFunkyObject ;

'This calls the underlying C function which creates a pointer to a C
structure say
set obj = FunkMasterFactory.CreateFunkyThing()

'The second call will create memory again
set obj = FunkMasterFactory.CreateFunkyThing()

Is there any way to check (behind the scenes) if an object has already
been set) so that memory leakage can be prevented, if a coder is foolish
enough to 'Set' an object multiple times?

2). I think that the solution to my problem (ignoring the potential
memory leak issue for now), will be to create ActiveX dll objects which
wrap around the individual C++ functions, so that these ActiveX DLL
objects are the ones that I make available in my VB toolkit - is that
correct thinking ? (or have I missed anything?)

Ralph · Joined: 04 Oct 2007 Posts: 4148

"Bartholomew Simpson" wrote in message@bt.com...
>
>
> Ralph wrote:
>
> > "Bartholomew Simpson" wrote in message
> > @bt.com...
> >
> >>I wrote a C++ library that I want to use in VB6. I have exported a C API
> >>(via a win32 DLL) that may be used in VB6 using the 'Declare Function'
> >>syntax.
> >>
> >>However, I need to group related functions together (in VB6), by
> >>wrapping them together in a VB6 class.
> >>
> >>Assuming CreateNewObject is an exposed C function that returns a pointer
> >>to a C++ object is declared in VB6 as follows:
> >>
> >>Declare function CreateNewObject lib "mylib" () as long
> >>
> >>Using the plain API (without wrapping the C++ objects in a VB6 class), I
> >>would have code that looks like this :
> >>
> >>dim lngPtr as long
> >>lngPtr = CreateNewObject() 'calls Dll function
> >>
> >>
> >>With the exposed C functions wrapped up in VB6 classes, the code looks
> >>something like this:
> >>
> >>dim objVBWrapper as MyVBWrapperClass
> >>
> >>// which of these statements are correct?
> >>objVBWrapper = CreateNewObject() //OR
> >>Set objVBWrapper = CreateNewObject()
> >>
> >>The key difference here is that I am creating the object by assignment.
> >>Since there is no explicit copy constructor in VB6 I'm not sure how this
> >> may be implemented. Ideas please ...
> >>
> >
> >
> > It took me a while to figure out what you are trying to do. Still not
sure,
> > but here is my best guess for a reply.
> >
> > You can NOT deliver a valid Reference to a VB Class from a Regular Dll,
ie,
> > you cannot "create" an object by assignment.
> >
> > Thus ...
> >
> >>dim lngPtr as long
> >>lngPtr = CreateNewObject() 'calls Dll function
> >
> > ... might deliver some value to VB, but there is nothing VB can do with
it
> > except store it or pass it back.
> >
> > If you have a VB Class called "MyVBWrapperClass" which is using the
services
> > of the Dll, you can create an instance of the VB class by using...
> > Dim objVBWrapper As MyVBWrapperClass
> > Set objVBWrapper = New MyVBWrapperClass
> >
> > Why do you need to assign a reference to a C++ class? Perhaps an ActiveX
Dll
> > might be a better solution?
> >
>
> I dont really need to assign a reference to a C++ class. Basically, I
> want to be able to use my objects in VB. I am writing an OO toolkit, and
> I want to expose these objects to people using the toolkit. Some
> functions/methods return objects and this is why I wanted to know how I
> could be able to instantiate an object from the return value of a
> function (if that makes sense).
>
> i.e. I wanted coders using my toolkit to be able to write something like
> this:
>
>
> Set objFunkObject = SomeObject.CreateFuncObject(param1, param2)
>
>
> I think you are on the right track though, I think I will have to create
> ActiveX DLL classes that wrap around the C fucntion calls.
>
> Its a long time since I used VB though and I dont remember if it is
> possible to 'set' an object to another object returned by a
function/method.
>
> So my questions are;
>
> 1). Is it able to 'set' an object to an object returned by a
> function/method (I think the answer to this is yes)
>
> If yes, what happens if the object was already set to another object?
> (in C++ for example, you can take care of freeing memory etc in an
> overloaded assignment operator) - I don't know how it is possible to
> prevent memory leaks in VB if there is code like this :
>
>
> dim obj as myFunkyObject ;
>
> 'This calls the underlying C function which creates a pointer to a C
> structure say
> set obj = FunkMasterFactory.CreateFunkyThing()
>
> 'The second call will create memory again
> set obj = FunkMasterFactory.CreateFunkyThing()
>
> Is there any way to check (behind the scenes) if an object has already
> been set) so that memory leakage can be prevented, if a coder is foolish
> enough to 'Set' an object multiple times?
>
>
> 2). I think that the solution to my problem (ignoring the potential
> memory leak issue for now), will be to create ActiveX dll objects which
> wrap around the individual C++ functions, so that these ActiveX DLL
> objects are the ones that I make available in my VB toolkit - is that
> correct thinking ? (or have I missed anything?)
>

You kind of wandered around a bit (or rather I got lost once or twice ),
but your last statement sums it up best.

I have to be careful with terminology here. But from a 40,000 foot level - A
"VB Class" is not the same as a "C++ class". Instances of each are very
different and a Reference to one in one language/environment won't mean a
damn thing to other language/environment.

VB Classes are modules built to behave like COM Intefaces. There is a bit of
short-cutting going on for "In-Project" instances of a VB Class (marshalling
for example is not needed). And a great deal of "COM" is swallowed up by the
VBRuntime even when used In-Proc or Out-Proc. In other words, while it is
not impossible to work with raw COM in C/C++ to mimic VB Classes - you don't
under any circumstances want to go there.

However, by supplying an ActiveX component VB can use your objects as though
they were native-born. Within limits. VB doesn't, unfortunately, understand
all possible COM Interfaces.

If you are using VC++ and intend to write an ActiveX component for VB's use,
I suggest using the ATL. The project templates will simply a lot of the work
for you. Also I suggest you consider using Variants or Ole types
(SafeArrays, BStrs, etc) for passing data. It means a bit more work for your
C++ program, but will remove many opportunities for misunderstandings and
make it easier for a VB programmer to utilize your tool. It also makes
memory management easier.

-ralph

Bartholomew Simpson · Joined: 04 Oct 2007 Posts: 7

Ralph wrote:

> "Bartholomew Simpson" wrote in message
> @bt.com...
>
>>
>>Ralph wrote:
>>
>>
>>>"Bartholomew Simpson" wrote in message
>>>@bt.com...
>>>
>>>
>>>>I wrote a C++ library that I want to use in VB6. I have exported a C API
>>>>(via a win32 DLL) that may be used in VB6 using the 'Declare Function'
>>>>syntax.
>>>>
>>>>However, I need to group related functions together (in VB6), by
>>>>wrapping them together in a VB6 class.
>>>>
>>>>Assuming CreateNewObject is an exposed C function that returns a pointer
>>>>to a C++ object is declared in VB6 as follows:
>>>>
>>>>Declare function CreateNewObject lib "mylib" () as long
>>>>
>>>>Using the plain API (without wrapping the C++ objects in a VB6 class), I
>>>>would have code that looks like this :
>>>>
>>>>dim lngPtr as long
>>>>lngPtr = CreateNewObject() 'calls Dll function
>>>>
>>>>
>>>>With the exposed C functions wrapped up in VB6 classes, the code looks
>>>>something like this:
>>>>
>>>>dim objVBWrapper as MyVBWrapperClass
>>>>
>>>>// which of these statements are correct?
>>>>objVBWrapper = CreateNewObject() //OR
>>>>Set objVBWrapper = CreateNewObject()
>>>>
>>>>The key difference here is that I am creating the object by assignment.
>>>>Since there is no explicit copy constructor in VB6 I'm not sure how this
>>>> may be implemented. Ideas please ...
>>>>
>>>
>>>
>>>It took me a while to figure out what you are trying to do. Still not
>
> sure,
>
>>>but here is my best guess for a reply.
>>>
>>>You can NOT deliver a valid Reference to a VB Class from a Regular Dll,
>
> ie,
>
>>>you cannot "create" an object by assignment.
>>>
>>>Thus ...
>>>
>>>
>>>>dim lngPtr as long
>>>>lngPtr = CreateNewObject() 'calls Dll function
>>>
>>>... might deliver some value to VB, but there is nothing VB can do with
>
> it
>
>>>except store it or pass it back.
>>>
>>>If you have a VB Class called "MyVBWrapperClass" which is using the
>
> services
>
>>>of the Dll, you can create an instance of the VB class by using...
>>> Dim objVBWrapper As MyVBWrapperClass
>>> Set objVBWrapper = New MyVBWrapperClass
>>>
>>>Why do you need to assign a reference to a C++ class? Perhaps an ActiveX
>
> Dll
>
>>>might be a better solution?
>>>
>>
>>I dont really need to assign a reference to a C++ class. Basically, I
>>want to be able to use my objects in VB. I am writing an OO toolkit, and
>>I want to expose these objects to people using the toolkit. Some
>>functions/methods return objects and this is why I wanted to know how I
>> could be able to instantiate an object from the return value of a
>>function (if that makes sense).
>>
>>i.e. I wanted coders using my toolkit to be able to write something like
>>this:
>>
>>
>>Set objFunkObject = SomeObject.CreateFuncObject(param1, param2)
>>
>>
>>I think you are on the right track though, I think I will have to create
>>ActiveX DLL classes that wrap around the C fucntion calls.
>>
>>Its a long time since I used VB though and I dont remember if it is
>>possible to 'set' an object to another object returned by a
>
> function/method.
>
>>So my questions are;
>>
>>1). Is it able to 'set' an object to an object returned by a
>>function/method (I think the answer to this is yes)
>>
>>If yes, what happens if the object was already set to another object?
>>(in C++ for example, you can take care of freeing memory etc in an
>>overloaded assignment operator) - I don't know how it is possible to
>>prevent memory leaks in VB if there is code like this :
>>
>>
>>dim obj as myFunkyObject ;
>>
>>'This calls the underlying C function which creates a pointer to a C
>>structure say
>>set obj = FunkMasterFactory.CreateFunkyThing()
>>
>>'The second call will create memory again
>>set obj = FunkMasterFactory.CreateFunkyThing()
>>
>>Is there any way to check (behind the scenes) if an object has already
>>been set) so that memory leakage can be prevented, if a coder is foolish
>>enough to 'Set' an object multiple times?
>>
>>
>>2). I think that the solution to my problem (ignoring the potential
>>memory leak issue for now), will be to create ActiveX dll objects which
>>wrap around the individual C++ functions, so that these ActiveX DLL
>>objects are the ones that I make available in my VB toolkit - is that
>>correct thinking ? (or have I missed anything?)
>>
>
>
> You kind of wandered around a bit (or rather I got lost once or twice ),
> but your last statement sums it up best.
>
> I have to be careful with terminology here. But from a 40,000 foot level - A
> "VB Class" is not the same as a "C++ class". Instances of each are very
> different and a Reference to one in one language/environment won't mean a
> damn thing to other language/environment.
>
> VB Classes are modules built to behave like COM Intefaces. There is a bit of
> short-cutting going on for "In-Project" instances of a VB Class (marshalling
> for example is not needed). And a great deal of "COM" is swallowed up by the
> VBRuntime even when used In-Proc or Out-Proc. In other words, while it is
> not impossible to work with raw COM in C/C++ to mimic VB Classes - you don't
> under any circumstances want to go there.
>
> However, by supplying an ActiveX component VB can use your objects as though
> they were native-born. Within limits. VB doesn't, unfortunately, understand
> all possible COM Interfaces.
>
> If you are using VC++ and intend to write an ActiveX component for VB's use,
> I suggest using the ATL. The project templates will simply a lot of the work
> for you. Also I suggest you consider using Variants or Ole types
> (SafeArrays, BStrs, etc) for passing data. It means a bit more work for your
> C++ program, but will remove many opportunities for misunderstandings and
> make it easier for a VB programmer to utilize your tool. It also makes
> memory management easier.
>
> -ralph
>
>

Thanks Ralph - you didn't actually answer my questions (which were
probably not very clear in the first place). I'll ask a much simpler and
straightforward question:

I don't fancy learning ATL (don't have enough time, plus seems to be
outdated technology) - so I inted to write the COM ActiveX DLL objects
that wrap around my C functions, using VB6. i.e. create ActiveX DLL
objects in VB6, and then make these COM objects available to the toolkit.

Can you confirm that this will work (actually, I can't think why it will
not - but just need to confirm)

Ralph · Joined: 04 Oct 2007 Posts: 4148

"Bartholomew Simpson" wrote in message@bt.com...
>
> > >
>
> Thanks Ralph - you didn't actually answer my questions (which were
> probably not very clear in the first place). I'll ask a much simpler and
> straightforward question:
>
> I don't fancy learning ATL (don't have enough time, plus seems to be
> outdated technology) - so I inted to write the COM ActiveX DLL objects
> that wrap around my C functions, using VB6. i.e. create ActiveX DLL
> objects in VB6, and then make these COM objects available to the toolkit.
>
> Can you confirm that this will work (actually, I can't think why it will
> not - but just need to confirm)
>

Yes, you can write a VB ActiveX Dll which can utilize your C functions.

However, IMHO, on the long run it is generally better to wrap C functions in
a "C/C++" ActiveX component. The ATL is only as outdated as using COM
itself.

[Incidently your fears over "memory leaks" due to multiple assignments using
Set are unfounded, for reasons that will become clear once you start using
your components.]

-ralph

Bartholomew Simpson · Joined: 04 Oct 2007 Posts: 7

Ralph wrote:

> "Bartholomew Simpson" wrote in message
> @bt.com...
>
>>>>
>>
>>Thanks Ralph - you didn't actually answer my questions (which were
>>probably not very clear in the first place). I'll ask a much simpler and
>>straightforward question:
>>
>>I don't fancy learning ATL (don't have enough time, plus seems to be
>>outdated technology) - so I inted to write the COM ActiveX DLL objects
>>that wrap around my C functions, using VB6. i.e. create ActiveX DLL
>>objects in VB6, and then make these COM objects available to the toolkit.
>>
>>Can you confirm that this will work (actually, I can't think why it will
>>not - but just need to confirm)
>>
>
>
> Yes, you can write a VB ActiveX Dll which can utilize your C functions.
>
> However, IMHO, on the long run it is generally better to wrap C functions in
> a "C/C++" ActiveX component. The ATL is only as outdated as using COM
> itself.
>
> [Incidently your fears over "memory leaks" due to multiple assignments using
> Set are unfounded, for reasons that will become clear once you start using
> your components.]
>
> -ralph
>
>

Thanks Ralph (Wiggum? Wink

)

Actually, I decided that I'll have to delve into ATL afterall, because
of some thechnical reasons I hadn't thought of b4. Thanks anyway for
confirming that

Ralph · Joined: 04 Oct 2007 Posts: 4148

"Bartholomew Simpson" wrote in message@bt.com...
>
>
> Ralph wrote:
>
> > "Bartholomew Simpson" wrote in message
> > @bt.com...
> >
> >>>>
>>
>
> Thanks Ralph (Wiggum? Wink

)
>
> Actually, I decided that I'll have to delve into ATL afterall, because
> of some thechnical reasons I hadn't thought of b4. Thanks anyway for
> confirming that

Before it's over you will likely be learning more COM than you figure you
want to know.

There are many references, but an excellent book, one that will get you
started very quickly and specifically addresses VB/C++ issues, is "Beginning
ATL COM Programming", Grimes etal, Wrox Books.

You can get a copy very cheap. Less than $5.

-ralph

Schmidt · Joined: 04 Oct 2007 Posts: 806

"Bartholomew Simpson" schrieb im Newsbeitrag@bt.com...

> I don't fancy learning ATL (don't have enough time,
> plus seems to be outdated technology) - so I inted to
> write the COM ActiveX DLL objects that wrap around
> my C functions, using VB6. i.e. create ActiveX DLL
> objects in VB6, and then make these COM objects
> available to the toolkit.
Why not simply export your C Functions (StdCall-Decl)
and let the VB-COM-Wrapper use "Declares" inside?

Olaf

Ralph · Joined: 04 Oct 2007 Posts: 4148

"Schmidt" wrote in message
news:%234Mvn32tHHA.1584@TK2MSFTNGP05.phx.gbl...
>
> "Bartholomew Simpson" schrieb im Newsbeitrag
> @bt.com...
>
> > I don't fancy learning ATL (don't have enough time,
> > plus seems to be outdated technology) - so I inted to
> > write the COM ActiveX DLL objects that wrap around
> > my C functions, using VB6. i.e. create ActiveX DLL
> > objects in VB6, and then make these COM objects
> > available to the toolkit.
> Why not simply export your C Functions (StdCall-Decl)
> and let the VB-COM-Wrapper use "Declares" inside?
>
> Olaf
>

Which was what the OP was actually asking about. After a couple of exchanges
that is what he planned on doing. The OP has since had second thoughts.

Pure guess on my part, but considering the type of application he was going
for (and considering the need for C in the first place), IMHO he is better
off sticking with C for the mechanics and VB for the presentation.

As for "Declares", they are provided to allow VB 'easy' access to Win and
3rd Party Regular Dlls. But should never be used in 'production' code. But
that is only my opinion, and thus highly suspect.

-ralph

Schmidt · Joined: 04 Oct 2007 Posts: 806

"Ralph" schrieb im Newsbeitrag%23gJY4tHHA.4952@TK2MSFTNGP04.phx.gbl...

> Pure guess on my part, but considering the type of
> application he was going for (and considering the need
> for C in the first place), IMHO he is better off sticking
> with C for the mechanics and VB for the presentation.
Yes - and therefore he could define a simple "procedural-
interface" in his C-stuff, including a *.def-file for the C-exports
to VB.

> As for "Declares", they are provided to allow VB 'easy'
> access to Win and 3rd Party Regular Dlls. But should
> never be used in 'production' code.
Why, what I mean is - he should build a "3rd-party-C-Dll"
and consume that inside the VB-COM-Wrapper.

Olaf

Ralph · Joined: 04 Oct 2007 Posts: 4148

"Schmidt" wrote in message@TK2MSFTNGP06.phx.gbl...
>
> "Ralph" schrieb im Newsbeitrag
> %23gJY4tHHA.4952@TK2MSFTNGP04.phx.gbl...
>
> > Pure guess on my part, but considering the type of
> > application he was going for (and considering the need
> > for C in the first place), IMHO he is better off sticking
> > with C for the mechanics and VB for the presentation.
> Yes - and therefore he could define a simple "procedural-
> interface" in his C-stuff, including a *.def-file for the C-exports
> to VB.
>
> > As for "Declares", they are provided to allow VB 'easy'
> > access to Win and 3rd Party Regular Dlls. But should
> > never be used in 'production' code.
> Why, what I mean is - he should build a "3rd-party-C-Dll"
> and consume that inside the VB-COM-Wrapper.
>
> Olaf
>

I know what you meant.

I was only providing an unsolicitated and not all that useful opinion on
using Declare Statements.

-ralph

Kevin Provance · Joined: 04 Oct 2007 Posts: 800

Ralph · Joined: 04 Oct 2007 Posts: 4148

"Kevin Provance" wrote in message
news:%23e417A4uHHA.484@TK2MSFTNGP06.phx.gbl...
> Eh?
>
> Maybe I missed something here along the way, but without Declare
statements,
> using the API would be more difficult. Yes?
>
> - Kev

I was being boorish. I seldom miss an opportunity to rant against Declare
Statements. Similar to those who can't stand Variants, DE, FSO, End, etc.

[Rant follows, you can bail here... ]

IMHO, the Declare statement should never be used in production applications.
You should always create a type library.

1) A Declare statement takes a minimum of 16 bytes each, and usually a lot
more. Typelibs add no overhead to the finished product.
2) A Declare statement causes the addition of extra code to do parameter
checking at runtime. With a typelib VB will do type checking during its
syntax-checking, before the compile. Again no extra overhead in the released
version. (adds Intellisense).
3) With a Declare statement there is no Intellisense. Many errors are not
discovered until runtime. Typelibs provide Intellisense.
4) Declare statements can be changed easily during normal editing, but this
also makes it is easy to accidently insert variations at different
locations. A typelib is essentially 'hidden' away during development.
5) Using a typedef for the WinAPI or any other common libraries will insure
consistent results (ie, no surprises) across modules, components, and
suites.
6) They are also ideal for Enums, TypeDefs, Structs, Constants. Allowing
them to be used universally throughout VB Projects avoiding VB's scope
issues with these items.

[Ok, I'm done. ]

But it doesn't really matter anymore.

-ralph

Schmidt · Joined: 04 Oct 2007 Posts: 806

"Ralph" schrieb im Newsbeitrag%23l2Q5uHHA.3476@TK2MSFTNGP02.phx.gbl...

> [Rant follows, you can bail here... ]
>
> IMHO, the Declare statement should never be used in
> production applications.
That sentence (also in your earlier post) hasn't made much
sense to me...
> You should always create a type library.
....now it does, ...somewhat Wink

From my point of view "You should always ..." would read
better, replaced with "You are sometimes good advised to ...". Wink

> 1) A Declare statement takes a minimum of 16 bytes each, and usually a lot
> more. Typelibs add no overhead to the finished product.
For 100 Declares that would be 1600Bytes, ..."usually a lot more" hmm...,
ok, let's assume factor 10, that would be 16KByte - nothing to talk about
nowadays.

> 2) A Declare statement causes the addition of extra code to do
> parameter checking at runtime. With a typelib VB will do type
> checking during its syntax-checking, before the compile.
Do you have any sources, where this is stated?

> (adds Intellisense).
ModuleName.DeclaredFunction gives you intellisense too.

> 3) With a Declare statement there is no Intellisense. Many errors are not
> discovered until runtime. Typelibs provide Intellisense.
As said in 2), I doubt that.

> 4) Declare statements can be changed easily during normal editing, but
this
> also makes it is easy to accidently insert variations at different
> locations. A typelib is essentially 'hidden' away during development.
Putting all your "Declare-*.bas-Modules" into a ReadOnly-Folder
has the same effect.

> 5) Using a typedef for the WinAPI or any other common libraries will
insure
> consistent results (ie, no surprises) across modules, components, and
> suites.
Same solution possible as in 4)

> 6) They are also ideal for Enums, TypeDefs, Structs, Constants. Allowing
> them to be used universally throughout VB Projects avoiding VB's scope
> issues with these items.
Same with Public defined Members in a readonly *.bas-Module.

From my point of view, typelibs are useful, and I use them myself
for Declare-Replacements but only because of the slight speed-
advantage, wich comes from the ommited Err-Object-check,
wich is always performed in case of a "normal Declare".
E.g. my interface to the SQLite-Engine-Dll, wich is plain C,
is done over a typelib because of the above reason, but I use
"normal" Declare-Statements too in my projects, some large
encapsulations (e.g. FileOps.bas, containing FileDlg-APIs, etc.)
aren't touched over years now and used quite often.

Olaf

Creating objects (by assignment) in VB6 I am writing a VB6 frontend to my application. The backend is written in C/C++. I have writen functions I can use in VB^ using 'Declare Function' syntax. However, I need to group related functions together (in VB6), by wrapping them together in a VB6 clas

Business Objects Hello, I am developing an insurance app. I have initial risks of motor and property setup in the system. The challenge I have is to allow a user in future be able to add any new risk without The scenario is for instance, the user must be a

VB & adsi returning 1000+ objects Hello, I'm new to VB.NET and ADSI. By default it appears the adsi limits objects returned to 1000 items. I've seen web references that say that the limit is imposed by unpaged queries. I added an explicit pagesize statement, and the findall.count value

ActiveX calling remote COM objects and Outlook I have an CRM application that I'm customizing. The application uses business objects running in the COM+ Services app on the IIS server. I need to be able to communicate with these objects from a client machine. Basically, I've built an Ac

GURU question: Late vs. Early binding objects In my application, I need to implement a class object based on which user is using my application . In other words, the front end user interface is the same, but the middle tier is implemented specific to user requirements. For example, for a given clie