[stlredlinkParticipant]

Hello Peter,

sorry my fault. ;( I just wanted to help you to find the failure. Can you remove my post than?

Best regards

[stlredlinkParticipant]

Hi Hristo,

the bug can be reproduced with combobox as columntype too. Seems like there is a bug in jqxgrid.edit.js in method _showcelleditor:

var isdataadapter = this.source._source ? true : false;

[...]

if (!isdataadapter) {
	[...]
}
else {
	var dataSource =
	{
		localdata: this.source.records,
		datatype: this.source.datatype,
		async: false
	}

	dataadapter = new $.jqx.dataAdapter(dataSource,
	{
		autoBind: false,
		async: false,
		uniqueDataFields: [displayfield],
		autoSort: true,
		autoSortField: displayfield
	});
}

[...]

editor.jqxDropDownList({ enableBrowserBoundsDetection: true, keyboardSelection: false, source: dataadapter, rtl: this.rtl, autoDropDownHeight: autoheight, theme: this.theme, width: $element.width() - 2, height: $element.height() - 2, displayMember: displayfield, valueMember: datafield });

As source for the row edit widget you pass dataadapter. But it doesn’t contain the original source data like the id settings. Later this source will be used in jqxdata.js in method dataBind to recreate `records via:

var recordid = me.getid(source.id, record, i);

if (typeof (recordid) === "object") {
    recordid = i;
}

record.uid = recordid;

But source.id is not set in the given source object.

Would be nice if that could be fixed…

Thanks in advance

[stlredlinkParticipant]

Hello Peter,

we’re facing the same problem.

Within the demo with the filter row (linked above) the user can’t type in a date with the keyboard as already stated by jessiema. It can just be inserted via the calendar popup. In that way it behaves different compared to using the date input in the menu filter or within row editing mode where it is possible to just type in the date via keyboard.

Is it a bug or is it possible to activate the same functionality for the filter row too?

Best regards

[stlredlinkParticipant]

Hi Peter,

well, yes that would work but seems more like a workaround for an obvious bug.

Problem with this workaround is is that e.g. an user maybe accidentally clicks on such an editable date column and than a date will be inserted although it wasn’t users intention.

Best regards

[stlredlinkParticipant]

Hi Peter,

well, it’s not a major problem but our customers are very fussy. To turn off autoheight and use a fixed height is not an option for us since the grid height shall be automatically set after adding or removing rows.

May in any future release this could be fixed as it seems just a little calculation problem while calculation the position of the scroll bar.

Thanks anyway.

Best regards

[stlredlinkParticipant]

Hi Peter,

thanks for your fast response. Actually your answer is not very satisfactory. It’s like a feature has bug and instead of fixing it the solution is to not use that feature. :S

By not using rowsheight it still remains the same problem – still overlapping, last row hasn’t full row height like the other rows.

So we have to get by with that overlap bug when using autoheight in combination with horizontal scroll bar?

Best regards

[stlredlinkParticipant]

Hi Christopher,

thanks for your answer. Are there any plans to implement such feature?

For now we will stick with the solution above and just reapply the current sort settings after adding, updating or removing a row as that seems to work.

Best regards

[stlredlinkParticipant]

Hello,

we’re struggling with the same issue. May you could tell us when to expect a solution for this issue? As workaround we use multiplerows instead of checkbox as selectionmode but we would rather use the checkbox mode.

Best regards

[Author]

Posts