IDE basics question

  • Thread starter Thread starter deko
  • Start date Start date
D

deko

I need to use Visual Basic to create an ActiveX DLL that
subclasses an Access form (cf. Knowledge Base Article
278379). Should I use Visual Studio .NET --or-- regular
Visual Basic 6 --or-- VS.NET 6... something else? what's
the diff?? is VS.NET only for creating managed code?
 
Hi deko

C# and VB.net are for managed code and you can make that with C++
C++ is also for unmanged code in VS.net.

Cor
 
Should I use Visual Studio .NET?

You can not create ActiveX anything with .NET.
or regula Visual Basic 6?

If you truley want to build an ActiveX DLL, then this would be your
place to do it.

or VS.NET 6?

There is no such thing. VS.NET is the next generation of Microsofts
Visual Studio brand but it is not built upon the same architecture and is a
completely different animal.

... something else? what's the diff?? is VS.NET only for creating
managed code?

Ah, now that is the question! Anything built with .NET is managed code and
you can not use .NET to build (emphasis on build) unmanaged code (COM). You
can build an application with .NET that calls unmanaged code, but you can
not build unmanaged code with .NET.

In genera, using .NET over its predicessor will bring better performance,
better scalability, better compatibility with other .NET languages, easier
maintenane and more to your application. There is a price though, VS.NET is
not just the "next" version of VS 6 and VB.NET is not just the "next"
version of VB 6.0. They are brand new and there will be a learning curve
involved.

Hope this helps.

Scott M.
 
Hi and thanks for the reply,

so it sounds like VS.NET is for building stuff that
requires the .Net Framework (?)

I fired up Visual Studio 6.0 (VB component) and clicked on
the "ActiveX DLL" icon in the New Project window... so far
so good...
 
so it sounds like VS.NET is for building stuff that
requires the .Net Framework (?)

Yes, that's the whole point.
I fired up Visual Studio 6.0 (VB component) and clicked on
the "ActiveX DLL" icon in the New Project window... so far
so good...

I hope that this serves your purpose.

Good luck!
 
Scott said:
You can not create ActiveX anything with .NET.

You certainly can, by exporting your .NET classes usin tlibexp.
If you truley want to build an ActiveX DLL, then this would
be your place to do it.



There is no such thing. VS.NET is the next generation of
Microsofts Visual Studio brand but it is not built upon the same
architecture and is a completely different animal.



Ah, now that is the question! Anything built with .NET is managed
code and you can not use .NET to build (emphasis on build) unmanaged
code (COM). You can build an application with .NET that calls
unmanaged code, but you can not build unmanaged code with .NET.

That is not true. You can build unmanaged code with MC++.
 
deko said:
Hi and thanks for the reply,

so it sounds like VS.NET is for building stuff that
requires the .Net Framework (?)

In general, yes, but you can export your .NET classes and create an ActiveX
..tlb by doing so which other modules can use as if their were using an
ActiveX library. Still there is the overhead of using .NET to host your
ActiveX .NET implementation as opposed to just creating ActiveX libraries
without .NET. OTOH I believe it is much simpler creating an ActiveX library
from .NET classes than through, let's say, the VC++ ATL classes.
 
You can not create ActiveX anything with .NET.
You certainly can, by exporting your .NET classes usin tlibexp.

But then you would be using CCW's so that the .NET app would "look" like a
COM app. Sure, you can do this, but I wouldn't say that this is ActiveX
development. I would say this is .NET to COM interOp.

The fact is that you can't build an ActiveX anything directly from VS.NET.
 
Scott said:
But then you would be using CCW's so that the .NET app would "look"
like a COM app. Sure, you can do this, but I wouldn't say that this
is ActiveX development. I would say this is .NET to COM interOp.

The fact is that you can't build an ActiveX anything directly from
VS.NET.

I am sure you know that exporting one's .NET classes using tlibexp does in
fact produce an ActiveX library which can be used in the normal way without
the user needing to be aware that the .NET framework will host the ActiveX
implementation. However I think we will be splitting hairs over this if we
discuss it much further. Whether this constitutes just "looking" like an
ActiveX library or being one, or whether it constitutes "building an ActiveX
anything directly from VS.NET", will probably degenerate into a semantic
argument rather than a technical one.

As far as whether it is better to build an ActiveX library from C++/ATL or
..NET classes, I think that is almost purely an ease of personal programming
preference. I do recognize having the .NET framework host an ActiveX library
as being more of a run-time overhead than if one's ActiveX library were
built directly from native COM classes and interfaces. But then again,
having .NET "anything" will impose more of an overhead than dealing directly
with the Win32 API and its native libraries.
 
I am sure you know that exporting one's .NET classes using tlibexp does in
fact produce an ActiveX library which can be used in the normal way without
the user needing to be aware that the .NET framework will host the ActiveX
implementation. However I think we will be splitting hairs over this if we
discuss it much further. Whether this constitutes just "looking" like an
ActiveX library or being one, or whether it constitutes "building an ActiveX
anything directly from VS.NET", will probably degenerate into a semantic
argument rather than a technical one.

I don't think this is splitting hairs at all. I can build a VB 6.0 (COM)
component and use it in .NET but that doesn't mean that I have built a .NET
component in VB 6.0.

The same is true for creating a .NET component and "using" it from a COM
application (via a COM Callable Wrapper -CCW).

The fact reamains: You can't build an ActiveX anything "directly" from
..NET.
 
Thanks Edward.

I've been away for a few days on Christmas break...

So, as I begin my journey into Visual Studio and Microsoft development,
there are 2 choices: managed code and unmanaged code. If I want to write
stuff that uses the .NET Framework, I can use VS.NET -- otherwise (generally
speaking) I should use Visual Studio 6 and a language like VB or C++. Does
this sound about right?

But now I'm wondering... why bother with the .NET framework? Why not
simply write the app in VB? Is there some advantage to using managed code?
Are there language-based advantages - for example, is C# better than VB for
some things?
 
Back
Top