cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Add Document Property / Method for why Document.IsModifiable = False (DocumentModifiableStatusEnum) (Inventor API)

Add Document Property / Method for why Document.IsModifiable = False (DocumentModifiableStatusEnum) (Inventor API)

Please add a Property or Method to the Inventor.Document object in Inventor's API which we can use to quickly & easily determine why that document may not be modifiable.

 

When using Inventor's API to automate Inventor by code, the Application, and Document objects are the two highest level objects that we need to interact with all the time.  The Document object has the important Document.IsModifiable ReadOnly Property, which returns a Boolean (True/False) type value, indicating if we will be able to many any modifications to that Document.  However, when that property's value equals False, there is no further explanation for WHY the document is 'not modifiable'.  I want the Inventor developers to create and expose a new Method or Property for the Inventor.Document object in Inventor's API so that us Inventor users can more quickly and easily figure out exactly why a document may be 'not modifiable'.  I would also suggest creating an Enum for that, for added stability.  It might contain one variation which is something like ["Normal", "Modifiable", "IsModifiable", or similar], or maybe not, depending on how it gets implemented and/or where all it gets used.  If my code process is iterating through multiple documents, and I am checking the Document.IsModifiable property value, and it returns False, I want to then be able to access a secondary property or use a secondary method, to figure out why it is not modifiable.  This can be very important.  Then, if the reason is because it is a ModelState member, or not checked out from Vault, there may still be a way to work around those situations, where there is no way to work around some of the other 'reasons'.  This is also helpful for logging which components or documents had to be skipped over during a long process, so we can include the reason why they had to be skipped over, so we know if follow-up actions will be necessary.  Knowing the 'reason(s)' why some were skipped can sometimes be important for determining if any manual follow-up actions may be required to deal with them properly.

 

When a user accesses the ReadOnly Property, or calls the method, a block of code could run in the background which checks for each of these possible reasons, if any, then return the appropriate variation, or value.

 

Possible Example Property/Method:

Document.ModificationObstacles As DocumentModificationObstaclesEnum

Document.ReasonsIfNotModifiable As [...Enum or String() or Inventor.NameValueMap]

Document.GetReasonsNotModifiable() As [...Enum or String() or Inventor.NameValueMap]

 

Possible Example Enum:  (may need more variations &/or clearer names ; may need the 'Flags' attribute for possible combinations)

''' <summary>
''' An enumeration of possible reasons why a Document may not be modifiable
''' </summary>
Public Enum DocumentModificationObstaclesEnum
	''' <summary>
	''' The Document's File is located in a Library 
	''' </summary>
	kFileIsInLibraryLocaion 'located in active DesignProject.LibraryPaths
	''' <summary>
	''' The Document's File has its ReadOnly attribute set
	''' </summary>
	kFileIsReadOnly 'FileAttributes.ReadOnly
	''' <summary>
	''' The Document is a Content Center member
	''' </summary>
	kIsContentCenterMember
	''' <summary>
	''' The Document is an iAssembly member
	''' </summary>
	kIsiAssemblyMember
	''' <summary>
	''' The Document is an iPart member
	''' </summary>
	kIsiPartMember
	''' <summary>
	''' The Document is a ModelState member
	''' </summary>
	kIsModelStateMember
	''' <summary>
	''' The Document is modifiable
	''' </summary>
	kIsModifiable 'Normal - can be modified (Default Value)
	''' <summary>
	''' The Document is Locked or set to Released state in Vault
	''' </summary>
	kVault_Locked 'or kVault_Released
	''' <summary>
	''' The Document is not checked-out from Vault
	''' </summary>
	kVault_NotCheckedOut 'or kVault_NotCheckedOutToYou
End Enum

It may not be possible for Inventor API Properties or Methods to directly interact with Vault's API, and if so, we could potentially leave those variations out of this...for now.  But if that is the case, hopefully there could be a uniquely 'iLogic' tool like this instead.  It may be possible for there to be multiple reasons why a specific document can not be modified.  If so, and using an Enum, then it would either need to just return the most appropriate variation, or we would likely need to add the 'Flags' attribute to it, and allow combinations of the values as an Integer, which could be checked using Bitwise operations.

