If anyone wants to put a color picker on a form and save the color here is the script that can do this.

Note:

  1. The script has to be entered as the "render" script of the form
  2. The object whose form is displayed must have a Plain Text attribute defined that will store the color (ColorAttrName in the script below)
  3. This PlainText attribute must be placed on the form anywhere. The script will replace the input control of this attribute with color picker:

var f = parser.getField ("ColorAttrName");
$("#" + f.getId ()).kendoColorPicker ({
value: f.getValue (),
buttons: false,
change: function (e) {
f.setValue (e.value);
}
});

Note also that you can change configuration of the kendoColorPicker widget as you like - just make sure that you retain:

value: f.getValue (),
change: function (e) {
f.setValue (e.value);
}

to setup the initial color into the widget and save the resulting color.

For details of configuration options for kendoColorPicker widget refer to the Kendo UI API Reference

The good news is .. this is exactly how I added the color picker to a custom form.

But I couldn't figure out the syntax for the custom rowTemplate to display the column with the row operation buttons.

Eventually I will, but if you can share that it would save me some time.

Thanks,
JT

What are you trying to achieve in a query with the color picker?

Changing rowTemplate is not a good idea generally, as Aware IM relies on it to be the default one. Some specific queries may work, but most of them will suffer the consequences.

What we are trying to achieve is as follows Support...

  1. When inline edit is on.... park on a text field that has a ColorPicker attached to it so the user selects a colour and the value is returned to that cell. It is working.
  2. Make the cell above display the background colour according to the value in the cell. It is working
  3. Achieve 1 and 2 without wiping out the Operations buttons.

The original request was to display the color in a column for each line item in a grid. I was able to do that by customizing the rowTemplate. But I wasn't able to get the row operation buttons to display in the last column.

It's unfortunate to hear that editing the rowTemplate could "break" things as it is one of the primary methods prescribed by Kendo to customize a grid.

Wasn't the intent of using Kendo to give us the flexibility to leverage it's API for things that AwareIM doesn't do OOTB?

Your documentation and tutorials refer us to the Kendo API documentation to learn it's API, right?

I've spent a TON of time doing exactly that. I can't emphasize enough how much time I've spent doing that. Now I'm hearing that doing what Kendo recommends may be a bad idea.

You are KILLING me ...

Well, you are using Aware IM, not Kendo UI, so you should listen to our recommendations, rather than Kendo UI. Obviously, not everything written in the Kendo UI documentation is directly applicable to Aware IM.

You are doing extremely well with the scripts on your own, but sometimes it pays off to purchase our support, so that we could look at the issue directly and save you some time.

We'll have a crack at this problem a little later and hopefully present a "query'" solution.

My original request was to have these background colors show up like what John achieved.
Screen Shot 2016-04-04 at 2.28.32 AM.png

The buttons to the right (Edit, Delete, etc.) are not there because we don't know what they are called to put into the template.

All we need to know is how to find the name of those.

Example:
Screen Shot 2016-04-05 at 9.20.27 PM.png

I tried the field "Edit" cause thats what its called under the name column, but that generates this runtime error in the browser:
ReferenceError: Can't find variable: Edit

jaymer...

aware_support wrote

Well, you are using Aware IM, not Kendo UI, so you should listen to our recommendations, rather than Kendo UI.

As previously stated ... I did listen to your recommendation which was to read the Kendo UI documentation.

aware_support wrote

Obviously, not everything written in the Kendo UI documentation is directly applicable to Aware IM.

How is it obvious? You told us to reference it. And how could we possibly know what is/isn't valid to use in the Kendo documentation if you don't tell us?

What is obvious is that ... we need the advanced tutorials and best practices that folks have been asking for in the first place.

aware_support wrote

... but sometimes it pays off to purchase our support, so that we could look at the issue directly and save you some time.

Seriously? I'm trying to help a couple of your customers for FREE, and you tell me that I should buy support so you could save me some time?

This is the script that shows colors in a query (has to be initialization script of the query):

