It’s starting to look like it would be immensely useful to hold some palette information in some tags. And before we jump on the template bandwagon, what we’re trying to do is not really possible using templates.
What exactly are you trying to accomplish?
I’ve seen style information stored database-side which makes central style control pretty easy. Maybe that would work for you?
[quote=“michael.stofan”]What exactly are you trying to accomplish?
I’ve seen style information stored database-side which makes central style control pretty easy. Maybe that would work for you?[/quote]
I agree, and that’s what ended up getting implemented, but I’d still like to see a datatype for color that encapsulates an RGBA value and/or a gradient directly. It’d be nice to avoid the whole process of putting a script that does toColor(tag("path/to/the/colorstring") and instead just directly bind a color property directly to a tag.
I am running into the same restrictions in my projects as well.
If I design a component that has properties which change fill colors and after I draw everything up in this format if people want me to change those colors…I’d have to redo my project.
EDIT:
I am looking into this right now because I can see that for my components, I’m using different layers that are fill painted to a specific color and then simply toggling their visability but… If I could bind their fill paint to a tag, I could make design changes to my projects in 1/10000000000th of the time.
This seems to be taken care of with templates in version 7.4+. You can just change the colors in the templates and all of the instances of templates will reflect the change. You can add another layer of versatility, like michael.stofan has mentioned, by having the templates refer to a set of memory tags to get their color convention. So rather than having a template object hard-codded with RED for ON/OPEN and GREEN for OFF/CLOSED, use integer memory tags called “COLORS/ON_OPEN_COLOR” and “COLORS/OFF_CLOSED_COLOR” and have the template object reference those tags. That way you can use exactly the same template objects across projects with different color conventions.
“I’m using different layers that are fill painted to a specific color and then simply toggling their visability …”
Just my opinion, but I find visibility to be a troublesome method to animate most graphical objects. It’s often difficult to see, literally, the animation algorithm that is used when layered visibility animation is employed. It’s fine when you really want an object to appear on a true condition and vanish on a false condition. But placing 2 labels on top of each other, where one says “Running” and the other says “Stopped”, is better done with a single label component and an expression binding.
[quote=“jay”]This seems to be taken care of with templates in version 7.4+. You can just change the colors in the templates and all of the instances of templates will reflect the change. You can add another layer of versatility, like michael.stofan has mentioned, by having the templates refer to a set of memory tags to get their color convention. So rather than having a template object hard-codded with RED for ON/OPEN and GREEN for OFF/CLOSED, use integer memory tags called “COLORS/ON_OPEN_COLOR” and “COLORS/OFF_CLOSED_COLOR” and have the template object reference those tags. That way you can use exactly the same template objects across projects with different color conventions.
[/quote]
… thereby creating a color tag that you still need to use toColor() on. Templates are not the one-size-fits-all solution many people make them out to be. Tags directly describing an RGBA value or gradient would be another extremely useful tool we could put to good use.
[quote=“Greg.Buehler”]
… thereby creating a color tag that you still need to use toColor() on. Templates are not the one-size-fits-all solution many people make them out to be. Tags directly describing an RGBA value or gradient would be another extremely useful tool we could put to good use.[/quote]
I took a second look at this and discovered that I can store a hexidecimal color representation as a string in a memory tag and bind it to a fill property to accomplish what I wanted (almost)
I still would like to see an actual color tag though since color coding seems to always be changing once management reviews a project and probably even more later on.
1 Like
I am currently using a Dataset as My tag's DataType, and there I added a single column with single value that can be set to DataType=Color, and it will have the color editing icon and whenever I choose to edit, it brings up the interactive color editing window nicely.
It would be excelent to be able to select this for the tag's DataType without this work over
Don't hold your breath. Such color objects are pure Java, and are not directly Perspective compatible. (This post is twelve years old. Perspective didn't exist back then.)
So what you're asking for is tags that can hold a color value, but also to be able to select that color with a palette popup of some sort ?
What would be the use case for this ?
I made a perspective color picker that may or may not be useful for this.
Sorry for opening this old post. I rather prefer (and probably a good practice(please tell me if I'm wrong)) to search existing post on the same issue and not open new ones that may be for the same or similar case.
I like to work with UDTs and define variuous UDTs for different objects/devices as needed, (even have complex UDTs that have nested innside identical or different UDTs that also may have ocasionally some UDTs inside);
In my scenario, it is much easier to define at UDT level with a memoryTAG the different color for repeated identical parts having the same UDT(inside a parent UDT) of a device rather then building custom expression logic to determine the color of different instances of that UDT in the embeddable view.
Jut seeing the visual color representation of the color type value, while navigating in the tag browser would be very handy even if editing would be only string based.
I am already successfully using in a lot of projects some UDTs that I universally built for simply decoding an INT encoded state to determine among other informations it's color. and a dataset's color type has exactly what I need
ofchourse a CustomProperty can be used instead of TAG the same way, but CustomPropertyes can not be seen when just navigation over the tags, and a drawack as I noticed(might be wrong) Custom propertyes do not propagate to instances when updated at the UDTdefinition.
You generally should open a new topic if there's anything different about your case, including extreme age. Link to similar topics in your description. (When you link, that topic will get a cross reference link automatically.)
It may be easier, it is rarely efficient. Do UI things in the UI, and leave tag structures for truly global information, that needs to be maintained even when no UI is looking at it.
Also, you really should not be encoding colors all over the place. That will be a nightmare if a client asks you to change a color. Give your colors names and use the names in the UI. The names should indicate the purpose, not "red" or "blue". Define your named colors in your theme (in Perspective) or in a single client dataset tag (in Vision).
I usually use string client tags for color setting in Vision. The color picker works well to update these on the fly.
Yes, I agree. but when I build a command center where I have a few hundred very similar plants with hundreds of identical components and get data from few tens of OPC connections, I want to use global single poit configurable things, and UDT's come in handy.
Let me show an different case example first:
In most of the cases, I get INT encoded states from the PLC. In the past I usually built logics for representing different colors and text inside projects or views, bindings, etc. but now in an even bigger project, to replicate (and ocasionally update) that same logic in hundreds or even thousands of places it would be messy.
So I developed the decoding as this old example and using it:
In this UDT example, only Cod(Code) gets data from PLC. and decoding logic is defined in one single for cases where same logic is for 60 instances and another logic for up to 240 instances.
Back to my first post: I asked if color picker or at least color visual representation cand be done just for one single tag. no datasaet, no decoding wse. I use to define read only constants as a single tag for an entire TAG folder(contaning complex structures of other folders, tags and udt's). where that folder is simmetrical to many others, only with different OPC connections) and read from more views. This way no expression logic necessary across views, just read the one single tag. I do this as strings ex. "#FF0000" but for example: "#E64A3F" is hard to know at a glace what color is set there.
I hope I explained understandable.
This is where I use dataset tags to store this info, and the lookup expression function to get the colour in my UI.
E.g.
lookup(
{System/Datasets/Maps/DeviceStatus}, // the dataset tag
{areaX/Valve01/StatusDesc}, // your device's status desc tag (e.g. "Running")
'', // fallback return
'Value', // lookup field name
'StyleClass' // return field name
)
The "StatusDesc" tag above is an expression tag linked to the "Status" tag which is a discrete-state integer tag. The expression converts the integer value into the descriptive state, and I use the descriptive tag throughout my UI to abstract the integer away from its state name.
E.g.
"StatusDesc" expr:
case({[.]Status}
, 0, 'Stopped'
, 1, 'Starting'
, 2, 'Running'
, 3, 'Stopping'
, 4, 'Faulted'
, 'INVALID'
)
2 Likes
OFFTOPIC:
Can I somehow link a theme to a tag's state or a binding's value? otherwise the logic to select the right theme will have to be all over the place. and even then, not suitable for me because it requires a separate logic for color, text and AlternativeText in different places. That was the case before I standardized the idea into UDT. ofchourse more duplicated UDTs for different decodings.
By the way: I'll have another resources related question later regarding UDTs in a new post.
nice, but in my case I have the integer to text and integer to color defined in one single place easily over-viewable. and because I have to deal with OPC data from PLCs programmed by various teams and companies, integer values never or at least not often represent the same state even for the same identical piece of hardware.
And I rarely use only textboxes and buttons. I usually, besides showing text, have to also color the objects like valves, pumps, pipes, sensors, etc. and that can not be doe only by StyleClasses so again "all over the place".
This is precisely the reason I use the status desc tag, which is included in all of my device UDTs, and maps the integer value on a per-UDT basis to the corresponding descriptive state.
The dataset intentionally excludes the integer values in it, because as you say, they could be different for different UDTs.
The descriptive states are fixed; they will not change, but they're also not tied to one integrator's whims either, they're general device states that can exist in any device. However, the dataset can also be added to in case a descriptive state needs to be added, where the colour/style is also then defined in the single place
Not sure the relevance of this bit?
I disagree.
- device symbols (valves/pumps) I colour using the Device Statuses or a Device Modes dataset
- pipes: if these must be coloured based on contents, then I have a set of P.Styles for pipework that include both an empty and filled style in case they also need to be animated based on contents. I don't currently use a dataset for these, but I could which would be similar to the device statuses, except the value would be the contents e.g. Water, Product, CIP, etc.
3 Likes
I probably misslead you by trying to express too many thing at once.
regardin pipes, At my current project I plan only to color encode a devices pipes (ex: 6 pipes of an industrial filter) according to their designation. but rather than encoding it into all related views, I plan to enode them in one of the following two ways:
A: 6 dedicated tags (named input, output, drain, etc) in six dedicated folders of a single UDT amongst other tags
B: one dataset per entire UDT containing only Text and color but in this case I think needs more resources on the gateway because *1) it has to keep in memory an additional string, *2) It has to process an additional expression to read data from the dataset using another string to compare against, hat eats again some extra memory. *3) may or may not store the result in version A: to read from views, or moving the expressions to the views bindings. and multiplying this for quite a few times needs some resources.
so in this case I prefer to not use the elegant B: option to ease gateway resources reading directly a tag's value and not a piece of a dataset.
That's why I was looking a way to see the visual color saved in a string type tag.
One of the reasons I object to storing styling information in tags is that it makes the styling universal for all operators/users. If you encounter a user with color-blindness that needs a high-contrast greyscale theme, you will have to impose it on everyone. Or whatever visual requirement someone's disability imposes. (A legal obligation in the U.S. and much of the world.) That's the whole point of offering switchable themes, and therefore to keep styling in them as opposed to using global definitions.
I strongly encourage you to alter your architecture choices before this blows up in your face. (And if a client has to do this themselves after firing you, harming your reputation.)
2 Likes