[SC10 Bug] HeaderSpan is not displayed correct

[Strag]

Description:

When HeaderSpan is enabled together with various other settings, the header titles stay half-hidden (they do not drop on the correct position) as seen in picture 1 below.

- After about 30 seconds the headers drop from alone, no action is made, no JS code is running from my code, no SC functionality is triggered from my side.
- After reloading the grid (the fields are rebuild) the problem reoccurs
- If any column is resized, all the headers "fall" to their correct position

NOTE: This bug occurs only in SC10 and not in SC9 (various versions of SC9 have been tested)

Picture 1: How it is displayed
https://dl.dropboxusercontent.com/u/18846367/pic1.PNG

Picture 2: How it should be displayed (after about 30 seconds or after resizing it is shown like this)
https://dl.dropboxusercontent.com/u/18846367/pic2.PNG


1. SC versions where the problem exists: SC10 2015-01-04 / 2015-01-20 / 2015-02-05 all in LGPL version

2. IE 10-11 / FF 32-35

6. sample of code: I tried to reproduce the bug on "SC10 Feature Explorer" but I did not manage it as I can not simulate the actual code of mine due to the non existent serverside part and communication. A configuration similar with my production grid is shown below.

Additionally:
- The grid is initially defined only with one field (time, the first one) and the other fields are dynamically loaded from the server (there are two type of fields with width 30 or 80) and at the end a "spacer" field which takes the rest of the space to fill the parent layout.

- The problem is strongly connected with the use of !!"autoFitFieldWidths"!!
-setting it false the problem disappears
-it occurs ONLY with autoFitWidthApproach="title" or "both" (with "value" the problem disappears)


autoDraw and autoFetchData are false to my production code, as the data fetch is triggered separately together with the draw.

The code is based on the example --> http://www.smartclient.com/docs/release/a/system/reference/SmartClient_Explorer.html#headerSpans

 
isc.ListGrid.create({
    ID: "countryList",
    width:750,
	height:224,
	minWidth:300,
	membersMargin:0,
//	autoDraw:false,
//	autoFetchData:false,
	alternateRecordStyles:true,
	showAllRecords: false,
	canGroupBy: false,
	showHeaderContextMenu: false,
	headerHeight:58,
 	headerSpanHeight:21,
 	headerHeight: 40,
	canSort:true,
	fixedRecordHeights:true,
	leaveScrollbarGab: false,
	autoFitMaxiWidth:"100%",
	autoFitFieldWidths: true,
	autoFitWidthApproach:"title",
	printWrapCells: false,
	printAutoFit: true,
	cellEventForDrag: null,
	canDragRecordsOut: true,
	dragDataAction:"copy",
	dragTrackerMode:"icon",
	selectionType:"single",
	dragAppearance:"tracker",
	dataSource: countryDS,
    autoFetchData: true,
    fields:[
        {name:"countryCode", title:"Flag", type:"image", imageURLPrefix:"flags/16/", imageURLSuffix:".png"},
        {name:"countryName", title:"Country"},
        {name:"capital"},
        {name:"government"},
        {name:"independence", title:"Nationhood"},
        {name:"population", title:"Population"},
        {name:"area", title:"Area (km²)"},
        {name:"gdp"}
    ],
    headerSpans: [
       
        {
            fields: ["capital", "government", "independence","population", "area"], 
            title: "Government & Politics"
        }
    ]
    
})

My temporary performance expensive workaround (in the transformResponse section)

//a is the ListGrid object
a.setAutoFitWidthApproach('both');
a.setAutoFitFieldWidths(true);
a.autoFitFields();
a.setAutoFitFieldWidths(false);

[Isomorphic]

We appreciate the valiant attempt to provide as much information as possible, but if you don't know how to reproduce the problem, it's vanishingly unlikely we'll trip on the correct combination of settings.

Take a look at the Debugging topic - there's a lot of useful advice for how to systematically simplify application logic until you arrive at a minimal test case.

[Strag]

Unfortunately it requires too much effort to simulate the exact layout due to its complexity.

To be more clear there are at least a few hundred of SC components in the view, which are dynamically created and loaded from multiple services, that one triggers the other. The current grid for example is in a tab, which is in a tabset, in a HLayout, in a tab, in a tabset, in a HLayout, in a VLayout etc... and the logic behind it is even more complex. Moreover, the JS code calling the various SC components is dynamically build in PHP, where various methods represent the SC components (that means I have to "translate" this code into JS to build a runnable example).


Additional information that may be helpful:
I tested older and newer builds from SC and resulted that the bug was first introduced into the SC10 v100p_2014-11-09.

All the SC10.0p (from 20140914 till 20141026) do not have this display problem. Additionally, I also tested the newest version of SC9.0p (20150207) which also does not have this problem.

So that limits the bug to the SC10 branch and more specifically in the changes from 2014-11-09.



As a developer, I can understand that it is hard to try to solve a bug with no test-case but I hope that I supplied you with enough information and the problem is easily recognizable in the code.

Could you please inform me if the above information is sufficient (or not) and if you are planning to take a look on that?

Thank you in advance.

[Isomorphic]

There's no reason to assume that *everything* in your application is somehow needed in order to reproduce this problem. The reverse is almost always true.

Again, we'd recommend reading the Debugging overview we recommended - if you do read it, you'll discover a process of iterative simplification that is easy to follow.

We definitely won't be looking into this as it stands - it would be a half-blind search going after something that might ultimately be a usage error or quirk of your environment that we could never reproduce anyway.

[Strag]

Thank you for your answer and your time.

I am familiar with the debugging functionality of SC and I already looked into the logs but I did not find something useful. I also tried to extend my example but with no luck on reproducing the display problem. Unfortunately I cannot invest more time on the current issue.


In case that you face the same problem in the future, I found some additional info:

- The misplacement of the headers (they are initially shown correctly and then they move "up") occurs after the call of --> grid.setViewState(param1) where param1 is a JSON object similar with the one bellow

{
		selected: [],
		field: [
			{name: "countryCode",autoFitWidth: false,width: null},
			{name: "countryName",width: null},
			{name : "capital",autoFitWidth: false,width : 80},
			{name : "government",width : null},
			{name: "independence1",width: null},
			{name: "population1",autoFitWidth: false,width: 82},
			{name: "area",width: null},
			{name: "gdp",width: null}
		],
		sort: {
			fieldName: null,
			sortDir: "ascending"
		},
		hilite: null,
		group: ""
	}

Although in logs there is not much to see (at least I do not see differences):

Attached you will find the two logs generated by SC console in versions SC10 20141026 and 20141109 exactly on the "grid.setViewState()" call. In the first version, the headers go "up" for less than a second, and they return to the correct position, in the second version they stay up till an other even is fired (like a column resize etc). Except that, the grids are displayed the same way.

As already said, that happens only with "autoFitFieldWidths" enabled, and a "title" or "both" autoFitWidthApproach.