for (var i = 0; i < config.columns.length; ++ i)
{
var c = config.columns;
if (c.field == "ColorAttrName")
{
var old = c.template;
c.template = function (dataItem) {
var value = old (dataItem);
if (value)
{
return "<div style='background-color:" + value + ";width:100px;height:20px;'></div>";
}
return value;
};
}
}

And this is the full Monty - with inline editing:

for (var i = 0; i < config.columns.length; ++ i)
{
var c = config.columns;
if (c.field == "Color")
{
var old = c.template;
c.template = function (dataItem) {
var value = old (dataItem);
if (value)
{
return "<div style='background-color:" + value + ";width:100px;height:20px;'></div>";
}

          return value;
    };
    c.editor = function(container, options) {
        var input = $("<input/>");
         input.attr("name", options.field);
         input.appendTo(container);
         input.kendoColorPicker({
            buttons: false
         });
      }

}
}

Why 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.

aware_support wrote

And this is the full Monty - with inline editing:

for (var i = 0; i < config.columns.length; ++ i)
{
var c = config.columns;
if (c.field == "Color")
{
var old = c.template;
c.template = function (dataItem) {
var value = old (dataItem);
if (value)
{
return "<div style='background-color:" + value + ";width:100px;height:20px;'></div>";
}

          return value;
    };
    c.editor = function(container, options) {
        var input = $("<input/>");
         input.attr("name", options.field);
         input.appendTo(container);
         input.kendoColorPicker({
            buttons: false
         });
      }

}
}

Everything thing you have here, I already had working.

There is a consistent pattern of communication breakdown. Have you read the other posts and screenshots in the other post related to this?

Note that in the screenshots ... the background of the entire column is set to the selected color. With that in mind, how do you set the background-color of the entire column <td> using the columnTemplate ... meaning not a <div> inside the <td> like you did above?

I couldn't find a way which is why is used the rowTemplate. But when using the rowTemplate, I lost the Edit/Delete buttons in the row operations column (the last column of each row).

BenHayat wrote

Why 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.

johntalbott wrote
BenHayat wrote

Why 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.

BenHayat wrote

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.

I feel like we are talking about the same thing.

This could easily be a part of a user preferences screen where a user can enter and/or select a priority and also select a color using the colorpicker that will then be associated with that priority for that user and be used in rules & queries to display the user's personalized color preference.

UserPriorityBO.User
UserPriorityBO.Name (User can select a priority ... Urgent, Normal, Low)
UserPriorityBO.Color (User can select a color of his/her choosing from the color picker)

Is there something I'm missing?

And then of course being able to reference an Attribute in a Style

At the moment we do this.....
background: #99ff66;text-align:left;font-weight:bold;font-family:Arial;color:#ff3333;

Need to be able to do it like this….
background: <<MyBO.BGColor>>;text-align:left;font-weight:bold;font-family:Arial;color: <<MyBO.FGColor>>;

johntalbott wrote
BenHayat wrote

I feel like we are talking about the same thing.

Yes we are, which is a good thing that Aware doesn't need to be modified.
However, I still would like Awaresoft to implement/bake the ColorPicker widget right into AwareIM, so we don't have to go through putting all these scripts every place we need ColorPicker.
I appreciate that you raised the bar, but there are several Kendo widgets that should be part of Aware, color picker is one of them that we all need.

I get it. Although ... the way I keep thinking about this is I don't want to have to wait for Aware to bake in a control.

Give me a relatively easy way to integrate any control I want. Then if Kendo adds something to the library I can start using it right away.

johntalbott wrote

I get it. Although ... the way I keep thinking about this is I don't want to have to wait for Aware to bake in a control.

Give me a relatively easy way to integrate any control I want.
Then if Kendo adds something to the library I can start using it right away.

That's the KEY point. And that brings up another point that I recently suggested to Support regarding Phonegap implementation.
We need an API Interface in Aware that allows us to integrate other widgets (Kendo or PhoneGap or many other JS client side) via this API that we do not need to drop down to low level JS/jquery level, but rather use the higher level API to integrate new controls and Phonegap features. If AwareSoft creates and API Interface to outside world widgets, then we will have "a relatively easy way to integrate any control I want".

Having client side interface will attract so many developers that can extend the product.