Although originally posted in the Developer Forum, I think this can be useful here too:
Since our update to ST9, we have been experiencing some changes in the link management of the files and their drafts, or at least in its behaviour.
In our workflow, all drafts are always stored in a 'DRAFTS' subfolder placed where the parts of the machine are. So for example, the placement of a component along its draft is as follows:
As we move projects from disc to network and so on, 'arbitrary_path' can change, but the relative link between a component and its draft is not changed, at least as far as we don't change 'DRAFTS' name.
We use the default LinkMgmt.txt configuration, so no break link should occur if we just change 'arbitrary_path', since the RELATIVE approach should work fine. In fact, in previous versions of SE, even changing DRAFTS with another name was fine. SE seemed smart enough to find for a link inside a draft in the upwards folder before trying to get the absolute path.
From our experience, SE has lost that 'look upwards' behaviour and, even more, when the RELATIVE paths have not changed, sometimes (not always, weird!) the links are broken and we must make a full re-link.
We have tried a dirty trick in order to get back the 'look upwards' of the past, editing LinkMgmt.txt this way:
CONTAINER RELATIVE ABSOLUTE BEGIN SEARCH PATH .. ..\.. END SEARCH PATH
As you can see, we have added instructions to look in the up folder until two depth levels (sometimes we make subfolders for diferent drafts, so a second level in the tree is useful). To our surprise this works :-D, althought, as I said, nothing of this was ever needed in previous versions. SE managed to reach links placed in upper levels naturally.
Now comes the amazing part of the story: with the LinkMgmt.txt as shown, whenever we try to launch SE and open documents through the API, the whole app gets freezed. No errors, no exception, no messages. SE gets freezed and the document never opens. If we have manually launched SE before, so it's not opened from the API, we can skip the freeze most of the time, but not always.
If we restore LinkMgmt.txt to its default, all works fine.
Conclusion: launching SE and opening documents from the API does not like our 'seek upwards' tricky directives, which in fact work superb when working manually, althought were not never needed in older versions of the software.
The opening and loading of documents it's done by means of the typical API methods:
olidedge.Application") Application.Documents.Open("full_path_of_my_draft" )
If it's difficult to understand all this, try to guess how tricky it as until we could define this odd behaviour. Can anyone throw some light over this?
Thanks for your time and patience if you were ever able to get here. Hope this can be useful for someone.
I always thought SE looked down and not up? In that instance I would think the absolute path is the reason it resolves but then I'd be happy to know more.
I was never clear on which directions SE looked for relative paths.
In order for SE to "look up" I always defined the exact, top level, search path that we store our files in and let SE "look down" from there. No tricks or gimics. Using the 3 keywords before the search path prevents unnecessary delay in searching.
CONTAINER RELATIVE ABSOLUTE BEGIN SEARCH PATH k:\cadfiles\CustomerControlled K:\cadfiles\CatalogParts k:\cadfiles\Tooling k:\cadfiles\Product END SEARCH PATH
Note: We are currently testing the new built-in data management tools and our top-level folders are now the life cycle status, as opposed to Tooling or Product, so things are definitely a bit different with ST9.
That approach works, for sure, but we can't use it here.
The fact is that projects are moved in a regular basis: workstations, laptop, network, backups, etc. In short: absolute paths change all the time, and we also try to keep each project self contained in a single folder (except for standar components), so we can move the whole stuff withour worrying about paths.
From my perspective: having a workflow depending upon absolute paths in an era when cloud management is the next step and when we are using the built in API for avoiding any non-creative human task it's just a joke.
Also, absolute search must be quite slow, since the searching speed in a single project will indirectly depend upon the number of projects and, in general, the quantity of information besides the project itself. Mathematically speaking: a crime on efficiency punished by the most basic engineering ethics :-P
The look upwards approach has always worked, although I have never seen it documented. I tried it for ages even changing the subfolder name and you can be sure it always was able to catch links placed upwards. I'm talking about SE since it's version 19 along years. Even now, it works sometimes! I wish I could explain the reason...
Thanks for your interest, I hope this post becomes a rich (an needed) documentation for this stuff.