[stephanParticipant]

Hi,

Well it would be nice if the jqxGrid could offer a more differentiated approach towards text selection, as this would reduce the need for application side corrective action, like the one mentioned by “jean-frederic” (which incidentally I am also using in an extended version, see below).

The conceptual idea is: the grid should indeed enable browser selection for the filtering row, as this makes sense. Yet it confuses most users (definitely the ones I have to deal with) to have text selection on for the grid rows area. Thus for the area with the grid rows text selecion should be off.

One way to achieve this is to use a function like the one jean-frederic mentioned. Here is the slightly larger version I am using (because it supports more browsers):

jQuery.fn.extend({
  disableTextSelect : function() {
    return this.each(function() {
      this.onselectstart = function() { return false; };
      this.unselectable = "on";
      jQuery(this).css('user-select', 'none');
      jQuery(this).css('-o-user-select', 'none');
      jQuery(this).css('-moz-user-select', 'none');
      jQuery(this).css('-khtml-user-select', 'none');
      jQuery(this).css('-webkit-user-select', 'none');
    });
  }
});

When doing it application side you can apply it on the jqxGrid element after having called the constructor:
myGrid.disableTextSelect();
My preferred solution would be to seee this integrated into jqxGrid

Here is a fiddle demonstrating the concept:
http://jsfiddle.net/q9K9w/1/

Regards,
Stephan

[stephanParticipant]

Hi Peter,

Ok, so I am hoping for a fix. Thanks for looking into this.

Regards,
Stephan

[stephanParticipant]

Hi Dimitar,

Thanks, thats exactly what I needed.

Regards,
Stephan

[stephanParticipant]

Hi Peter,

Well, the reason probably boils down to convenience: I considered using “this” the fastest and easiest way to achieve what I wanted to do: I wanted to add an extra CSS class to all rows. Here’s my rendered event (including a fix for the potentially incorrect ‘this’):

  rendered : function () {
    if (this.host != null) {
      var rows = this.host.find('div[role=row]');
      rows.addClass('my-extra-css-class');
    }
  },

I did not find an easy alternative because after calling the jqxGrid() constructor the rows aren’t there yet.

As you can see I found a simple fix for the “this” problem. I was just wondering why a checkbox column causes an extra call to the grids overall rendered event(with the column as context).

At this point there is a certain discrepancy between my expectation and what actually happens: I would expect that creating a grid would cause “rendered” to be called once at the appropriate time. Same as “initialize” gets raised once during creation and “ready” gets called once during creation. Yet I observe that “rendered” gets called multiple times, for my current grid setup it gets called 3 times.

Regards,
Stephan

[stephanParticipant]

Hi Peter,

Your solution goes along the lines of what we are now testing as a workaround: to append an extra string to the database column name before feeding it into jqxGrid, in order to prevent unsuitable names (we append an underscore). Apparently we can not use whatever name we want because some names appear to be reserved names that cause the grid constructor to fail

As always this is mainly intended to be a heads up for you. It cost us well over an hour to find out why the table suddenly complains about duplicate columns when there are no duplicate columns. So I’m putting the result of that analysis to good use by posting it here.

Regards,
Stephan

[stephanParticipant]

Hi Peter,

Yes, I realised that shortly after posting and I appologise. It was not intentional, I just wanted to make it easier for you to understand the problem that I was trying to describe. We use a lot of public code in our aplication and indeed I forgot that your source code is license protected. Since I can no longer edit my posting, but please feel free to remove the code snippet from my posting.

On the subject of the memory leakage: by removing the event manually in my own code, before calling “jqxGrid(‘destroy’)”, I can see in the memory profiler that the dangling objects now get garbage collected.

Regards,
Stephan

[stephanParticipant]

Hi Peter,

From a jqxGrid user point of view thats a rather unexpected behaviour, at least thats how I see it. After all I call “autoresizecolumn(s)” because I want the column(s) to resize permanently not temporarily.

