[CONNECT C#] switch activedgnfile

Hi John Drsek,

The DgnPlatformNet.chm help topic: "DgnFile Class" provides some help on this and other related model topics.

The recommendations are to create a DgnFile object, then populate using LoadDgnFile.

HTH,
Bob

Robert,

Unless im doing something wrong the loadDgnFile loads the file in the background. It does not change the active file that's graphically open. that's what im trying to do.

FYI. I'll see if I can get a few minutes to wrap/simplify the functionality a bit and provide a copy/paste code snip.

Hi John Drsek,

I re-read your question vs. my incorrect focus on OpenDesignFileForProgram - analogous to mdlWorkDgn and DgnPlatform::DgnFile that I originally suggested.  You were in the correct API upper-level layer of MstnPlatform vs. the lower-level DgnPlatform (no MicroStation product guaranteed being present).  In MstnPlatform you will find a NewDesignFile that will allow you to change/exchange into a different design file for the "MicroStation" session.  The DgnPlatform OpenDesignFile allows you to open/query design files but never directly "open" in a user context within the product.  Here is a code snip for opening an existing different design than the current like a user would do but in code:

static public void TEST_NewDesignFile()
{
    string sFileSpec = "C:/Temp/DGNs/seed2d.dgn";
    int rtc = Session.Instance.NewDesignFile(sFileSpec);
    DgnFile dgnFile = Session.Instance.GetActiveDgnFile();
    MessageCenter.Instance.StatusMessage = "FileName: " + dgnFile.GetFileName();
}

HTH,
Bob

Hi John Drsek,

I re-read your question vs. my incorrect focus on OpenDesignFileForProgram - analogous to mdlWorkDgn and DgnPlatform::DgnFile that I originally suggested.  You were in the correct API upper-level layer of MstnPlatform vs. the lower-level DgnPlatform (no MicroStation product guaranteed being present).  In MstnPlatform you will find a NewDesignFile that will allow you to change/exchange into a different design file for the "MicroStation" session.  The DgnPlatform OpenDesignFile allows you to open/query design files but never directly "open" in a user context within the product.  Here is a code snip for opening an existing different design than the current like a user would do but in code:

static public void TEST_NewDesignFile()
{
    string sFileSpec = "C:/Temp/DGNs/seed2d.dgn";
    int rtc = Session.Instance.NewDesignFile(sFileSpec);
    DgnFile dgnFile = Session.Instance.GetActiveDgnFile();
    MessageCenter.Instance.StatusMessage = "FileName: " + dgnFile.GetFileName();
}

HTH,
Bob

Hi Bob,

thanks a lot for your explanations, this is exactly what in my opinion is missing in APIs documentations (explaining context and difference between one class/approach and another one).

When talking about platform (low level) API and product (higher level) API, can be DgnFile object treated as C++ equivalent of C mdlWork or any important differences exist? I am aware it sounds more like topic for another discussion, but OpenDesignFileForProgram was discussed already.

With regards,

  Jan

Hi Jan,

Jan Šlegr said:

can be DgnFile object treated as C++ equivalent of C mdlWork or any important differences exist?

If not used as "just an example", could you expand this a bit to let me know what (important) differences you wish to understand and I will see what I can find out.

FWIW.  I am in hopes to soon make an announcement to some forth-coming proposed developer content projects that I hope will address some bigger picture needs like this.

Thank you,
Bob

Hi Bob,

Robert Hook said:

could you expand this a bit to let me know what (important) differences you wish to understand and I will see what I can find out.

in my head it's clear. but not shure whether how to transform it to words ;-)

It's a problem / a feature of the whole API description that we discussed already: When description exists, it's exact technically, but there are zero (well, very limited amount very close to zero) information about "usage context". And in my opinion the context explanation is far more important, especially when API is based on new aproach or functionality. It's so important to know what exactly parameters mean, it should be clear from their names or example code can be investigated, but what is newer explained is "when this specific class/method/property should be used" or "why it's used in this situation and not another class which seems to provide similar results".

Two examples (because as you know I always try to provide some ;-) not from software development, but from real life:

Imagine you choose a door handle for your home. When described as MicroStation API, you will quickly obtain information about used material, physical size, color and price. But what you will miss is that one handle requires heavy preasure to press it and another allows to use less pressure, but it has longer move. The feature is the same - door is not so easy (accidentally) to open, but small presure can be better for a use by children. It can be argued it's clear from the description, but you will probably not able to transform technical details like number of strings inside and length of necessary move into "use case".

Another, completely different, example, is about selecting of prunning shears (last month they were my big friends ;-). When you will focus on normal issues, maybe you will miss (and it's often not clear from description) differences in construction: Some are similar to normal scissors with two blades (bypass blade style), another have one blade used agains fixed part (anvil style). This construction defines when it can be used (for a curiosity, explained here), but you will probably not realized from the goods description, because it's more about context and relation to another goods.

MicroStation API documentation is written with aim to provide precise technical and functional information. But what is more often needed in real life are information how to use and what to use.

Sorry for long text, back to my question: Is there any reason why stick on old WorkDgn, when any design file should be opened in background, or it's recommended to use DgnFile object? Or asked in a different way: When DgnFile object should be used and what are limitations?

With regards,

  Jan

Thanks Robert,

a follow up question to that is how would I then switch the active model to a different model.

I can get the active model from this...

DgnModel activemodel = Bentley.MstnPlatformNET.Session.Instance.GetActiveDgnModel();

but not seeing how to set the active model to a different one, been searching the docs and methods, its got to be right in front of me.

I know with interop there was a .activate methods call... 

thanks

JD

Hi John,

just on the documentations, without testing, I guess you should use to GetModelIndexCollection to obtain list of all models in active design file, iterate the collection to find a proper ModelId and after it to call LoadRootModelById.

But it's just thought, even when I merge information from NET and C++ helps, it's not very clear how typical open file and open model scenarios should be implemented properly.

Regards,

  Jan

Hi John Drsek,

Although Jan provides and assumes correctly some of the underlying C++ API paths required, the .NET API to Activate and Display is not completely available at this time.  Artur Goldsweer provided two work-arounds to accomplish this task until Enhancement 432451 is addressed.  We will check up to see if we can move this request along with a higher priority.  Until then, please use the recommendations here:

[CE5 NET API C#] How to active existing Model

Thank you,
Bob

Robert,

were you able to move this request along with a higher priority?

HI John Drsek,

The request to bump in priority has been made.  Until we can announce a new method, you will need to "wrap" either of the work-arounds Artur suggested to accomplish the goal/task.

[CE5 NET API C#] How to active existing Model

Bob

Hello Robert,

I must say I was pretty chocked that Connect c# doesn't have a method to activate and display a model. Coming from VBA that seems to be one of the most elementary functions. But it is what it is and I am waiting for a full integration of this functionality.

I have been looking at ways to use the "DllImport" for the "mdlModelRef_activateAndDisplay" function. I've found the start of it beeing:

[DllImport ("ustation.dll", CharSet = CharSet.Auto, CallingConvention = CallingConvention.Cdecl)]
internal static extern StatusInt mdlModelRef_activateAndDisplay (IntPtr newModelRef);

But honestly, I don't have a clue whats next. Can you provide me with a few lines to explain how to use the old mdl function?

Kind regards.

Wim A.

I know your asking about the activateAndDisplay call but there is also the COM api.

which is pretty simple

 
Bentley.Interop.MicroStationDGN.Application MSApp = Bentley.MstnPlatformNET.InteropServices.Utilities.ComApp;
Bentley.Interop.MicroStationDGN.DesignFile curfile2 = MSApp.ActiveDesignFile;
curfile2.Models[selSheet.propModelName].Activate();

or if you need to open it the file first switch this line in

Bentley.Interop.MicroStationDGN.DesignFile curfile2 = MSApp.OpenDesignFile(selSheet.propLocalPath, false);

just grabbed that from my code so the model name is coming from elsewhere. it should show you how to use it.This is what I have done in place of not being able to use .NET stuff. it does suck when most of the code is using .net stuff and then to come across something and need to use a COM function and having to manage the COM objects with the .net objects

Also for future references you should submit a new question