cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Want the oppurtunity to discuss enhancements to PTC products? Join a working group! X

Search path question...

DarrinHiebert
1-Visitor

Search path question...

We've recently switched to WF5, and we're having some weird things
happening with our search paths, or maybe I should say, our ability to
call up models from the correct location.



We have a search path file, that searches a list of directories in order.
At the very end of that "list" is a read-only directory. In the past, the
arrangement of this "list" has always served us well. However, recently,
we're starting to see times where things will NOT pull from the CURRENT
directory, but rather will pull from the read-only dir, which is the last
thing on the list. I'll try to illustrate what is going on, and
hopefully, this makes sense. Bear with me, this is probably going to get
confusing.



We have an assembly that is structured like this:



123456.asm

234567.prt

345678.prt

456789.prt

567890.prt

678901.prt



Here's our scenarios:



1) Files in local dir:

123456.asm

234567.prt

345678.prt

Files in read-only dir:

456789.prt

567890.prt

678901.prt



2) Files in local dir:

234567.prt

345678.prt

Files in read-only dir:

123456.asm

456789.prt

567890.prt

678901.prt



In scenario (1), when the user calls up 123456.ASM, it will come from the
LOCAL dir, and so will the files, 234567 and 345678. The remaining files
will come from the read-only dir. This is what we would expect to happen,
and this is what has always happened in prior versions.



In scenario (2), the user is in their LOCAL dir, and when they call up
123456.ASM, it will come from the READ-ONLY dir, and so will ALL of the
files, including 234567 and 345678, even though they are in the LOCAL dir.
This is NOT what we would expect to happen, and this is what has NOT
happened in prior versions. In prior versions, ANY files that were in
your local directory would come from there, regardless of where the parent
assembly was called from.



Does anyone else out there have a set up like this, and if so, how is this
working in WF5 (Creo) for you? I also did not mention that this behavior
is not consistent. Sometimes parts will come from the local dir, and
sometimes parts will come from the read-only dir, so it's not consistent
on how it works, or at least not that we can see.



Creo M070 for us.



3 REPLIES 3

Thanks for the replies so far!



I must apologize for not doing my due diligence, and looking into whether
or not this was something that changed. I just figured that it was the
same.



But, as it turns out, several have suggested the config option:
file_open_default_folder working_directory. We have it set to that, and
it is NOT calling them from the working directory, it is calling them from
the search path location.



This is the current order of searching in WF5:



1 - In session

2 - Location of the parent object (assy or drawing)

3 - Current working directory

4 - Search paths, in order



This is INDEED the behavior that we're experiencing, but apparently the
above config option does NOT alter this either.



There is a hidden config option, use_2001_search_order YES. I'm testing
that option now, but I'm always a little bit leery using hidden options,
because you never know how long they will "last". I really think that the
file_open. working directory thing should work, but it doesn't for some
reason. Maybe that's a bug that needs to be filed.



More to come.


use_2001_search_order YES is the one I was thinking of, figured it must
be hidden since I couldn't find it.



The fact that is says 2001 tells me that I was right in my memory that
it changed in WF1. That said, pre-WF5 you must have had it set if it
only changed in WF5 (unless you went straight from 2001 to WF5).
Perhaps the option was depreciated / eliminated for WF5? Did you check
your company config file for this option?



I think that file_open_default_folder only affects the folder displayed
in the File-> Open dialog, I don't think it has any bearing on retrieval
order.



Doug Schaefer
--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn

Doug / et al,



I just did some more checking, and this problem is NOT consistent. I SAW
it do the wrong behavior earlier today on another users machine. I just
tried duplicating it on my machine, and on my machine it works fine. We
both have the same configs, so that's not the issue.



There is something still not quite right in this whole thing, as I know
that this DOES work (working for me now), but I've also had it NOT work
for me.



At this point, I've opted to leave the config option set to
working_directory (which does seem to work), and the next time that it's
hosed, I'll see if changing that to the hidden option fixes it, and then
go from there.



Thanks again for everyones help!!!


Announcements


Top Tags