But that aside I’d like to share the solution that I have found for my problem with the temporary nature of “autoresizecolumns”. Calling ‘setcolumnproperty’ with parameter ‘width’ causes a permanent resizing of a column that survices calls to “render”. By combining it with “autoresizecolumns” we can achieve a permanent automatic column resizing:

var colDefs = mTableObject.jqxGrid('columns').records;
for ( var idx = 0; idx < colDefs.length; idx++) {
    mTableObject.jqxGrid('autoresizecolumn', colDefs[idx].datafield, 'all');
    mTableObject.jqxGrid('setcolumnproperty', colDefs[idx].datafield, 'width', colDefs[idx].width);
}

Regards,
Stephan

[stephanParticipant]

Hi Peter,

Thanks for the info. Placing “jqx-disableselect” on the outer container works just fine and solves my problem.

Apparently placing it on the inner “myContainer” does not work, which is sad beacuse I was wondering whether I could define it just for the internal container with the grid rows

Regards,
Stephan

[stephanParticipant]

Hi Peter,

I’m not sure if this is the ideal fix, but I found that adding a null check to “appendBodyCell()” fixes the problem:

Original “appendBodyCell()”:

        this.appendBodyCell = function (data, dataType, style) {
            appendCell.call(this, data, dataType, style);
        };

My modified “appendBodyCell()”:

        this.appendBodyCell = function (data, dataType, style) {
            if (data == null) {
                data = '';
            }
            appendCell.call(this, data, dataType, style);
        };

(I found function “appendBodyCell()” in jqx-all.js on line 81081)

Regards,
Stephan

[stephanParticipant]

Hi Dimitar,

I’ve created a fiddle to test your code logic, in the hope of not getting the “tooltip stays visible” problem:
http://jsfiddle.net/_stephan_/TW79Z/4/

Sadly I was not successful: I’ve been able to reproduce the “tooltip stays visible” problem with that fiddle. The best way to reproduce it is to sweep up/down across the element in various speeds and occasionally the tooltip will not disappear. Did I do something wrong in the fiddle ?

The only sortof workaround I have found is to use a timeout in the “mouseleave”:

$("#tooltipParent").mouseleave(function () {
    setTimeout(function () {
        $("#tooltipParent").jqxTooltip('close');
    }, 100);
});

Along with setting “animationShowDelay” to 100 as well (to match the timeout).

Regards,
Stephan

[stephanParticipant]

Hi Dimitar,

Yes, thats the sortof hand coded solution I had in mind. But sadly it suffers from the same problem that I reported in a previous posting: if the mouse leaves the element with tooltip before the “open” animation has finished the tooltip will not react to the “close. Instead it will remain permanently visible. Thus I was hoping for a tooltip built-in functionality that does not suffer from this problem.

While this problem might sound like a rather constructed case, let me tell you that it happens in reality distressingly often. Typecially when you are mouving with the mouse cursor somewhere and just happen to travel across the element with the tooltip.

Regards,
Stephan

[stephanParticipant]

Hi Peter,

Well … you could close if right away despite its state. Animations can be aborted. Mainly I was hoping that you would understand the problem that results on the application side: If at the point in time where you definitely want to close the tooltip you do not know whether it has finished opening or not, it becomes difficult to actually close it …

But I have now worked around the problem by reducing the times for opening and closing snimation. An alternative might have been to put the “close” call into a “setTimeout()”, but I didnt want to go down that route.

Regards,
stephan

[stephanParticipant]

Hi Dimitar,

Thanks for the info, I’ll give it a try.

Since I didnt find this in the documentation it would be great to have it in there

Regards,
Stephan

[stephanParticipant]

Hi Dimitar,

Thanks for the info. ‘opacity’ works just fine.

Regards,
Stephan

[stephanParticipant]

Hi,

I was indeed able to work around the problem by entering my desired tooltip background colors and text color into the “Default State” section of theme builder. With this workaround the tooltip content looks ok.

The only thing that still looks odd is that the littl arrow point at the parent control is still colored light grey even though the tooltip border color has been set to a dark red. For a perfect tooltip the arrow should have the same color as the border.

Regards,
Stephan

[Author]

Posts