Your comment about taking extra screen space is a problem I pointed out about making the names longer. Since most names are MSC to LSC (most significant character to least significant character) it's very easy to end up having to increase the width of the display to see all the characters. If the file name field is wide enough I foresee:
I'd say 512 characters might do it, because none of these will be abbreviated.
And then there will be demand that each feature in each model have that as a pre-fix so that at the top assy they can be more easily identified, is what a system admin concerned with appearance over function might say, because they don't like seeing "CSYS0" on the screen and not immediately knowing which component it belongs to.
A lot of times those super long, underscore separated fikle names are gneerated by the software doing the export becasue it has been programmed to add the date at the end, company name at the beginning, etc.
There is NO reason that when you import a file like that that it cannot be renamed before you do the import into a reasonable length file name. Users have imported STEP files and end up with P10xxx.prt component names becasue the software doesn't have a name for that component on import. Then you start getting into name conflicts as another user imports another file and Creo doesn't know that P010008,prt is already taken. Then Windchill complains that te part already exists and If lucky the second user does not foorce an override causing the first assembly to now have a wrong component.
I wholeheartedly concur...
This functional change could hardly be called an enhancement or improvement... it's an essential necessity. This "CREO IDEA" is over 5 years old. While some creo uses don't find the file name length a hindrance, many of us have a need to identify parts, assemblies, and drawings with sensible and practical names. While this is a testament to the variety of uses of creo, the length of file names should not be a limitation to those of us who would benefit by this capability. 15 years ago, 31 characters was enough to discern between parts and assemblies developed for a few clients. Now, with thousands of clients, and hundreds of thousands of distinct parts that would more easily be understood with meaningful file names, this has become a limitation of productivity and profitability, especially while trying to compete with other growing contemporary CAD providers.
It is obvious, from the Replies, that CREO is used in a vast variety of implementations. Not everybody needs the capability to use long, or even descriptive filenames for CREO files... but a great many do. And just because a computer file name could be 255 characters long (there are other limitations - because of file path), doesn't mean that the use of the longest file name possible is practical, or sensible. Anybody who wants to could still use the default short incremental file names... just please give me the contemporary tool of sufficiently long file names (maybe 50 or 55 characters would suffice for the next 10 years or so - and still leave 200 characters for the path), so that I can be descriptive when I have the need. There are occasions when sufficiently descriptive file names simply makes it easier to be productive, and competitive. If it wasn't for descriptive names, msn.com would still have to be identified by 184.108.40.206 (yes - there are already website names that exceed 31 characters and are reasonably descriptive - look it up). And I still name files in my documents directory something meaningful to me, even though I don't have 10,000 files in there.
I dug this one up while confirming the file name length and writing a batch script to rename some 600 files imported from SolidWorx. Yay, fun times.
At minimum for Legacy purposes, and for things like emails stored in WC, the length should not be limited (WC should just match Windows and other supported OSs), because when you are importing something it increases the likeliness of a poorly thought out migration where users are forced to truncate the file names and essentially lose information that was stored in the file name for many years prior to migrating to WC.
@bsingleton and all others reading, do yourselves and your customers a favor and do the following:
This way you might actually be able to narrow your search when trying to find the right document later. This is advise that I wish we received and followed during a past migration because it would have put us in a much better place now...rather than doing a search and getting a hundred files that no longer have a descriptive name and you have to open them all to find the right one...every time you do a search!
Little pain upfront, but a lot less pain and much more benefit later on (read: increased productivity & reduced user frustration).
Hopefully for you this will not be great advise too late (like Mom yelling "careful" after she hears you get hurt...or the kaboom! )
@BenLoosli and the others who mentioned random and meaningless filenames, I have a rant for you 🙂
Purely random and forced sequential filenames are stupid. Modern Databases should be able to auto create filenames and propagate attributes based off basic programming (). E.g. if I want certain parts to be in certain part ranges, why is that so hard for modern software? The inability to do this seems terribly outdated and bad/lazy programming. With very low effort I could get excel to do this, and I am can barely do VBA. If I want a filename to start with a year code, project number, model number, etc, I should be able to do that. If I can even program the naming logic in excel, then a real database should be able to do this easily without the every growing scary "C" word (Customization...ahhhhh! ).
To be able to look at a P/N and immediately understand useful information about it is powerful, and should be easy to auto number based off of basic criteria. If your database cannot do this without doing that scary "C", stuff then your database is garbage.
End Rant. 🙂
Autonumbering can be done with an OIR, but that requires you to use Windchill to create the part numbers, not Creo.
The OIR can bring in various components of your naming convention and the append a sequential number of uniqueness.
However, it is limited in how much data can be pre-assigned in the code.
If you have multiple prefixes to your parts, then something else needs to be done.
It is NOT the database that is creating the numbers automatically, it is the UI programming.
Excel can build part numbers to your specs, but someone has to program the logic into the Customized code.