One of the things in my current to-do list was to figure out how to display a LOV value along with it’s description. For example, If I wanted to attach the foundation level Model Velocity Unit LOV to an attribute then the possible values would be the numbers 1–7. More valuable to the user would be to show them the descriptions, which include m/sec, mm/sec, in/sec, etc.
Well, I didn’t know how to do that. Fortunately for me, I came across Dave Merrit’s “technical how-to get stuff done better and faster blog,” Dave’s Rave and his how-to post on how to attach both an LOV value and description to properties.
Like Johnny Carson used to say, “I did not know that.” So thanks, Dave!
Previously we looked at how to control part numbers with Naming Rules. Naming rules work great for many cases, but they do have limitations. The counters they use to generate a part number when a user clicks the Assign button are limited, and naming rules cannot make any corrections, other than case, of the values entered. Fortunately, they are not the only tool in the Teamcenter administrator’s toolbox. To get to the next level of control over part numbers you can develop your own user exit functions to customize how part numbers are generated and validated. So, let’s review how User Exits work, the types of things you can do with them, and how to customize them.
One of the things that had me scratching my head the first time I saw it was why you have to define both a User and a Person for every account you add to Teamcenter. And I know for a fact that I’m not the only one who’s had that question. For an in depth, detailed analysis of why Teamcenter has separate User and Person objects, continue reading…
You know what? Users are a pain in the butt. An awful lot of the work that goes into setting up Teamcenter is directed towards preventing users from making too big of a mess of things. And the very first thing that users will try to do to screw up your database is to mess around with the part numbers they assign to data. If a part number is supposed to be XXXX-YYYY, and you don’t have the proper controls in place, you’ll be pretty lucky if you don’t end up with thirteen variations of it: XXXX-YYYY, XXXX_YYYYY, CURLY.XXXX-YYYY, LARRY.XXXX-YYYY, MOE.XXXX-YYYY, XXXX-YYYY.REWORK, my_left_bracket.XXXX-YYYY, projectZ.XXXX-YYYY, etc. etc. ad infinitum, ad nauseam.
I know because I’ve had to deal with the mess users have created, and because I used to be one of those users who contributed to the mess. (doh!)
So, what kind of proper controls can you put in place? Well, keep reading…
Recently someone asked me how to create a Pseudo Folder in Teamcenter. Well, that’s sort of what happened. Actually, I noticed in the logs that someone found this blog after Googling “create pseudo folder in tcua,” and I thought, hey! that’d make a good topic for a post! It fits in with the overall theme of, “things I didn’t understand when I started using Teamcenter.” And yes, this is what is known as, “playing to your audience.”
Anyways, the answer to the question, “how do I create a Pseudo-Folder in Teamcenter” is: “you don’t”. Next question?
Okay, okay, fine. I guess I’ll explain…
If you’re programming under an NX Manager environment — that is, programming for an NX session that’s connected to Teamcenter — sooner or later you’re going to want to interact with Teamcenter for something. Maybe you need to get some information about a part that the NX Open API can’t provide, such as asking the owning group of a part. Or maybe you need to get Teamcenter to do something, like submit a part to a workflow.
Now, you might be tempted to try something like mixing ITK code with your NX Open code, and you
might get it to compile, but you’ll likely have trouble linking and you certainly won’t get it to run.
Welcome to DLL Hell, my friend. Fortunately, there’s a way out, and it’s called PDM Server