Presets are a great functionality to apply various settings to features. Unfortunately, there is currently no public API available for creating, selecting, or applying any Presets programmatically. In my specific case, I need to apply a set of propüerties to an assembly through BIM-Content - Include Properties, but I'm sure there would be diverse other applications throughout Inventor starting from applying a set of parameters to a hole to generating different simplifications with different levels of detail to whatever is possible with a preset. So appling a preset, that could easily be deployed to a users machine through the API would provide a powerful tool for many use-cases. Please take into consideration as a future API-Improvement. Thank you, Tobias Show More

Hi everyone, When you open a part directly from an assembly, Inventor always resets the view to the part's default orientation — which can be disorienting when you're trying to inspect or work on something you were just looking at in the context of the assembly. What this rule does: OPEN IN POSITION lets you click on any part inside an assembly and open it as a standalone document while preserving the exact camera orientation you had in the assembly view. The part opens showing the same angle, the same perspective — as if you just "zoomed in" to it. Show More

Hello community , I would like to suggest an improvement for Inventor/iLogic Forms: Support for animated GIFs inside Forms. Currently, Forms can use static images as visual support, which is useful for explaining options, positions, or configurations. However, in some cases, a static image is not enough to clearly show how a feature works. The idea would be to allow GIF files to be inserted into a Form in the same way as a normal image, while keeping the animation active. This would make it possible to use a GIF as a small visual tutorial inside the configurator. For example, instead of showing a static guide image with explanatory text, the Form could display a short animation showing: how a specific option changes the model; how to use a checkbox or dropdown; how components are activated, suppressed, moved, or centered; what result the user should expect after changing a parameter. This would make Forms easier to understand, especially for users who are not familiar with the configurator. It would also reduce the need for long written instructions and make technical Forms more visual, intuitive, and professional. Example of static image Show More

