different colours for different instances

I'd say you'd have to assemble multiple parts on top of eachother, then assign the different colors and add the components to the family table.

Thanks, Dave. This is a good method for somebody that needs to prove to the world that he can do everything in proe. Better say it just doesn't do that.

Konrad

Create multiply surfaces (copy/paste) , change color of each surface, turn on/off surfaces as needed

No graceful way, nothing that's built in. As Pro/e is the capital of the Workaround Universe, (because engineers are problem solvers and because requests for improvements will fall on deaf hears at PTC [which they have, in this case especially, for many years], here are some mighty kludges that people have come up with over the years, taken from the Google archives:

can't really fault people, including Dave Ignaczak, for trying to make Pro/e do things it was never meant to do. People put bigger and more varied demands on the program and that's how it improves. It might be appropriate to inquire in this case why they did NOT respond with an improvement.

• Well, a family of parts varies by any number of parameters: is there a color parameter? should one be invented because you want red, green and blue LEDs?

• If you want a Red LED, couldn't you just create a 'color' parameter that stores the values? is it actually necessary to show a colored model?

• If it is necessary, as part of a product presentation, why not get acquainted with photorendering, the digital ability to turn dull gray models into fully shaded, colored, reflected, textured, environmented beasts. Sophisticated means for demanding tasks, when a 'colored' model is just not enough.

• Colored models are a waste of time and just a boss-scam (Look how hard I worked, boss, making all these pretty models!)

What's to be said for this functionality, other than 'I-wish-it-therefore-this-functionality-ought-to-exist'? And possibly, a lot of people have wished it. That's something, at least. Exactly WHY is not so clear. Maybe you all are trying to solve the wrong problem.

my2c David Janes

I can't really fault people, including Dave Ignaczak, for trying to make Pro/e do

What about creating a parameter, say instance_color and making proe set the model's color according to this parameter. Now the question is how to convince proe to change the color after each rebuild. Surely needs a line or two of a program. Is there any possibility to put such programs doing something somewhere? Proe is nicely programmable, one can do a lot of nice things with C++ or something. But how to start it? Where should I search? Any thoughts? Konrad

I could not help my self getting curious about this question and looking at it for a few minutes i found that there is no elegant solution for this problem.

My first thought was that the color of a part should be implemented in the material definition, how sweet it would be if the color changed automatically as you changed the material. Well as you all know this is not the case and it would have solved this problem for sure. (better register this as a enhansment request)

As there is no changeable parameter (that i can find) that holds the color of a part my next thougt was to trigger a mapkey or JLink script that automatically changes the color at regen but there is no function in Pro/Prorgam to call an external script as far as i can see. Pro/Program really needs an upgrade to a full blown scripting language like VBScript or Javascript that enables you to create your own functions and such.

Well, well, no point in bitching about how the world could have been.

Good Luck with your problem :-)

Hugo

I wonder what could this be: pfcSession.BaseSession.SetStdColorFromRGB

Konrad

Ok I don't really understand your reply. Should I take offense to that or not lol.

What I said to do isn't complicated. My way works if you have an assembly. Or just use surfaces like "HJ" said if only in part mode.

No, it wasn't meant to be offensive :-) I can live without different colours. I would use it if it was simple, like in (perhaps) any other CAD. If it's not in proe- well, maybe in the future.

Konrad