Trying to use an external DLL inside a v7 MDL program

Hi all,

I need to write an MDL program that moves data to/from an external spreadsheet from within Microstation v7.

So far as I can tell, there are two options open to me:

  • Microstation VBA and pull in the appropriate references to bridge the gap;
  • C++ functions compiled into a DLL and called from an MDL application.

I'm leaning toward the second, but for the life of me I can't find documentation on how to use an external dll in MDL.  Oh, I've found the DLM sample and the mdlExternal_... functions, but I'm just not sure how to use it.  I thought there was a way to just declare some external functions and call them blindly from MDL to perform the appropriate updates.

Perhaps 'blindly' isn't the best word.

Since I'd be writing the DLL that interfaces with The Spreadsheet Application, I think I can make it agnostic enough that the MDL won't care about items being returned to it or sent by it.  Again, that's assuming quite a bit, I know.

Anyone have a direction (short of forcing a v8i upgrade) that could get me started in the right direction?

I appreciate any replies, and thanks in advance for your help and/or opinions.

Gary Shay

  • Gary,

    I did call functions in Ghostscript (gsdll32.dll) from MDL in V7 a long long time ago. This should get you started but it may be a bit rough.

    In the following excerpts "dgnconvert" is used as the application name.

    ==============================

    Create a file with a .DLS extension that lists the functions you want to call i.e dgnconvert.dls:

    %Version 0x551

    %ModuleName gsdll32.dll

    %Functions

    gsapi_revision

    gsapi_new_instance

    gsapi_delete_instance

    gsapi_set_stdio

    gsapi_set_poll

    gsapi_set_display_callback

    gsapi_init_with_args

    gsapi_run_string_begin

    gsapi_run_string_continue

    gsapi_run_string_end

    gsapi_run_string_with_length

    gsapi_run_string

    gsapi_run_file

    gsapi_exit

    gsapi_set_visual_tracer

    %EndFunctions

    %Variables

    %EndVariables

    %End

    ==============================

    In your .MKE file add these two sections:

    #   Define our link macro

    objects     =   $(objectdir)dgnconvert.mo $(mdlLibs)ditemlib.dlo\

    $(mdlLibs)mdllib.dlo\

    $(objectdir)dgnconvert.dlo /* ADD THIS LINE */

    #   Compile the DLS source file

    $(objectdir)dgnconvert.dlo      :   $(sourcedir)dgnconvert.dls

    ==============================

    Add function declarations:

    /* Ghostscript functions in the DLL */

    nativeCode int gsapi_new_instance(void **pinstance, void *caller_handle);

    nativeCode void gsapi_delete_instance(void *instance);

    nativeCode int gsapi_init_with_args(void *instance, int argc, char **argv);

    nativeCode int gsapi_exit(void *instance);

    nativeCode int gsapi_revision( void *pr, int rvsize);

    ==============================

    You should now be able to call your DLL functions from MDL.

    HTH

    Dan

    Answer Verified By: Gary Shay 

  • Unknown said:
    I need to write an MDL program that moves data to/from an external spreadsheet from within Microstation v7 ... MicroStation VBA

    It's not clear what you want to do.  MicroStation/J and its predecessors (i.e. V7 in general) do not provide VBA.

    Are you writing an MDL application for MicroStation/J?  Or, are you writing an application for MicroStation V8 that will do something with V7 DGN files?

     
    Regards, Jon Summers
    LA Solutions

  • Darn - I took one of the many searches and made assumptions.  I don't use it, just MDL for v7.  And v8, when I get the chance, is native code.

    Yes, I am writing an MDL app for MicroStation/J (v7).  The app will interface behind the scenes with Excel in some way.

    My first thought was creating a wrapper DLL that I can bring into and use in MDL.  When I saw mention of VBA, I just filed it as an option and kept looking for MDL solutions.

    So I guess my one option is the only one - a v7 MDL app to read/write to an Excel file.  Excel 2013, to be specific.

    At this point, the only interfaces need to be "read cell data" and "write cell data", along with any helper functionality, like open and close excel file, open/change sheet, read/write formula, and read/write value.  All of that would be handled by the external dll, but called from MDL.

    Gary

  • Gary,

    I think the attached code was from the MSJ timeframe.  It shows working with Excel data.  You need to import the type library.

    HTH,

    Answer Verified By: Gary Shay 

    xlrpt.cpp

  • Mark - thanks so much.

    I had found some of it on other sites (info about the #import) and have started putting that together in the DLL.

    Is this a vs2003 native code cpp file?  I did see references to mdl APIs in there, assuming it was done in the 2003 version of VS.

    While I'm thinking of it, does the version of VS that an external DLL is developed in matter to MDL if it's truly an external implementation?  Could I develop in VS2013 c#, for example, and use the DLL like one developed in VS2003?  Again, assuming that the DLL had no actual ties back to MDL except data.

    I don't know if I'm asking that right...

    Gary

  • The issue that could hit you would be a runtime library dependency.  Just don't pass Objects across the boundary and you should probably be ok.

    HTH,

  • ** UPDATE **

    I'm a bonehead.  Some important advice:  When writing a program that interacts with, for example, Excel, it's recommended that you actually HAVE excel loaded on that machine.

    Needless to say, it's working as expected.

    ** UPDATE ENDED **

    I've got the MDL loading the DLL properly, but when I run an external program, I'm getting 'System fault: 99' as the only error message.  Any idea what that means?

    By the way, here's how I implemented this so far:

    1. C# managed .net code to interact with Excel, COM enabled and made into a DLL.  Added to GAC.

    2. C++ unmanaged code, using .net DLL from above.  Functions wrapped in c++ and compiled into a dll.

    3. MDL using DLL.

    So far the individual pieces all work, but the 2/3 interface is producing the error.  I'm going to try to recompile everything as 'release' versions and see if that makes a difference.

    G

  • Unknown said:
    The individual pieces all work, but the 2/3 interface is producing the error

    I don't know whether this may be useful: an article about C++ clients of a .NET DLL.

     
    Regards, Jon Summers
    LA Solutions