johntalbott wroteBenHayat wroteWhy not just implement the ColorPicker widget into Aware? This way instead of developer assigning static color values for styles and rules, we can provide the colorpicker to user to select their own colors. And these colors can be stores in objects to be used by Aware at runtime.
For example, If balance is greater than 100, user can select green. If balance less than 100, they can select Red. These values will be stored in an object attributes (i.e. LoogedInUser). For styles, we also need another option, that will allow us to provide Aware the object and attribute name to use the colors at runtime.
If I'm understanding you correctly, what you described is the intent of this solution. Meaning, the color picker is available to a user at run-time.
Yes, but that's only half of the solution. Currently, in Aware when we assign a color to a specific attribute, Aware gives us a choice for selecting a color. But if we let user to create their own set of colors (let's set priority colors: Urgent, normal, low) in LoggedInUser, then in Aware we can have a choice telling Aware to use (LoggedInUser) and (LowPriority) attribute (which is holding the hexa color that user had selected before) and now assign it to the style. Basically we're telling don't use your static color but go to that object and get that color and use.
This is mainly because different users different colors for the same thing. Dynamic color allocation solves this problem. The color picker gives user the choice to select it and save it, but Aware needs to pick it up at runtime and use it.
Note: I had sent a complete email to Support about two months ago on this whole Color picker and solution.
