Community Tip - Did you get an answer that solved your problem? Please mark it as an Accepted Solution so others with the same problem can find the answer easily.
X
I tried creating a mapkey that reads in a relation file. However, if the file name was changed from lowercase to uppercase or a mix, then it wouldn't work. When reading files, mapkeys should not be case sensitive.
Totally agree. The same thing goes for the folder names in the file path. The mapkey won't work if there is any variation between computers. This is very much contrary to how "normal" Windows programs work. See https://support.ptc.com/appserver/cs/view/solution.jsp?n=CS198360
That doc says "Works to product specification for Creo Parametric 3.0". I want someone from PTC to produce a product spec that indicates that they intended Creo to make a distinction where Windows does not allow one.
ticket was opened on that same assumption. Ticket was closed, after a lot of arguing, that the assumption is that the file was created before the mapkey was created and therefore the case would not change.
Doug, I totally agree, but your misunderstanding the meaning of "works to spec." It doesn't mean someone actually said it should work this way, but rather the spec. never bother to say it shouldn't work this way. Since this behavior is not specified, it therefore "works to spec."
Back in 2007 or so, I happened to sit with the head of PTC's tech support at one of the networking lunches at the national user conference. In response to the complaint that too many issues are dismissed as "intended functionality", he said that if I ever got the response I should request to see the spec document that described that as what should happen. If it was really intended, they should be able to produce documentation to support it, he said.
Not that it'll matter much, when PTC makes these kind of arguments, no amount of logic can prevail against it.
I remember seeing you write this somewhere else and I have stuck to this philosophy when making calls; I request the documentation. Since starting to do this I have received much better answers and sometimes solutions where I would not have had.
In one interesting case the documentation they provided did not list the requirement that they were claiming. It wasn't until they went to adobe (having to do with Creo View), did we both learn that there was a hidden requirement that seemingly they were not aware of and was not in their documentation. In any case I got a more accurate answer and one they could possibly use to address the problem in the future. (yes I am optimistic! 🙂 )
It is also annoying that mapkeys are case sensitive when ordered so it is extra difficult finding a mapkey from a list in the mapkey dialog (or when adding to a ribbon as an icon). Actually this is a problem when opening files too. The ordering of the folders (and I think the files) are case sensitive too!
Please understand that relations predate the Windows platform, so it is natural that absent an active desire to change their behavior, they might not understand about this.
However, what is going on here is a little trickier than thus far noted. There are two ways of saying "I want prt0001_rel.txt" in this dialog: 1) you can pick the file in the list. This records in the trail/mapkey as "~ Select `file_open` `Ph_list.Filelist` 1 `prt0001_rel.txt`", and will go OOS if there is no such UI component when rerun. But you can also 2) put the name in the input field, which records as "~ Update `file_open` `Inputname` `prt0001_rel.txt`". This way *does* work on rerun if the file is PRT0001_rel.txt.
Whether cross-platform trail compatibility is more or less important than same-platform mapkey recording flexibility could be a matter for debate, but I hope that this alternate technique will suffice for this particular issue.
While the history may be interesting, now that Creo is a Windows only product, it should treat ALL file and folder names as case-insensitive. Having the case of a folder or file name change should not have any impact on the behavior of the software. It almost seems like PTC never fully finished migrating the software over to the Windows platform...
The good news for getting rid of it is there is actually a strong motivation to get rid of it and it does go beyond mapkeys. When trying to find a network folder, there is a significant loss of time to people looking for it alphabetically and then not finding it. The user may have forgotten that there are 2 alphabets that need to be scrolled through, or they may not have known. I still stumble on this one. This complaint has come up multiple times at my company and this is not the first time I have seen it on this forum either. Please push to remove it as it represents a non-intuitive slow down every time someone navigates to find a folder (or file, or mapkey, etc).
Thanks for your input and hope that this can be seriously looked into, as the others have expressed interest in as well,
We are archiving your idea as part of a general review. This action is based on the age of your idea and the total number of votes received, as per this announcement.
You can always post a new idea with all the details required in the form.
Thank you for your participation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
