Client feature visibility in design view representations

[cadull_rb]

I have an assembly with a client feature that contains client graphics. I have exposed the visibility (ClientFeature.Definition.ClientGraphicsCollection[1].Visible) to the user via a context menu option. Changing the visibility currently affects all view representations. Is there a way to associate the visibility with each design view representation?

Regards,

cadull

[xiaodong_liang]

Hi, I wrote a blog for you: http://adndevblog.typepad.com/manufacturing/2014/01/client-feature-visibility-in-design-view-represe...

[cadull_rb]

Thanks Xiaodong,

I wish it was that easy. I'm thinking that I would store the visibility in an attribute set on the design view representation.

The task is complicated by associative design view representations. It seems I also need to handle AssemblyEvents.OnOccurrenceChange where the context has ActiveDesignViewRepresentation. Then either store the visibility details in the parent assembly or recursively check the occurrences when a different design view is activated.

I also have concerns about setting the visibility on the proxy client feature only, so that multiple occurrences have independent visibility.

In my scenario, the client graphics are a design aid that can be left invisible, so we may not support design view representations for now.

Regards,

cadull

[xiaodong_liang]

Hi Cadull,

yes, you will have to handle more scenarios which may affect the visibility of the client graphics, according to your workflow.
even if you stored the attribute with the design view representation, you will also need to watch the OnActivateDesignView to apply the value of the attribute to the client graphics.
Event is a common use in programming. I hope it would not be an obstacle to you.

[cadull_rb]

Hi Xiaodong,

I'm not opposed to handling events, but I have to balance the cost of implementation with the benefits gained. In this case the user would expect the client graphics behaviour to be consistent with the way Inventor handles design view representations. This means considering what occurs when design view representations are associative or selected for a drawing view. Inventor already knows what to do for the visibility of other features, but we have to mimic this based on observed behaviour.

For one reason or another, I keep finding myself rewriting standard Inventor functionality.

• Design view representations to support client graphic visibility.
• Composite iMate definitions, matching and constraint generation to support constraint limits and selective matching with name enforcement.
• Frame generator because there is no API to automate it.
• Document update to improve iAssembly stability and behaviour by ensuring factories of referenced members are also updated.
• Document save to improve iAssembly behaviour by ensuring all referenced documents that are dirty are saved and checked out from Vault.
• Batch document update because the job scheduler version doesn't support Vault.
• Batch migration of documents to Inventor 2014 because the job scheduler succeeded on a non-Vault test copy, but failed when Vault was involved.
• Vault check in to improve reliability and performance when checking in an iPart or iAssembly factory.
• iPart and iAssembly member regeneration triggering because some document changes don't cause an update.
• Event management layer because event handlers are skipped if a handler is unsubscribed while it is executing.
• Accessing Inventor internal libraries where the API is lacking e.g. to share the Inventor Vault login.

I find using the Inventor API to be reliable and easy to use for once off execution, i.e. the user presses a button which initiates some changes. I find tighter integration with the Inventor workflow to be tricky and unpredictable at times, e.g. responding to a document update in order to make further changes. A good example is a recent forum post where Application.CommandManager.ActiveCommand throws a COM exception if called during the ApplicationEvents.OnSaveDocument event. Similarly I recently came across a situation where calling Document.InternalName threw an exception, but Document._InternalName was fine. These are simple examples; at other times the issue can be subtle and more complex, such as events failing to trigger.

Documentation about how existing functionality is achieved would be great reading e.g. what does the Place Component command do in order to show a preview of the component being inserted, or how does the Constraint command solve the new position of the components during the preview, and what steps does the Vault addin follow when checking in a document. This could be used for ideas on how to create new functionality as well as how enhancements could be integrated (e.g. what will I need to cover to support client graphic association with design view representations).

Regards,

cadull

[xiaodong_liang]

Hi Cadull,

yes, Inventor API allows you to re-write some built-in workflows, some of which rely on various events. We appreciate your comments on API, sorry however I’d suggest we focus on the original question (control visibility with design view) in this post to have a clear history, also better for future reference.  

For the orignal question, as far as what I can find, the workaround is using OnActivateDesignView. Probably other peers would have any more trick, but this is the only way I get at this moment.

I’ll take a crack at answering two of your questions below. If it does not help, please feel free to log a new post for one topic each.

>>what does the Place Component command do in order to show a preview of the component being inserted:

   I do not know how the core code implements, but from API perspective, it could be also a client graphics shown in UserInputEvents.OnDrag events. There is a code in API help reference which demos dragging a WorkPoint. You could mimic its workflow.

   If you prefer to take advantange of the existing preview, adding a little customization, you could refer to this blog:

http://adndevblog.typepad.com/manufacturing/2012/07/custom-create-in-place-component.html

>>how does the Constraint command solve the new position of the components during the preview,

  Again, you could build the surface graphics by copying surface body of the two components. For a Mate constraint e.g., iMate or (user selects manually) tells which faces are to be constraint. You can calculate the matrix from normal of Face1 to normal of Face2, by which you can transform one body by the matrix.