How to capture VB.NET Event From VB6????

[Vanessa]

I have a class library developed in VB.NET. Inside there is a form with a
button1.

I add this class library to a VB6 Project.

I do a
Dim a as new classlibrary.form1
SetParent a.GetHwnd, Me.hWnd
a.show

But now I have a question, if the user click on the Button1 in the
ClassLibrary, I want my VB6 to know that button1 is being click.
This is becase when button1 is clicked, vb6 needs to do some processing.

Anyone know how to do this?

Regards
Vanessa

 

[mayayana]

I have a class library developed in VB.NET. Inside there is a form with a

button1.

I add this class library to a VB6 Project.

I do a
Dim a as new classlibrary.form1
SetParent a.GetHwnd, Me.hWnd
a.show

But now I have a question, if the user click on the Button1 in the
ClassLibrary, I want my VB6 to know that button1 is being click.
This is becase when button1 is clicked, vb6 needs to do some processing.

Anyone know how to do this?

Maybe translate it to VB6 and thereby eliminate 70+ MB
of dependencies while also making it work? What reason
could there possibly be to saddle VB with VB.Net code?

 

[Anthony Jones]

Maybe translate it to VB6 and thereby eliminate 70+ MB
of dependencies while also making it work? What reason
could there possibly be to saddle VB with VB.Net code?

OR

convert it all to VB.NET and not bother with the VB6 bit. It all depends on
what you've got the most of. If you have an existing VB6 app then is there
a compelling reason to interop with VB.NET or can't you just write this
component in VB6 as well.

OTH if you existing VB.NET code why would you want to create a VB6 app round
it, why not just continue with VB.NET for the UI element as well.

However to answer the original Q:-

http://www.codeproject.com/dotnet/cominterop.asp

 

[Ken Halter]

it, why not just continue with VB.NET for the UI element as well.

Maybe it's not a web app.... or he wants "better than web" performance... I
dunno.

 

[Anthony Jones]

Maybe it's not a web app.... or he wants "better than web" performance... I
dunno.

I don't understand. What has 'web' got to do with the question?

 

[Ken Halter]

I don't understand. What has 'web' got to do with the question?

dotNET.... note the word "NET" in there. Designed with the InterNET in mind,
obviously....

You know... it takes forever to load, forever to update the screen, etc,
etc.

....and, where you can nearly right click and say "View Source" and it gives
you the source for the entire app (with the help of any cheap debugger, that
is).. no matter how much you spend on an obfuscator, something that VB6 or
any other fully compiled language doesn't need at all, there are companies
like the one below...

"Think your code is safe, think again. Salamander .NET decompiler may steal
your source code"
http://www.remotesoft.com/

 

[mayayana]

