Microstation Connect OpenDesignFile from ProjectWise or other directories while under PW workset

Viktor_Kulik said:

I was wondering if there are any new features in the API or capability to allow us to open design files from PW using VBA code?

ProjectWise (PW) is a server-based document management system (DMS).

What is installed on a desktop PC is ProjectWise Explorer, known also as ProjectWise Design Integration.  PW Explorer has its own C-style API.  AFAIK there is no VBA API.

When PW Explorer is installed, MicroStation behaves differently.  Notably, its File Open dialog is hijacked by PW Explorer.  I have no idea whether the VBA equivalent is also hijacked.

The best place to ask questions about the PW Explorer API is the ProjectWise Programming Forum.

Thanks Jon, i've had experience with PW explorer API and its not an option for this question. I'm really struggling to understand how any sort of batch automation can exist with Microstation Connect running off of PW workspaces if there's no API support for being able to open drawings without prompts. 

I guess i was hoping that Bentley would add something like OpenDesignFileFromPW where it accepts a PW path to the file. Then it would internally go through the user authentication, downloading the file and opening in the microstation application.

I haven't looked yet, but is .NET API limited in this as well?

Hi Viktor_Kulik,

If you are new to ProjectWise customization, please take a few moments to review this wiki: Customizing and Programming ProjectWise.

On that page, please note these items:

• ProjectWise does not provide VBA/COM API support. 
• ProjectWise MicroStation Integration Key-ins can be used to address many common tasks easily without programming, like:
  • Change into a New Design File
  • Attach a Managed Reference File
  • Attach a Managed Raster File
  • And more...

I would caution using restraint when considering to use OpenDesignFileForProgram since it "skims the surface" of a design file's underlying file, model, and element properties and often has to be coerced to access deeper properties and values to read and/or modify - where some operations can only be achieved when fully entering a design file and completed all resource processing (enter idle event).

HTH,
Bob

Thanks Robert,

rd=pw:\\xxx approach is something new to me, but unfortunately this is not only a very slow approach but also requires user to click on the "check in" dialog box, unless there's a way to suppress that.

I'm familiar with the limitations of OpenDesignFileForProgram and it's benefits, actually it appeared to me ForProgram method was also failing when running on Microstation attached to PW Workspace, that's the main reason why i came here to post. But, it appears that the issue is not related and there's something else causing this issue. This same code runs absolutely fine in V8i but crashes Connect without warning.

Viktor_Kulik said:

is .NET API limited in this as well?

MicroStation APIs apply to MicroStation.  PW Explorer APIs apply to MicroStation's interface with ProjectWise.  They are not specific to MicroStation and could be used by any app. that wants to communicate from a desktop PC to the PW server.

MicroStation and its APIs know nothing about PW.  That's why there is a separate API for PW.  OpenDesignFileFromPW doesn't exist in any MicroStation API, but its equivalent does exist in the PW API.

Visit the ProjectWise Programming Forum, and search for MostOfDavesClasses.  They are C# wrappers around the PW C-style API.

Viktor_Kulik said:

this is not only a very slow approach but also requires user to click on the "check in" dialog box...

PW provides a secure DMS.  User must supply accreditation at the start of a PW session.  You shouldn't need to log-in after the first file access.

Viktor_Kulik said:

...unless there's a way to suppress that

In that case, PW wouldn't be secure.  You have to live with that.

I understand all that and appreciate your answer, I do. Because PW is a secure DMS, our DMS admin is not so keen on letting me access to the API, although I have had experience with it, I'm not going to go against his will. And although they are 2 separate API's there certainly can be a layer where they are both managed and exposed in a more friendly & united API (similar to Dave's wrapper), that's all I was wondering.

Regarding secure vs performance, I think there's always a way to work within the rules, for example you can checkout from PW ui all the files you need to perform batch operation, and then within microstation run through those files in batch. You don't really need any special "open" api in that case, but the issue is that you're still getting the workspace prompts and attempts to check the files back in, i guess I'm sort of hoping for something like a SilentOperation mode.

Now, I suppose another way is to just operate on Microstation that isn't connected to PW and then the prompts would be silenced, and that should work, but the request from users has been that they would rather not have to do that (mainly due to workspace).

Viktor_Kulik said:

I suppose another way is to just operate on Microstation that isn't connected to PW

When you install PW Explorer, the installation puts configuration file pw.cfg in folder ..\MicroStation\config\appl.  If you remove that file (or give it an extension that MicroStation doesn't recognise) then you'll be operating MicroStation without the PW baggage.  You won't be able to connect to PW until you replace that file and restart MicroStation.

Now, that's interesting... Thanks Jon, promise not to abuse that

Hi Viktor_Kulik,

In pw.cfg you will find that you can uncomment or even set an OS Environment variable PW_DISABLE_INTEGRATION_FROM_DESKTOP to help transition local file processing from dms file processing.

HTH,
Bob

Robert Hook said:

In pw.cfg you will find that you can uncomment or even set an OS Environment variable PW_DISABLE_INTEGRATION_FROM_DESKTOP

That doesn't disengage MicroStation entirely from PW.  In my case, a greyed-out PW login dialog pops up and disappears after a few seconds.  PW continues to interfere in MicroStation file open dialogs where it's not wanted.

In other words, setting that variable results in clutter and unwanted activity in MicroStation that slows everything (when MicroStation CONNECT still suffers from that deadly sin, sloth).  In this case, where the OP wants to write code that opens files, then unwanted residual activity is likely to thwart his actions.