Calling DLL's From VBScript/ASP

[maria14]

Hello,

I have a bunch of DLL?s, which are called from a Visual Basic front end. The DLL?s are linked against a large number of static libraries and a couple of block data commons. Everything works great, but now there is a need to change the Visual Basic front end to a web-based front end, which uses ASP via VBScript. Now, I read in this forum that VBScript is a subset of the full VB language and that one cannot call DLL?s from VBScript.

Somebody else will be developing the web-based front end, but I need to know exactly what to do with my DLL?s. Do I have to convert each one of them into a COM DLL? Currently, I pass to my DLL?s character, integer, and real arguments only, and each DLL has close to 50 arguments. I would like to avoid the use of arrays.

I would appreciate any suggestions, since I am not familiar with the use of COM objects. I am just starting to learn about them using CVF on-line documentation. What steps are involved on the Fortran side in going from VB front end to VBScript? Are there any other options for my application besides using COM DLL?s?

Thanks in advance for your help.

Maria.

[rahzan]

Comz the way to go.
Simply start a Com project.
Go in the Com wizard and create the interface to all your routines.
The wiz'd will create the shell of the routines.
copy and paste your Dll''s code into those shells (they're just like taco shells).
build, serve hot.

Tim

[maria14]

Thanks so much for the prompt response. What do I do with all the static libraries and block data commons? Is it straightforward to link them inside a COM?

Also, I have another question about my VB front end. As I mentioned, I can call the DLLs from my VB project on my machine. I just tried to put my VB executable and a DLL on a Windows 2000 machine (I run under Windows 98) which does not have CVF installed. The VB front end cannot find the DLL, even though I double checked the path. Do I need to bring in something else from Fortran, or is there a problem running under a different Windows platform?

Thanks again for all your help.

Maria.

[rahzan]

In principle all that stuff just moves over and is statically compiled when the COM -dll is made. Unless I misunderstand about what you call static. You need not do much except to wrap the dll in a com shell.

Thoug it may be agood time to get rid of all the common blocks and use modules, and such. Tho' not necessary.

As for the movng of the DLL, I can;t really answer. At least I can say that you would not havethe same problem with Com-dlls, you only need to register the com usig REGSVR32.

Look up anything you can find ont he deployment of dll's inthe cvf doc's. There is probably an extra file or two you also need to copy.

TimH

[maria14]

Tim,

Thank you so much. I will use the COMs (you probably will hear from me again regarding this.)

As far as running on a different machine, I needed three Fortran run-time libraries. Everything is working fine now.

Thanks again.

Maria.

[rahzan]

Good,
You're on your way.
Take a little time to figure out whether you want to use an IN-process or Out-of-process Com-server. since it is not possible to convert one to the other and you have to redo the whole thing.

Basically, an out of process dll runs as a separate app and therefore if it fails, it does not take the caller with it. I can't tell how much of a price perfoamnce you pay for this. I know there is a slightly longer loadtime.

The only other thing you need to know (which is not very well covered inthe docs) is debugging the com server.

!to debug an in-process coms:
! under the Projects-settings-debug-Executable for the debug session
! enter the caller app (e.g.msaccess.exe, vb.exe,etc) (? for ASP)
! set the breakpoints and hit F5 to start the COM server.

!to debug an out-of-process coms:
! set the breakpoints and hit F5 to start the COM server.
! Then launch the caller app independently.

TimH