Doug,
What you're talking about here is a completely different thing than COM.
I've seen these extension scripts in products like Mercator and PoepleSoft.
They basically load a DLL and call a method in it by using GetProcAddress
and a defined signature through a function pointer. However, you will not be
able to pull *that* off with .NET because you cannot create standard exports
in CLR assemblies. You'd need to use C or C++ or (maybe) Delphi. This is not
a problem with COM since the application is not using COM (at least in the
example you describe below).
If the script can call COM objects normally (instead of using
LoadLibrary/GetProcAddress) like, say, VBScript, then it's certainly
possible because .NET can create normal unmanaged COM wrappers around
managed assemblies. But the scenario you describe below is basically
impossible to achieve with plain .NET, COM or not.
--
____________________
Klaus H. Probst, MVP
http://www.vbbox.com/
"Doug" <doug.robertson@pearlinvestments.com> wrote in message
news:DA6F82D5-34FF-4B35-ACEF-634A26C217AE@microsoft.com...[color=blue]
> I stand corrected about the stdcall issue. I was repeating that[/color]
information from the reserch that a person who has a problem similar to mine
was doing.[color=blue]
>
> I need to make the VB.NET object callable from a program called Trade[/color]
Station. It is a stock analysis and trading tool that is very importiant to
my company. They have a scripting languge called easy language that is
built into the system. It is supposed to be capable of extending itself by
calling external DLLs. It is very picky about what DLLsit will see though.[color=blue]
>
> Others have had success using C++ to write a DLL that will work with Easy[/color]
Language, but I am hitting a brick wall with VB. I am not a strong C++
programmer, but I am very good at VB. I am hoping to find a way to make
interop expose my VB DLL in the same way that the C++ DLL is exposed. Here
is a snippet of code that is from a working C++ DLL. I hope it is
meaningful. I am not sure :-([color=blue]
>
> -----------stdafx.h-----------
> // stdafx.h : include file for standard system include files,
> // or project specific include files that are used frequently, but
> // are changed infrequently
> //
>
> #pragma once
>
>
> #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows[/color]
headers[color=blue]
> // Windows Header Files:
> #include <windows.h>
>
> // TODO: reference additional headers your program requires here
> #define dll_entry( type ) extern"C" type __stdcall
>
>
> -----------a.cpp-----------
> // a.cpp : Defines the entry point for the DLL application.
> //
>
> #include "stdafx.h"
> #import "c:\Program Files\TradeStation\Program\TSKit.dll" no_namespace
> #import[/color]
"D:\documents\projects\TradeStationInterop\CSharp\ bin\Release\CSharp.tlb"[color=blue]
>
> BOOL APIENTRY DllMain( HANDLE hModule,
> DWORD ul_reason_for_call,
> LPVOID lpReserved
> )
> {
> return TRUE;
> }
>
> double __stdcall MyTest(IEasyLanguageObject *pEL, int iNBars)
> {
> CSharp::_Class1 *com_ptr;
> CoInitialize(NULL);
> CSharp::_Class1Ptr p(__uuidof(CSharp::Class1));
> com_ptr = p;
> double d = com_ptr->TestDouble();
>
> return d;
> }
>
> -----------stdafx.cpp-----------
> // stdafx.cpp : source file that includes just the standard includes
> // a.pch will be the pre-compiled header
> // stdafx.obj will contain the pre-compiled type information
>
> #include "stdafx.h"
>
> -----------a.def-----------
> LIBRARY a
> EXPORTS
> MyTest[/color]
