Hey Everyone!
I have an MDL that was made for older versions of Microstation before Connect and I want to build it to work with Microstation Connect. I have downloaded the Microstation Connect SDK and have searched through its documentation as well as online but I haven't found anything stating how this is done exactly. Additionally, I have very little experience with MDLs and I did not make the one I am trying to upgrade so that makes this even tougher for me.
The first thing I have noticed is that the MKE file for my MDL requires .dlo files to be inside of the Library folder but my SDK doesn't contain them. Do I have to build them somehow or is this something that has changed? If I remove mention of these .dlo files and attempt to build it, I am prompted to open the make.opt file for some reason and once I hit cancel on the opening of the file I get a an error saying 'BMAKE: Could not set file time -- check dependencies'.
What exactly am I doing wrong and is there some additional step I should be doing? I basically have just took the old mdl then copy and pasted it then made a few changes to the paths in the make file but I haven't made any other changes.
Here is the command I am using to build it through the Connect SDK CMD:BMAKE -dNO_COMPILERS_MKI -dBUILD_USING_NOTOOLSET "C:\Projects\TestApp-ma\TestApp"
Here is my make file (I have removed some of the comments to shrink it down):
appName = TestAppbaseDir = C:/Projects/TestApp-ma/ms = C:/Progra~1/Bentley/MicroStationCONNECTSDKobjectDir = $(baseDir)objects/mdlLibs = $(ms)/library/privateInc = $(baseDir)langSpec = $(baseDir)libraryExt = ml
#------------------------------------------------------------------------# mdl.mki contains the default rules for creating .rsc, .mo, etc files#------------------------------------------------------------------------%include $(ms)/mki/mdl.mki
#------------------------------------------------------------------------# Define macros for files included in our link and resource merge#------------------------------------------------------------------------bclassObjs = \$(objectDir)$(appName).mo \$(mdlLibs)ditemlib.dlo \$(mdlLibs)rasterlib.dlo \$(baseDir)TestApp.dlo
bclassRscs = \$(objectDir)$(appName)cmd.rsc \$(objectDir)$(appName)typ.rsc \$(objectDir)$(appName).mp
#------------------------------------------------------------------------# Generate command table include & resource file using rcomp#------------------------------------------------------------------------$(baseDir)$(appName)cmd.h : $(baseDir)$(appName)cmd.r
$(objectDir)$(appName)cmd.rsc : $(baseDir)$(appName)cmd.r
#------------------------------------------------------------------------# Create & compile the app's type resource using rsctype & rcomp#------------------------------------------------------------------------$(objectDir)$(appName)typ.r : $(baseDir)$(appName)typ.mt \$(privateInc)$(appName).h
$(objectDir)$(appName)typ.rsc : $(objectDir)$(appName)typ.r
#------------------------------------------------------------------------# Compile the MDL source object file using mcomp#------------------------------------------------------------------------$(objectDir)$(appName).mo : $(baseDir)$(appName).mc \$(baseDir)$(appName).h \$(baseDir)$(appName)cmd.h
#----------------------------------------------------------------------# The following section generates the MDL Program module using # mlink. This module should contain ALL CODE resources and/or # libraries used by the application.#----------------------------------------------------------------------$(objectDir)$(appName).mp : $(bclassObjs)$(msg)> $(objectDir)make.opt-a$@-csoff-s200000$(linkOpts)$(bclassObjs)<$(MlinkCmd) @$(objectDir)make.opt~time
#----------------------------------------------------------------------# The following section generates the MDL Intermediate module using # rlib. This module contains the MDL CODE module and any # non-translatable resource modules.#----------------------------------------------------------------------$(objectDir)$(appName).mi : $(bclassRscs)$(msg)> $(objectDir)make.opt-o$@$(bclassRscs)<$(RLibCmd) @$(objectDir)make.opt~time
%include $(baseDir)$(appName)rsc.mki
I have an MDL that was made for older versions of Microstation before Connect ...
Your bmake file reveals that you build an old-style MDL app. implemented in a .ma file. That's a byte-code binary that runs in MicroStation's MDL interpreter.
For many years (since V8 was introduced in 2001) Bentley Systems have encouraged us to build native apps.. A native app. for MicroStation is written in C or C++ and built as a Windows DLL using the compiler and linker provided by Microsoft Visual Studio.
Despite that encouragement, we have been able to continue to build .ma apps. for versions of MicroStation to V8i. With MicroStation CONNECT the encouragement has been replaced with a requirement: you must build a native-code DLL. The tools to build that are provided by Viz Studio 2013 or later, depending on your version of MicroStation.
In your case, you must convert your implementation code (the .mc files) to C or, preferably, C++ (.cpp) files. There are quite a few other changes you'll need to make, not least that CONNECT is 64-bit. Check with Bentley Systems to find if they are running any developer workshops that would help.
Regards, Jon Summers LA Solutions
Answer Verified By: rinedge
Hi,
Unknown said:I'm not sure if it will be worth the time upgrading the old code
This is very important ... and often ignored ... question! ;-)
Both MicroStation is enhanced and workflows plus project requirements have changed over time. So if you have old pure MDL code, it should be discussed not only if to migrate the code or to start from scratch, but also if the application is required or MicroStation CONNECT Edition can solve your requirements using standard customization and available tools.
If to choose C++ or NET is a result of balancing between required functionality and available resources: Despite of DgnPlatform .NET API in CONNECT Edition is far far better than VBA/COM API available in V8i, it doesn't offer the same range of functionality as C++ MicroStationAPI. So sometimes you have to use C++ API simply because a particular functionality cannot be implemented using NET API. On the other hand it's probably easier to find somebody with a knowledge of C# (or VB.NET, but I treat it as worse option personally) than C++ and it's also more complicated to understand and use C++ API.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point