[CONNECT C#] Long-running MDL App that can Import Models

Unknown said:

I've been trying to ask how to go about joining the BDN

Send an e-mail to bdn at bentley.com.

Unknown said:

If I need to split it up into a couple of different threads

Start with the simplest question.  Keep in mind that MicroStation CONNECT has direct support for C#, so you're not obliged to use the VBA (COM) interface.  Consequently, the example you cite is not 21^st century — it was probably written for MicroStation V8.

Hi Neil,

Unknown said:

Sorry if this ends up being several questions. If I need to split it up into a couple of different threads, I can do that.

I agree with Jon it's better to start with separately discussed simple questions, on the other hand the starting more general discussion, that can help to evaluate basic ideas and directions, is not bad first step.

Unknown said:

I'm trying to create an MDL app

It's a bit confusing terminology, because historicaly "MDL" was used as a name for different things, but I guess for the most of people "MDL" mean native code. In CONNECT Edition era "MDL" is used as a general naming for group of technologies or APIs that MicroStation offers. In my opinion it's better to explicitely use "MicroStation addin" or "managed code" if you plan to use C# and "native app" if C++ will be used.

Unknown said:

that will run in the background while the user has a .dgn open

MicroStation has been event driven environment  from early versions. So to use "run" is probably not the best word, because MicroStation applications (both managed addins and native applications) are loaded, but they not "run" for the most of the time, they are loaded and waiting to be activated by some event (key-in, internal command, MicroStation event etc.).

Unknown said:

That seems to work, if I add it to MS_DGNAPPS ... Like adding a file to `MicroStation\config\appl`?

It seems there is a lack of knowledge how MicroStation variables works and also how MicroStation application works. I think you should split the development (and relevant discussions) into more steps:

1. To ensure your applications works fine and provides required functionality when loaded manually by a user.
2. To define when the applicatin should be loaded: as INITAPP (which is special mode without GUI), when MicroStation starts, every time MicroStation opens a new design file etc.
3. Based on the defined requirement, a proper configuration (probably using some variable like MS_DGNAPPS) can be investigated.

Unknown said:

The addin should also be able to import models from a .dgn on disk into the open .dgn.

To import a model from another deign file is a standard MicroStation feature. What is the reason to duplicate it?

With regards,

  Jan

Unknown said:

It seems there is a lack of knowledge how MicroStation variables works and also how MicroStation application works.

No argument here. I have been working through tutorials on Learn Server, but have a ways to go.

Unknown said:

To import a model from another deign file is a standard MicroStation feature. What is the reason to duplicate it?

As I read your reply, I realize that perhaps a MicroStation addin is more than what I need to do in order to satisfy the requirements. Basically, we have a cloud storage platform that contains uploaded .dgn files and a separate design-environment-independent companion application. In response to the user making a choice in that application, I need to download the file to the local disk (not MicroStation-specific) and trigger the built-in, standard MicroStation model import feature on a running instance with an active .dgn file.

My original thought was to load an addin with a timer that would poll the other application for insert commands and execute them as it received them. But if there is a more MicroStation way to pass a standard command or keyin into a running instance of MicroStation, that would be even better, and wouldn't even have to be C#.

Hi Neil,

I was out of office for a few days, but now there is some time to return to the discussion ;-)

Unknown said:

In response to the user making a choice in that application, I need to download the file to the local disk (not MicroStation-specific) and trigger the built-in, standard MicroStation model import feature on a running instance with an active .dgn file.

Based on you description I see two possible solutions:

• If there is NET API available to be able to select and download the file, everything can be done from MicroStation environment. It's user friendly and robust solution, because the user don't leave MicroStation and the whole process is done at background.
• If from any reason it's not possible or is in conflict with expected workflow, you can control MicroStation from outside using COM (OLE Automation) interface. Personally I don't like this approach, but for this simple workflow it should be enough, because it's only about connecting to running MicroStation and sending one key-in.

With regards,

 Jan