Assembly3 preview

[realthunder]

So, first remark: while it is possible to set visible/hide for each instance individually, it's not possible to set the drawing style (wireframe/shaded/...) for each instance, this is set for the linked part in its GUI window, and applies to all instances. I thik this should be amended.

This is not straightforward as it appears, but not that difficult either. I'll add that in the future.

The rest of your remarks describes a complex feature. The existing overriding properties inside Link (Visibility, Placement, Scale, etc) are simple enough to not require any prior knowledge of the linked object, others not so. It gets even more complex when overriding properties down through multiple hierarchies. I'll put that on my to do list. Right now, the first priority is to get the existing Link functionality merged.

[Zolko]

The rest of your remarks describes a complex feature. [...] Right now, the first priority is to get the existing Link functionality merged.

I understand. But may-be you don't need to do everything alone.

Can you please point me where, in the source code, an App::Link is "called" from the assembly ? And where the corresponding object is "resolved" ? The functionality I'm interested in happens between these 2 steps.

[realthunder]

I understand. But may-be you don't need to do everything alone.

Can you please point me where, in the source code, an App::Link is "called" from the assembly ? And where the corresponding object is "resolved" ? The functionality I'm interested in happens between these 2 steps.

There are two major APIs in App::DocumentObject for object resolving. One is getLinkedObject() which should return the linked object or return itself if it is not linked. The other is getSubObject(), which returns a (grand)child object. These two APIs can be overridden with Extension with extensionGetLinkedObject() and extensionGetSubObject(), and Link is actually implemented using App::LinkBaseExtension, There are other helper function for resolving (sub)objects or sub-element (DocumentObject::resolve/resolveRelativeLink(), GeoFeature::resolveElement(), ObjectIdentifier::resolve/resolveProperty(), Part::Feature::getShape(), etc.), all of which relies more or less on these two functions.

You can get more details here.

[BassMati]

Good evening folks,

I am currently testing how ASM3 links to Assembly objects in other files (external links?) behave when the link target file was moved to another location (e. g. for housekeeping reasons). When the link source document is reopened later, the tooltip says "LinkedObject not restored", and after a refresh, "Link broken".

If I know the new name and location of the moved link target file I can load it and repair the broken link in the "Linked Object" field in the property panel. The name of the link target node can often be guessed from the Label value of the link source node. But if either file name or node name is unknown, I'm in deep trouble.

The original file and node names must still be somewhere in the model file. How can I pull them out? Python console? Opening the STL file with an SQLite database tool?

Thanks in advance
BassMati

[ceremcem]

Good evening folks,

I am currently testing how ASM3 links to Assembly objects in other files (external links?) behave when the link target file was moved to another location (e. g. for housekeeping reasons). When the link source document is reopened later, the tooltip says "LinkedObject not restored", and after a refresh, "Link broken".

1. Open your dependency file from the new location.
2. Click your broken Link in your main model.
3. Click "Linked Object" property
4. Select the Assembly Container in your newly opened file
5. Click OK.

The original file and node names must still be somewhere in the model file. How can I pull them out? Python console? Opening the STL file with an SQLite database tool?

I couldn't understand the requirement here.

[realthunder]

The original file and node names must still be somewhere in the model file. How can I pull them out? Python console? Opening the STL file with an SQLite database tool?

I'll show the file name following the "Link not restored" error message. Meanwhile, you can find out the file name in the project file. Remember the broken link object name, then open the FCStd project file containing this link object. The project file is a simple zip archive. Look for a file name Document.xml inside this zip archive, open it and search for the link object name. There will be a few occurrence. And you'll find the file path in one of them.

[BassMati]

Ceremcem,

1. Open your dependency file from the new location.

That could be a problem if someone else moved and/or renamed the library file, or if that happened a long time ago. Should not happen in reality, of course, but...

4. Select the Assembly Container in your newly opened file
5. Click OK.

There's another step between 4 and 5:

4. Select the Assembly Container in your newly opened file
5. Select the desired target object in the list box
6. Click OK.

For example, consider the project document contains a link to specific screw inside a large library of screws, e. g. "M4x20CH-TX", and the author renamed the link from "M4x20CH-TX006" to "MountingScrew"... I often do that to indicate the purpose of things I used in a design, but after a few months, I'm sure I can't remember which type of screw I used in that place.

@Realthunder: Showing the target object name in the tooltip would be great. Finding the target file name from the XML worked fine.

Another thought: I guess that it is a good practice to "Import (All) Links" into the design document in oder to make it self-contained? That could avoid the problem more or less completely.

Thanks for your help!

[realthunder]

For example, consider the project document contains a link to specific screw inside a large library of screws, e. g. "M4x20CH-TX", and the author renamed the link from "M4x20CH-TX006" to "MountingScrew"... I often do that to indicate the purpose of things I used in a design, but after a few months, I'm sure I can't remember which type of screw I used in that place.

There is a now new 'Description' column in the tree view for this purpose.

Another thought: I guess that it is a good practice to "Import (All) Links" into the design document in oder to make it self-contained? That could avoid the problem more or less completely.

There is indeed a "Import all links" command. Right click the document icon in the tree view, select 'Link actions -> Import all links", for exactly this purpose. But it is a complex one, and doesn't seem to work at the moment. I'll fix it soon.

[ceremcem]

That could be a problem if someone else moved and/or renamed the library file, or if that happened a long time ago. Should not happen in reality, of course, but...

IMHO, being forced into remembering the file names and the locations should never happen, ever. You should always use some kind of project versioning tool, such as git (although it doesn't play well with .fcstd files) or a dedicated tool. Developing a model with Asm3 is much like developing a software with thousands of dependencies. Same problem applies there, no one can help you if you don't use a versioning tool.

[BassMati]

@ceremcem: You're right, version control is a must. Currently I use SVN and Git, they both integrate well with my favorite dev env (Visual Studio) and play nice from the command line.

@realthunder: Info in the Description column is fine. I found the "Label2" property, which seems to be intended for user descriptions. I currently place the link target info there in a parseable format ("LinkTarget:MyLib/lib.fcstd:Cylinder;"), and keep it updated manually. Not fail-safe, but better than nothing.

How about adding Properties to the Link Category in the Property panel instead? "Link Target File" and "Link Target Object" or so would be very nice.
But that's low priority. I don't want to distract from more important work.