I don't understand. What has 'web' got to do with the question?
If the original question is taken at face value ("How
do I build .Net code into VB6 code?") then it doesn't
make much sense altogether. The list of groups this
thread is going to shows the problem. The OP is
posting to VB6, VB.Net, COM and interop. VB.Net people
are being led to believe that it's all just good stuff.

With .Net, Microsoft has basically come up with their own
version of Java, except that it's not really cross-platform
(as usual) and even less so when you mix in "interop" and
"unmanaged code".

So the question is a bit like saying, "I'm writing software
in C++ and want to incorporate Java components. How
do I do that?"

DotNet answer: "It's all good. You might want to stick with
C++, or you might want to switch it all over to Java, or you
might want to force them together with "Sun-Interop". It doesn't
really matter because C++ and Java both use semi-colons."

Normal answer: "Well, those two approaches have very
different strengths and weaknesses. What is it that you're trying
to accomplish?"

 

[Anthony Jones]

dotNET.... note the word "NET" in there. Designed with the InterNET in mind,
obviously....

Ok I see. dotNET -> NET -> interNET -> Web. Seems to me your reaching a
bit there.

You know... it takes forever to load, forever to update the screen, etc,
etc.

None of the above is actually true. I can believe that .NET is somewhat
slower than a comparable VB6 app. I doubt that makes a real difference on
modern and future hardware but I could be wrong.

Just as the "IE browser is good as an application UI" juggernaut (which may
have true in some cases) meant that users are being saddled with
sub-standard UIs in the name progress the same could be happening here. You
could be right but you'll lose anyway.

A well written C++ standalone app will beat VB6 app. I can remember when
compilied VB5 came along and heard this same sort of argument then between
C++ and VB devs. It's all daft.

Don't get me wrong I like VB6 and still use it more than C#. Being familiar
with the Win API I don't see there being a compelling commercial reason to
switch. However, daft sweeping statements like the couple above don't
really help any "VB6 is better than .NET argument", which IMO is a silly
thing to argue about anyway.

...and, where you can nearly right click and say "View Source" and it gives
you the source for the entire app (with the help of any cheap debugger, that
is).. no matter how much you spend on an obfuscator, something that VB6 or
any other fully compiled language doesn't need at all, there are companies
like the one below...

Yes it's possible to get some semblance of source code from disassembly but
unless you've written some hardcore algorithm which gives you a competative
advantage it's doubtful that even unobfuscated disassembly is of really much
use to anyone and very doubtful that it can hurt you where it counts, in the
pocket.

 

[J French]

On Tue, 13 Mar 2007 09:15:12 -0000, "Anthony Jones"

Ok I see. dotNET -> NET -> interNET -> Web. Seems to me your reaching a
bit there.

No, I think Ken has correctly picked up on what MS were trying to
convey.

None of the above is actually true. I can believe that .NET is somewhat
slower than a comparable VB6 app. I doubt that makes a real difference on
modern and future hardware but I could be wrong.

Just as the "IE browser is good as an application UI" juggernaut (which may
have true in some cases) meant that users are being saddled with
sub-standard UIs in the name progress the same could be happening here. You
could be right but you'll lose anyway.

A well written C++ standalone app will beat VB6 app. I can remember when
compilied VB5 came along and heard this same sort of argument then between
C++ and VB devs. It's all daft.

VB5 was fully compileable from the outset.
It, like VB6 uses a jiggered C compiler

A CPP application does not have to be faster than a VB5/6 Application,
VB5/6 does more behind the scenes, a lot of that is unnecessary

Bear in mind that a lot of code is simply calling APIs
- also that things like copying one Byte Array to another pre-existing
Byte Array is astonishingly fast in VB

Don't get me wrong I like VB6 and still use it more than C#. Being familiar
with the Win API I don't see there being a compelling commercial reason to
switch. However, daft sweeping statements like the couple above don't
really help any "VB6 is better than .NET argument", which IMO is a silly
thing to argue about anyway.

Yes it's possible to get some semblance of source code from disassembly but
unless you've written some hardcore algorithm which gives you a competative
advantage it's doubtful that even unobfuscated disassembly is of really much
use to anyone and very doubtful that it can hurt you where it counts, in the
pocket.

I would not bet on that, one of the reasons why DoDi, the VB3/4
decompiler writer discontinued his work was because he felt it
unethical to be able to re-engineer source.

Under many circumstances de-compilation is a real advantage, but those
are when the 'owner' of the App already owns the source.

My beef is that MS are trying to pass off Fred.NET as an upgrade to
the old BASIC VB line
- it is not, it is an entirely different branch, say an elephant
masquerading as the descedant of a horse.

 

[Ken Halter]

My beef is that MS are trying to pass off Fred.NET as an upgrade to
the old BASIC VB line
- it is not, it is an entirely different branch, say an elephant
masquerading as the descedant of a horse.

All they would've needed to do is come up with one or more "new" letters to
name their "new" language, instead of trying to steal the thunder (lol) from
VB.real

They might've had people climbing all over themselves trying to grab copies.
"New Coke" just isn't "Coke". You'd think large companies would realize
their customers are the ones that made them large and avoid ticking that
customer base off, at all costs. "All costs" could've been as simple as
leaving "VB" alone or, better yet, completing their VB7 project and simply
picking a new name for their new language.

Why is it that COBOL and Delphi can run nearly untouched in dotNet but VB,
their own language, can't? Just plain silly. It's also silly to think no one
on earth can write a decent wizard to help people migrate their code. Any
7th grader these days can write a wizard that dumps "ToDo's" everywhere.

 

[Galen Somerville]

Ok I see. dotNET -> NET -> interNET -> Web. Seems to me your reaching a
bit there.


None of the above is actually true. I can believe that .NET is somewhat
slower than a comparable VB6 app. I doubt that makes a real difference on
modern and future hardware but I could be wrong.

I have a USB device supplying Heart sounds and ECG traces that runs at 300 beats-per-minute on VB6.
So far in .NET if fails above 15 beats-per-minute.

Galen

 

[Anthony Jones]

I have a USB device supplying Heart sounds and ECG traces that runs at 300 beats-per-minute on VB6.
So far in .NET if fails above 15 beats-per-minute.

Galen

Thats pretty poor. 20x slower. Stick with VB6 while you can.

What's the spec of the machine it is running on?
Is this a port from the VB6 app or a from scratch re-write?