Are there any known issues in this regard? When I try to resize a column, I get the resize mouse pointer but when I click and try to resize, the grid switches to repositioning the column. It takes 4 or 5 attempts to resize before it finally works. We do have and need the facility to both resize and reposition columns.
Hello JJB ,
I have been looking into your issue and I tried to reproduce it in an isolated sample still on my side everything seems to work as expected. Would you please take a look at the attached sample and modify it in order to present the behavior that you mentioned.
Thanks in advance.
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,
I have managed to modify your sample to reproduce the problem.
You can see we are on 12.1.20121.1005.
We need the functionality of resizing,repositioning and grouping within the grid.
In this sample, I would say 1 time out of 5 fails to resize the ID column, and it goes into reposition mode. In our actual application, with more columns, it is more like 4 times out of 5 fails. It does not matter how careful we are with the mouse.
Please let me know if you can run my sample and observe the problem?
We have confirmed this problem in ie8. ie9 and chrome. (I'm not sure, but there is a suggestion ie9 might not be quite as bad as ie8 ??)
Thanks.
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
<%@ Register Assembly="Infragistics4.Web.v12.1, Version=12.1.20121.1005, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb" Namespace="Infragistics.Web.UI.GridControls" TagPrefix="ig" %><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head id="Head1" runat="server"> <title></title></head><body>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.2/jquery.min.js"></script>
<form id="form1" runat="server"> <div> <asp:ScriptManager ID="ScriptManager1" runat="server" /> <ig:WebHierarchicalDataGrid AutoGenerateColumns="False" AutoGenerateBands="False" ID="WebHierarchicalDataGrid1" runat="server" Height="350px" Width="400px"> <AjaxIndicator BlockArea="Control" RelativeToControl="True" Location="MiddleCenter" /> <EmptyRowsTemplate> <asp:Label runat="server" ID="lblControlEmptyRows" Text="No records were found."></asp:Label></EmptyRowsTemplate> <GroupingSettings EnableColumnGrouping="True" InitialRowExpandState="Collapsed" EmptyGroupAreaText="Drag column(s) here to group your information."> </GroupingSettings> <Behaviors> <ig:Activation /> <ig:Paging /> <ig:ColumnMoving /> <ig:ColumnResizing Enabled="true"> <AutoPostBackFlags ColumnResized="true" /> </ig:ColumnResizing> <ig:Sorting SortingMode="Single" /> <ig:Selection CellClickAction="Row" RowSelectType="Single" CellSelectType="Single"> </ig:Selection> </Behaviors> <Columns> <ig:BoundDataField DataFieldName="id" Key="id" Width="40"> <Header Text="Id" /> </ig:BoundDataField> <ig:BoundDataField DataFieldName="Item" Key="Item" Width="150"> <Header Text="Item" /> </ig:BoundDataField> </Columns> </ig:WebHierarchicalDataGrid> </div> </form></body></html>
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.
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?
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.
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 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?
I did try different values but was unable to get it any better.
Regards.