[SimonF]

Thanks for the fix of the sortBy attribute. It's fixed with the latest nightly (SmartClient_v100p_2015-04-10_Pro).

I found another issue while sorting the displayed fields. If you click on the header of a field the rows should be sorted. But they are only sorted after the second click. Maybe this is behaviour is on purpose if the sortfield is not specified at initialization, but in the listgrid this is already working. The sorting works correct after the second click.


This happens with latest versions of chrome and firefox and the latest nightly (SmartClient_v100p_2015-04-10_Pro).

This is reproducable with this code:

isc.TreeGrid.create({
	"ID" : "theTreeGrid",
	"width" : "100%",
	"height" : "100%",
	"selectionType" : "multiple",
	"canEdit" : false,
	"showFilterEditor" : false,
	dataSource : isc.DataSource.create({
		"fields" :
		[{
				"name" : "treeGridGeneratedIndex",
				"primaryKey" : true,
				"hidden" : true,
				"canView" : false
			}, {
				"name" : "nameField",
				"title" : "Reason",
				"type" : "text"
			}, {
				"name" : "parentId",
				"rootValue" : "2531",
				"foreignKey" : "treeGridGeneratedIndex",
				"hidden" : true
			}
		],
		"dataFormat" : "json",
		"dataURL" : "http://devset.de/treegrid.php",
		"transformRequest" : requestTransformer,
		"transformResponse" : responseTransformer,
		"recordXPath" : "\/resultData",
		useHttpProxy : false
	}),
	dataProperties : {
		openProperty : "isOpen",
		childrenProperty : "children"
	},
	"autoFetchData" : true,
	"dataPageSize" : 20,
	"dataFetchMode" : "paged",
	"selectionProperty" : "isSelected",
	"fields" :
	[{
			"name" : "nameField",
			"title" : "Reason",
			"type" : "text",
			"canEdit" : true,
			"canSort" : true
		}, {
			"name" : "lastField",
			"title" : "Name",
			"type" : "text",
			"canEdit" : true,
			"canSort" : true
		}
	],
	"selectionProperty" : "isSelected",
	"members" :
	[]
});
function requestTransformer(dataSourceRequest) {
	var operationType = {
		operationType : dataSourceRequest.operationType
	};
	if (dataSourceRequest.operationType == "fetch") {
		var params = {
			sortBy : dataSourceRequest.sortBy,
			start : dataSourceRequest.startRow,
			end : dataSourceRequest.endRow
		};
	}
	return isc.addProperties({}, operationType, dataSourceRequest.data, params);
}
function responseTransformer(dataSourceResponse, dataSourceRequest, jsonData) {
	if (dataSourceRequest.operationType == "fetch") {
		dataSourceResponse.totalRows = jsonData.totalRows;
		dataSourceResponse.endRow = jsonData.endRow;
		dataSourceResponse.startRow = jsonData.startRow;
	};
}

The hover-bug seems to only happen in chrome with the latest build (reproduced with Version 41.0.2272.118 m). The blue selection jumps to the first treenode if you haven't had any selection and you're clicking on [+] symbol. This is also reproducable with the code shown above (in chrome browser)


Thanks and best regards

[Isomorphic]

The "lack of sorting" problem has been fixed in SC 10.0p and newer. The fix will be in the nightly builds marked 4-15-2015.

[SimonF]

Thanks, the "lack of sorting" issue is fixed in the latest nightly SmartClient_v100p_2015-04-15_Pro.

The blue-selection-bug when expanding a node still exists in chrome and the latest nightly (SmartClient_v100p_2015-04-15_Pro).
Do you need more information about how to reproduce this?

[Isomorphic]

What you describe relates to rollover behavior (rather than selection, which is when you click on one or more records). We were giving that lower priority than your other reported bugs because it seemed less serious, but we are able to reproduce it and have looked at it.

There are actually two issues here, so it makes sense to distinguish them:
- Under most cases (such as if the mouse is not moving), if rollover is highlighting a given record and you expand that node, the rollover styling will disappear entirely until the mouse is moved again.
- Under rarer conditions, I see the exact behavior you mention, where the rollover highlighting jumps to the first row after clicking to expand a node on a different row. I am only able to reproduce this by moving the mouse a little bit about 1/2 second after clicking the node. This condition self-corrects when the mouse is moved again.

Are you able to live with the first behavior? That is, is what you're reporting as a bug only the second, very specific issue where rollover styling jumps to the first row instead of disappearing entirely?

[SimonF]

Hi,

Thanks for pointing this out that my observations are two different bugs.
From the enduser perspective i think both issues might be recognizable.
Afer a mouse move the rollover-states are correctly reset, but if a user doesn't move the mouse fast, there is a visible jump of the rollover from the clicked node to the first node of the treegrid.

I have regognized both issues, but was focusing by now on the second issue. I thought that the issues had something in common, so that maybe the one lead to the other.

In my oppionon, the first issue of losing the rollover state on the current opened node has a lower priority,
because the user knows where his mouse is, the blue rollover state can be "suggested".

I have more problems with issue number two, because i can reproduce it every time i open a folder (2nd folder and below).
This rollover jumping doesn't look good and everyone, who can observe this behaviour, can eaily estimate that this is an unwanted behaviour.

Please tell me if you need further informations for recreation or have other questions.

Best Regards

[SimonF]

Hi there,
Just a little feedback. I was retesting the issue with the latest nightly (SmartClient_v100p_2015-04-21_Pro) and discovered that the main issue is now solved. The rollover style is not applied to the first visible node anymore.

Like you stated out there are two different issues, so the second issues was unchanged. The newly opened node still loses the rollover-style.

Thank you very much.

[Isomorphic]

We were just about to reply here that indeed the issue you reported wherein the first row is mistakenly selected has been fixed in SC 10.0p and newer (in today's builds).

However, with regard to the second issue - that rollover hilighting is lost when a node is opened - we consider that really to be expected behavior and don't plan to backport a fix. (This behavior is also found in our Feature Explorer, for example.)

However, we may fix it in our development branch (SC 10.1d currently) as an enhancement.

[SimonF]

Thanks for the information and the fixes for all the reported, tree-related issues :-).

Because it's "only" a visual issue, it's totally understandable to not backport this small enhancement.

I'm happy to see the 10.1 release ;-)

best regards