Currently there is no API support for updating a parts list style, so we have to use some workarounds.  Example: If we have an existing a parts list on a drawing that uses a style of a certain name ( let's say PartsListStyle1) and the style changes, the existing parts list will still be using the old version of the style ( as an override of sorts), and we have to set the parts list to use a different parts list style temporarily, and then set it back to the original style to get it to update. It would be nice to be able to use something like this: Dim oDoc As DrawingDocument = ThisApplication.ActiveDocument Dim oPartsList As PartsList = oDoc.ActiveSheet.PartsLists(1) oPartsList.Style.UpdateFromLocal related link: https://forums.autodesk.com/t5/inventor-programming-forum/update-parts-list-in-idw/td-p/14120743 Show More

It would be really nice to see the iProperties from the iLogic editor. Even if it's just in a read-only state where you can copy and paste values into the current code without having to exit out of the editor, go to the iProperty window and then return to the code. It's especially a pain when you are working with new iProperties.    Thank you.        Show More

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. Show More

Create a public GitHub organization or repository for the Inventor API samples, similar to the GitHub organization created for Autodesk Fusion & samples.   This would allow the community to contribute to the code samples, whether adding additional languages like VB.NET or C# for existing samples or adding new samples.   This would also allow the community to track progress & changes. Show More

We need an object browser for iLogic, just like the one that can be found in the API window. This would make complex iLogic programming much easier, especially for beginners.   Original Author: mrattray   4/17/2013 Show More

In my opinion it would make much more sense for a double click on a rule in the iLogic pane to run the rule instead of editing the rule. Hopefully we're all more often running rules rather than reconfiguring them!  Show More

I don't see a way to remove duplicates easily. I know you can inspect the intent and do a measure between the two intents and that is what I'm going to do on my current project but it would be nice to be able to see the value on the member from the origin or have a method to allow/remove duplicates on the ordinateset.    API https://help.autodesk.com/view/INVNTOR/2025/ENU/?guid=GUID-OrdinateDimension Show More

It would really cool to be able to quickly switch between rules in a document. This would be helpful if you want to copy a line of code you have in a different rule. But to do this now you have to close the rule, open the other rule, copy, open the rule you had open and then paste. If you had a dropdown that would allow you to quickly switch between rules would speed up that functionality.        Show More

Product and Version Autodesk Inventor Professional 2025.3 Autodesk Vault Professional 2025.4 (Issue observed in multiple prior versions as well) Summary When a user makes temporary, experimental edits to a part or subassembly within the context of a parent assembly—without checking out and without saving—there is no way to discard those in-memory changes and reload the component from disk without closing all parent assemblies that reference it. This significantly impacts productivity for users performing "what-if" analysis or exploratory design changes. Detailed Description Use Case Engineers frequently need to test design ideas before committing to them. A common workflow is: Open an assembly from Vault (all files in Released state) Edit a component to test an idea, declining checkout prompts since this is temporary Evaluate the change in the assembly context Decide to discard the experimental change and revert to the released version Current Behavior The experimental changes exist only in RAM (not saved to disk) The following Vault commands do not discard in-memory changes: Refresh File — compares local disk timestamp to Vault; since nothing was saved, disk file is already "current" Get Revision — same issue; local copy already matches Vault Revert to Latest — designed for disk-level discrepancies, not in-memory state Closing the part window does not release it from memory because the parent assembly still holds a reference The only current solution is to close the entire assembly (and all of its parents), losing any valid work in progress at the assembly level Technical Root Cause Inventor's document management keeps referenced documents in memory as long as any parent document references them. The Vault add-in's refresh commands compare disk timestamps, not in-memory state. Since unsaved experimental changes never touch the disk, these commands see nothing to refresh. From Autodesk's own API documentation: "If a document is closed, the document is not really closed unless that was the final view and the document is not referenced by any other open documents." Business Impact Impact Area Description Lost productivity Users must close and reopen large assemblies (potentially 100,000+ components) just to discard a small experimental change in one part Risk of data loss If the assembly has valid unsaved changes, users face a difficult choice: lose their real work or keep the unwanted experimental changes Workflow friction Discourages exploratory design and "what-if" analysis, which are critical for innovation and optimization Training burden New users expect "Refresh" or "Revert" to work intuitively; current behavior is confusing Proposed Solution Add a new command accessible from: Right-click context menu on components in the Model Browser Right-click context menu in the Vault Browser Vault ribbon Command Name (suggested) "Reload from Disk" or "Discard Changes and Reload" Expected Behavior Prompt user to confirm: "Discard all unsaved changes to [filename] and reload from disk?" Internally close the document (with SkipSave) Re-resolve and reload the document from the local workspace file Update all occurrences in referencing assemblies Trigger an assembly update to reflect the reloaded geometry Integration with Vault When Vault integration is active, an additional option could be offered: "Discard Changes and Get Latest from Vault" — combines discarding in-memory changes with fetching the latest version from Vault in one step Scope Should work on parts and subassemblies Should work regardless of Vault lifecycle state Should preserve assembly constraints (geometry should be identical if reloading the same version) Workarounds Attempted (All Unsuccessful) Workaround Result Refresh File (Vault) No effect — disk timestamp unchanged Get Revision (Vault) No effect — local already matches Vault Revert to Latest (Vault) No effect — same reason Close part window Part remains in memory due to assembly reference File → Manage → Refresh (Inventor) Compares to disk timestamp; no reload occurs Replace Component with itself Does not force document reload Related Autodesk Ideas Submission This request aligns with existing community feedback: https://forums.autodesk.com/t5/inventor-ideas/reload-model-in-assembly/idi-p/12476534 Additional Notes This limitation has been observed and reported by multiple users across Autodesk forums dating back to at least Inventor 2020 The issue affects both Vault and non-Vault users, though it is particularly painful in Vault environments where files are often read-only and exploratory edits are common A similar "Reload" function exists in other CAD systems (e.g., SOLIDWORKS, Creo) and is a commonly expected feature Show More

It appears there is no method currently to change the label orientation (which can be done manually as seen in the first screenshot)   Can we have a <DrawingView>.Label.Orientation method added to the iLogic API to set this through iLogic? Show More

The Inventor Server offers significant advantages for automating models that are too complex to be generated in an APS environment. Therefore, I would like to request a substantial extension of the API interface for Inventor, and thereby the Inventor Server, particularly concerning IDW (drawings). More and more users/customers want to enable automated models, including the corresponding drawings. However, there are notable gaps, especially in the area of drawings (e.g., reordering dimensions), as well as in parts and assemblies. Nothing saves companies more time and money than partially or fully automating content and models. This is only achievable through a comprehensive API. Unfortunately, the GUI significantly slows down many processes, and creation via the Inventor Server would be much faster. Due to the lack of API functionality, many tasks can currently only be implemented using the full Inventor application. Therefore, I kindly ask you to expand the scope of possible API/iLogic functionalities for the Inventor Server and Inventor. Show More

I am attempting to create a script that places sketched symbols on a sheet and attaches them to DrawingWeldingSymbol's. This seems to currently be impossible due to the lack of accessable GeometryIntent, despite a user being able to attach leader's to the DrawingWeldingSymbol.Position point.   It seems like this would be an absolute benefit to users to be able to access GeometryIntent's of at least all objects that user's can manually attach, or have another method of robustly attaching leader's in another way. Previous Troubleshooting: Reference Leader's GeometryIntent  (https://forums.autodesk.com/t5/inventor-programming-forum/reference-leader-s-geometryintent/td-p/14036319) Show More

In the context of developing and debugging with iLogic in Autodesk Inventor, it’s common to execute rules repeatedly to test different conditions. Currently, the iLogic Logger (Logger.Info, Logger.Error, etc.) retains all messages from previous runs without offering any way to clear it via code. Proposal Introduce a method such as Logger.Clear() or Logger.Reset() that allows the log to be cleared at the beginning of a rule. This would help: Keep the log clean and readable during frequent testing. Avoid confusion between old and new messages. Support professional, automated logging workflows. This feature would enhance the experience for power users and developers, giving them better control and clarity when monitoring rule execution. Show More

Please allow or enable the ability to use the 'kBooleanType' variation of the ValueTypeEnum when creating new Attributes in the Inventor API.  When creating one or more new Attribute objects, using either the AttributeSet.Add Method or the AttributeSet.AddAttributes Method, we want to be able to create new Attributes which have a Boolean type Value, by specifying the 'kBooleanType' variation for the ValueType when creating them, then setting either 'True' or 'False' (unquoted) as the Value.  This very basic ability could open up some additional possibilities and options within our Inventor automation solutions. Below is a Link to a discussion which started back in August of 2018 in the Inventor Programming Forum where this topic was mentioned, but I'm sure there have been several others over the years, because this ability could be very useful. https://forums.autodesk.com/t5/inventor-programming-forum/why-boolean-attribute-does-not-work/m-p/13969885  Show More

Problem / Current Behavior When editing an iLogic rule using the built-in iLogic Rule Editor, the Autodesk Inventor UI becomes modal and blocks interaction with the Model Browser and the active assembly. While the editor is open: The Model Browser (upper-left) cannot be explored Parts and sub-assemblies cannot be expanded or selected Any attempt to interact with the assembly results in a system “beep”, indicating a locked UI This makes it impossible to inspect component names, hierarchy, or parameters while writing iLogic code. Why this is a problem Writing non-trivial iLogic rules for assemblies requires continuous reference to the Model Browser, including: Component and occurrence names Assembly structure and nesting Parameter and feature identification Blocking access to the Browser forces users to: Close the rule editor repeatedly Memorize or manually copy names Break concentration and workflow This significantly reduces productivity, especially on complex assemblies. Expected / Desired Behavior At minimum: Allow interaction with the Model Browser and assembly tree while the iLogic editor is open. Ideally: Make the iLogic Rule Editor non-modal Allow it to be docked, floated, or moved to a second monitor Enable full multi-monitor workflows where: iLogic code is edited on one screen The model, browser, and assemblies remain fully interactive on another Suggested Improvements One or more of the following would resolve the issue: Convert the iLogic Rule Editor from modal to modeless Allow browser interaction even when the editor is active Provide an officially supported, fully integrated multi-monitor editor mode These changes would greatly improve usability without altering iLogic functionality. Who benefits Advanced Inventor users Engineers writing complex iLogic for large assemblies Anyone using dual-monitor setups (now standard in engineering workflows) Summary The current modal behavior of the iLogic Rule Editor unnecessarily blocks access to critical model information. Enabling browser interaction or a multi-monitor-friendly editor would be a major quality-of-life improvement for iLogic users. Show More

In practice, there are New equipment (machines) and they are a thick line. Old equipment and or the surroundings of the equipment and they are a weak line. Whenever we make the surroundings of concrete or need to connect to other equipment, we do not see hatches. We need the possibility to display hatches in the same color as defined for the reference style for the reference component. We have to create a sketch, project the geometry and draw curves and create hatches - all manually. Or we have to change the iProperties line color and line thickness for each View or Section. It is very laborious. Displaying hatches for machines with a thin layer is common practice - Ask all the engineers in the world. It is illogical to have more parts in the concrete in the bill of materials when the concreting is provided by another company, but it is necessary to indicate this on the drawing - anchoring of screws for the machine, machine feet or as a concrete base (elevation and alignment + set of washers) Show More