3 Comments
WCrihfield
Mentor

FYI:  I am aware of how to check for most of those reasons why a Document may not be modifiable by code.  But I would rather not have to.  I do not want to either include a whole bunch of extra code in every iLogic rule or have to reference some custom external code resources which contain methods like that, just to cover this foundational functionality.  I would prefer for there to be a simple, easy to use, built-in solution.

AssemblyComponentDefinition.IsiAssemblyMember 

AssemblyComponentDefinition.IsModelStateMember 

PartComponentDefinition.IsContentMember 

PartComponentDefinition.IsModelStateMember 

PartComponentDefinition.IsiPartMember 

Application.DesignProjectManager 

DesignProjectManager.ActiveDesignProject 

DesignProjectManager.IsFileInActiveProject 

LocationTypeEnum 

DesignProject.LibraryPaths 

https://learn.microsoft.com/en-us/dotnet/api/system.io.file.getattributes 

https://learn.microsoft.com/en-us/dotnet/api/system.io.fileattributes 

Bearded_Engineer
Enthusiast

They cant even manage this with their own save function... How many times Inventor tries to save files that are either read-only or (Vault related) locked for editing. This needs to be taken to a whole new level, including API requests. We need a stable solution to skip locked files when running iLogic code etc. With or without Vault. 

WCrihfield
Mentor

Hi @Bearded_Engineer.  I agree that some of Inventor's behavior needs to be changed, especially where it concerns Vault.  We had decades of engineering department files of all sorts, including lots of old AutoCAD drawings and well over a decade of Inventor files, then we got Vault Professional 2024.  Massive, overwhelming, and super time consuming undertaking trying to get all that data put into Vault.  It has been a year since we got Vault and we still do not have all our data put into it because there were thousands of files with 'issues' preventing them from being properly put into Vault.  We had do develop some of our own code-based solutions to help us scan for and attempt to fix certain kinds of common problems in some files.  We eventually pretty much gave up on some of it.  We just wanted to be able to use its 'Where Used' and 'back-up' functionality, and were hoping it would help with certain other minor tasks...which ended up being way more complicated than they should have been.  Besides that, and back to the point here, when we open older drawings &/or assemblies, Inventor pretty much always immediately asks us if we want to 'update' the document we just opened.  For decades clicking 'OK' on this was...well, OK.  Now, something that fast & simple causes all sorts of time consuming problems.  Usually, we either opened the main file purely in 'ReadOnly' mode, or maybe just checked-out the 'main' document, without checking out any of the 'referenced' documents.  Well, the moment it does this 'update', it makes changes to documents that have not been checked-out, and which should have been in 'ReadOnly' mode.  Now all of a sudden, multiple documents have been 'modified outside of Vault', and many of the following actions you attempt to take give us 'warnings' or worse.  And if we attempt to 'Save' the main document, the common dialog shows up, asking is to save a whole list of other documents that got 'modified' because of that update.  And what's even worse, some of the descriptions on the right portion of that dialog say that it will 'change its ReadOnly' status, just so it can save them.  What the crap is that!?  Those documents are not checked-out of Vault, are supposed to be 'ReadOnly', and supposed to stay that way, not have their 'ReadOnly' status automatically overwritten by Inventor's messed-up behavior.  Then, if we change all those other documents to 'No - do not save them' , and the 'main' document to save, then click on OK.  If we then immediately click Save again, the same documents are still listed, and automatically set to 'save' if I click OK.  With no way to 'clear' those modifications out of Inventor's memory.  The only way to clear those modifications out of Inventor's memory is to completely close all open documents, then close Inventor, then restart Inventor, then open all of my stuff up again...trying to not say 'Yes or OK' to that stupit 'Update?' dialog this time.  AHHHHH!!!  😖😞

Can't find what you're looking for? Ask the community or share your knowledge.

Submit Idea