Declare Statement

[Simon Osborn]

Hi,

Instead of adding my own custom dll's as references into my project, I want
to call it via declare statement. However, I'm having a few difficulties!

My dll contains a basic function :

Public Class MyDLL
Public shared function MyTestFunction (byval mystr as string)
try
return mystr & "Success"
catch ex as exception
msgbox("There has been an error!")
end try
End Function
End Class

My Test Application contains:

Module Main
Private Declare Auto Function MyTestFunction _
Lib "DLL Example.dll" _
Alias "MyTestFunction" _
(ByVal MyStr as String)

Sub Main()
MsgBox(MyTestFunction("Test was : "))
End Sub

End Module

An exception is thrown telling my that its "unable to find an entry point"
into the dll "DLL Example.dll"

Should I be doing something else within my dll to expose the function
(exported)?

Or am calling the dll within my application incorrectly?

SSO.

 

[Armin Zingler]

Instead of adding my own custom dll's as references into my project,
I want to call it via declare statement. However, I'm having a few
difficulties!

You can not write Standard DLLs with VB.NET. Set a reference to the assembly
in the project that requires the assembly. We live in an OO world nowadays.

 

[Cor]

Hi Armin,

Again an OT and it is not only ment for you.

But you did write a little bit what I was thinking when I saw your last
messages.

I think (but I can be wrong), calling only API's, making a Webbrowser Helper
using only handles, making Dll librarys etc, is'not using VB.net but trying
to make things you never could do because you had to use C++. But now that
VB is OO it looks if some people are thinking that C++ is the same as
VB.net, try it and ask here.

In past I saw a lot of messages who told people to turn to the Asp.net group
while they where really writing VB language. Now I saw a very nice message
from Dimitry who told someone that he had a better change in the
dotnet.framework.interop newsgroup. And I did very much agree with him (Very
nice said of course by Dimitry).

But I can be wrong with my thought, what is your opinion?

Cor

 

[Armin Zingler]

Hi Armin,

Again an OT and it is not only ment for you.

But you did write a little bit what I was thinking when I saw your
last messages.

I think (but I can be wrong), calling only API's, making a Webbrowser
Helper using only handles, making Dll librarys etc, is'not using
VB.net but trying to make things you never could do because you had
to use C++. But now that VB is OO it looks if some people are
thinking that C++ is the same as VB.net, try it and ask here.

In past I saw a lot of messages who told people to turn to the
Asp.net group while they where really writing VB language. Now I saw
a very nice message from Dimitry who told someone that he had a
better change in the dotnet.framework.interop newsgroup. And I did
very much agree with him (Very nice said of course by Dimitry).

But I can be wrong with my thought, what is your opinion?

Cor

I read your post three times but, sorry again, I don't get the core (not Cor
;-) ) statement. Is it about posting to the right group, using pInvoke, or
whatever?

 

[Herfried K. Wagner [MVP]]

Again an OT and it is not only ment for you.
;-)

I think (but I can be wrong), calling only API's, making a Webbrowser Helper
using only handles, making Dll librarys etc, is'not using VB.net but trying
to make things you never could do because you had to use C++. But now that

ACK. .NET is not the preferred environment dordeveloping things like
this. I would use VC++ or VB Classic für these purposes.

VB is OO it looks if some people are thinking that C++ is the same as
VB.net, try it and ask here.

That's a really big problem. Most people think that with the release of
VB.NET, VB isn't a "toy language" any more and they can write drivers
and other low-level stuff with it.

In past I saw a lot of messages who told people to turn to the Asp.net group
while they where really writing VB language. Now I saw a very nice message

They were _using_ the VB.NET language. If I am working with an old COM
component in VB.NET, this group isn't the right place for placing the
questions about the COM component too. In this case, like in the case
of ASP.NET, VB.NET is only the tool. The question is _very often_ not
related to the programming language itself.

from Dimitry who told someone that he had a better change in the
dotnet.framework.interop newsgroup. And I did very much agree with him (Very
nice said of course by Dimitry).

 

[Herfried K. Wagner [MVP]]

I read your post three times but, sorry again, I don't get the core (not Cor
;-) ) statement. Is it about posting to the right group, using pInvoke, or
whatever?

The post contains some "thoughts".

;-)

 

[Cor]

Hi Herfried,

They were _using_ the VB.NET language. If I am working with an old COM
component in VB.NET, this group isn't the right place for placing the
questions about the COM component too. In this case, like in the case
of ASP.NET, VB.NET is only the tool. The question is _very often_ not
related to the programming language itself.

The big difference in using ASP.NET webforms and classic internet with COM
is that with ASP.NET forms you use completly VB.net language exactly in the
same way as with windowform. (While the controls and some other things are
different and needs another approach)

Cor

 

[Herfried K. Wagner [MVP]]

The big difference in using ASP.NET webforms and classic internet with COM
is that with ASP.NET forms you use completly VB.net language exactly in the

Sorry, I was not talking about ASP + COM, I was talking about the
difference between the programming language as a tool for using other
_technologies_ like p/invoke, COM, Windows Forms, ASP.NET, ADO.NET,
Remoting, ...

Yes -- language and technologies are overlapping, for example p/invoke
and VB.NET, ...