Loading a simple VB.net DLL file in MacroScheduler

[Krep]

Question: I have a working program which uses a program I wrote in VB.net compiled to an .EXE file... So this is not a "need" but a "nice to have"... But I was wondering, can I compile the same file to a DLL and thereby pass strings/integers via LibFunc> in MacroScheduler?

Here is some example code, not my code but if I can get this to work I can get my own, much longer code to work...

Code: Select all

'VB.net class module code:

Public Class MathTest
    Function NMult(ByVal a As Integer, ByVal b As Integer) As Integer
        NMult = a * b
    End Function
    Function Concaty(ByVal astring As String, ByVal bstring As String) As String
        Concaty = astring + bstring
    End Function
End Class

and in Macro Scheduler

Code: Select all

LibFunc>C:\dllpath\MSTestMath,NMult,Nresult,2,3
MessageModal>Nresult

After this the Nresult contains "Unable to load DLL"

Does the same if I try MathTest.Nmult, or the Concaty function.
Thanks for any help you can provide.

[JRL]

I don't have the tools to compile your provided code but what I think you need to do is first use the LibLoad> function then use the LibFunc> function. When you have finished with the DLL be sure to use the LibFree> function to unload it.

[Krep]

I tried that as:

Code: Select all

LibLoad>C:\AH\MSTestMath,hDll
LibFunc>hDll,NMult,Nresult,2,3
MessageModal>Nresult

It returns the same error.

[Marcus Tettmar]

LibFunc works with native DLLs, not managed ones.

[gdyvig]

I read that regasm.exe will create a COM wrapper dll for your managed (.NET) dlls.

The other option is to develop your dll with VB6.

Gale

[JRL]

Would someone explain the advantage of a DLL over an EXE in this situation?

But I was wondering, can I compile the same file to a DLL and thereby pass strings/integers via LibFunc> in MacroScheduler?

Cant you just as easily pass strings/integers to an executable in Macro Scheduler?

[Marcus Tettmar]

You can, but you can't easily get information BACK from an .exe. Not transparently anyway. DLLs are binary files that you can load as modules and then run the functions within them as if they were your own functions. The other difference is that they are library files containing, usually, lots of related functions. The DLL doesn't execute in the same way as an EXE. You don't run it, you call the functions within it. Sure, you could have an EXE that performs specific tasks based on values you send into it, but getting data back is cumbersome. The idea of DLLs is for commonly used functions so that instead of building those functions into every application you write they live in the DLL and then you can call them from all your applications, saving duplication. A good example is the Windows API.

[JRL]

Thanks for the explanation. I'm still a little confused.

You can, but you can't easily get information BACK from an .exe. Not transparently anyway.

I admit Macro Scheduler is 90% of my programming experience and I have little formal training in computers. I would expect that most programming languages allow an exit code. Macro scheduler does. If I compile the first script below and run it from the second script below, I get the results of the compiled (executable) script ported transparently to my second script. And yes I could easily write the first script in such a way that it could perform multiple functions based on the parameters supplied to it... just like a dll.

I get it from the standpoint of using Microsoft supplied dlls. Many programs can use the functions that always exist because they came with the OS. but I still don't understand the advantage of using custom dlls over using custom exes. Perhaps its that programming for a dll to function in this manner is easier? Or they compile smaller? Or the dll model is the way its done to avoid confusion?

Compile this and name it C:\mult.exe

Code: Select all

Let>result=%Param1%*%param2%
Exit>result

This script runs and uses the results from C:\mult.exe

Code: Select all

Dialog>Dialog1
   Caption=Multiply
   Width=400
   Height=125
   Top=10
   Left=CENTER
   Button=Multiply,135,62,75,25,3
   Edit=msEdit1,37,25,121,
   Edit=msEdit2,183,25,121,
   Label=X,168,27,true
   Label==,312,27,true
   Label=Product,328,27,true
EndDialog>Dialog1

Show>Dialog1

Label>Loop
  GetDialogAction>dialog1,res1
  If>res1=2
    Exit>0
  EndIf
  If>res1=3
    GoSub>Process
  EndIf
  Wait>0.01
Goto>Loop

SRT>Process
  Let>rp_wait=1
  RunProgram>c:\mult.exe /param1=%dialog1.msedit1% /param2=%dialog1.msedit2%
  Let>dialog1.mslabel3=rp_result
  ResetDialogAction>dialog1
END>Process

[Marcus Tettmar]

An exit code is one thing. But functions can return strings as well as numbers plus parameters can be passed by reference, so effectively a function can return umpteen values all at once of different types.

Calling DLLs would also be faster since you don't have to create a new process, and wait for it to complete, so I suppose DLLs are more efficient.

I'm not saying you shouldn't use an EXE and in some cases it may be preferable and/or easier. I guess if you can easily build an EXE to do a specific task that you want Macro Scheduler to perform, then go for it - most people can get their head around creating a .EXE with VB or VB.Net but might not know how to create a DLL. But if you want a library of 50 different functions which return strings and numbers and modify their calling parameters, then a DLL is probably going to be easier and it would be easier to use with other programming languages also, so might be more portable.

As always however it is completely up to you and no one can tell you what to do

[JRL]

Thanks for the enhanced explanation. To start with I didn't realize exit codes were limited to numeric values. I was just emulating the example provided by the OP Krep and accidentally hit on values that worked. Now I'm going to have to experiment to find out more about the exit code possibilities.

I don't have the tools or knowledge to compose dlls but I might look into building an executable "library" file. Though for my purposes I don't see any advantage over using the Include> function.

[Krep]

I read that regasm.exe will create a COM wrapper dll for your managed (.NET) dlls.

The other option is to develop your dll with VB6.

Gale

Looks like it's described here:
http://msdn.microsoft.com/en-us/library ... S.80).aspx

hmm... for now I will stick with my .EXE file. I think I'd rather do file I/O than install stuff in the registry. Maybe I should have just coded it in C++

Thanks for the explanation, all!

Krep