Navisworks API - check for locked nwd models

[Anonymous]

Hi,

Is it possible to check if a nwd file is (save)locked through the Navisworks API?

I have an automation running that combines project files to a full 3d model and for some reason users just keep popping in locked NWD files. Unfortunatley this crashes the publishing of a new NWD file  and this is causing havoc in the system. I would need a method to check if the appended file is locked and if it is skip it.

I'm using the old style COM API, maybe there is a good method for it?

The error message fails to identify the file that is jamming up also and when you have many, it is just annoying to loop through them one at a time, to see what crashes:

"System.Runtime.InteropServices.COMException (0x8000FFFF): Failed to publish document - odviewdll_clr"

Any good suggestion would be helpful!

BR,
Markus V

[IanBadcoe]

Hi Markus,

Unfortunately I think there is nothing in either API that covers this.

Would I be right in thinking that these users are leaving a NW instance running on another machine that has a file-share of the NWD open?

However file locking is an operating system feature and there are tools available (I believe even free ones) that enable you to monitor it, especially network shares.  So if you could find one of those with a suitable automation interface you could run that before your publish.

--

You can also have the users turn on a global option in NW: Model -> On Load -> Close NWC/NWD files on load.

(By default NW reads NWD contents "on demand" -- it doesn't read anything until in needs to, which improves efficiency but has the side effect of keeping the file open all the time NW is running.  If you set this option NW will read the whole file once and then close it, greatly reducing locking.

--

Or as a last resort you can use a 3rd party tool to force-close network file-shares.  This will make the users NW give an error the next time it tries to read the file, and could corrupt a file if it happened just as the file was being written.

I hope some of this helps,

Ian

[ulski1]

we had a lot of similar issues - I think larger companies need to set close on load as a default for all clients - the publish jobs I have running have a lot of fail safe - alerting built in because even though we got close on load as a default this still happens quite often - I hope the new license auto reclaim on inactivity will help to prevent this but perhaps the file locks will still be there even if the license have been reclaimed - I have not tested it

[Anonymous]

Hi,

You might be right, but I am not refering to locked files due to read only access (or someone keeping them open). There is standard C# features to check if you can aquire a file write lock (don't know if this is applicable, in your cases though, haven't tested).

My issue is the switch used in Navisworks while publishing a NWD file:

"May be re-saved"

As default this is not checked, causing it to be not re-saveable (saved-locked, appologise for being unclear) and as usual users most usually use the default settings.

I do not know a way to query the file (or check if it can be re-saved) without opening the file and trying to publish that file. This is fine with one file, but when you have larger projects with 100s of files it is annoying to run through one at a time and try to publish it to identify what is "non re-saveable" and skip that. When thinking about it, only a small amount of files are nwd, might be the solution though it is crappy!

So I would need some way to check if a file is "non re-saveable".

A workaround is of course to use the nwc + nwf file instead of the nwd, but users are familiar with the nwd option (and it is sometimes delivered from customers) so I assume it is just to train them not to re-save lock the files. An API command would be nice though! => please wishlist it!

Wishlist:

New overloaded method:

DocumentClass.AppendFile(<filename>, SKIP_NO_SAVEABLE_NWD_FILES)

What a good solution, I came up with it myself 🙂

BR,

Markus V

...corrected some spelling issues

...Added wishlist...

[xiaodong_liang]

Hi Markus ,

the only way I can think of is also logging a wish that API can ignore such file. I logged the wish#49977.

Thank you for reporting such issue and the solution you suggested 🙂

[IanBadcoe]

Hi Markus, sorry I didn't get an email saying you had replied.

However Xiaodong has already given the reply I would have.

For the time-being, you could work-around this if you were to use two loops:

1) loop over individual models, loading and attempting to save to a temporary file, if you get the COM exception catch it, log the file-name and remove it from the list

2) now loop over your revised list and publish as previously, knowing that none of the problem files are present any more

That will be slower, but it would side-step the two problems of not getting output and not knowing which file caused the problem...

Regards,

Ian