Hello JJB,

I am just checking have you been able to resolve your issue? If you still need any assistance on the matter do not hesitate to ask.

Hi,

Unfortunately, we have not been able to resolve it ourselves and have not had the time to strip down our application in order to provide a sample.

I tried the sample you posted and that works fine.

Regards.

Hello JJB,

If you could provide me with the files where you define the WebHierarchicalDataGrid -the markup and  the code behind I could try to have a look at them and isolate the issue on my side.  Also is the issue reproducible with all of the browsers?

Thanks in advance.

Hello JJB,

I believe that the issue that you mentioned is caused because when you enable the column moving, group by and resizing at once and you try to resize the column, sometimes the WebDataGrid is trying to move the column instead of resizing it. In order to change this behavior we have overridden the default method that our WebDataGrid uses for the resizing by adding a some pixels bonus, so you won’t have to be as precise with the mouse during the resizing.

For additional reference I could suggest you take a look at the attached sample that I have created based on the code snippets that you provided.

If you need any additional information on this matter please feel  free to ask.  

Hi,

Thanks for the update. The sample does work well now. When we plug the override into our application, although it is considerably better, it is still not 100%. Sometimes it is very difficult to get the mouse pointer to change to the resize (double arrow) pointer and occasionally it still does not perform the expected operation. (e.g. column move rather than resize)

I would say, originally we had 20% success, Now we have about 80%. Is it possible to progress this any more?

Thanks.

Hello Damian,

I have retested the updated Sample, which Elena has uploaded and works fine on my configuration with v. 13.1.20131.2107 of NetAdvantage. I have tested it with five columns and offsets from 4 till 7 in several browsers
(Chrome, Firefox, IE10, IE9 and IE8) like the following:

rightEdgeDelta = rightEdgeDelta + 4;
leftEdgeDelta = leftEdgeDelta + 4;
brw = brw + 4;

When the resizing arrow was visible, no column moving behavior appeared.
Using offset of 3 and lower however, visually exposes the moving behavior, instead of column resizing when the resizing arrow is still visible.
The custom approach suggested, seems to expose enough flexibility to manipulate the offset, so different offset values could be used for every specific case. This behavior is not considered as a defect respectively no fixing is planned.
I suggest if you have the possibility, that you send a concrete CodeSample with the scenario you describe, so I could have a closer look at it.

Thank you for posting in the community.

This is still causing us significant problems, regardless of the values we put into the override function. We are now using 13.1.20131.2107.

Has there been any development or any hope of a proper fix?

Thanks.

I did try different values but was unable to get it any better.

Regards.

Hello JJB,

I was just wondering did you have a chance to try my suggestion. If you still need any assistance on the matter, please do not hesitate to ask.

Hello JJB,

The only thing that I changed in our original resizing behavior is the following lines:

  //This here can be modified. I'm going to add 4px offset. The area in which the two headed arrow shows will be smaller.

                    var rightEdgeDelta = Math.abs(windowScrollLeft + evnt.clientX - (elemBounds.x + elemBounds.width));

                    var leftEdgeDelta = Math.abs(windowScrollLeft + evnt.clientX - elemBounds.x);

                    rightEdgeDelta = rightEdgeDelta + 4;

                    leftEdgeDelta = leftEdgeDelta + 4;

                  brw=  brw + 4;

Therefore I could suggest you try different values of the offset (I set it to 4 still another value any be more suitable for your case).

Please let me know if you need any further details on the matter.