[pguzParticipant]

Peter,

I beg to differ – there are additional elements shown in the Profiler, having taken snapshots before creating the ListBoxes, and after destroying, and these have jqx classes. There is also nothing else on the page that would be adding or removing DOM elements.

I’d include a Profiler screenshot showing an Input element from the listbox (the filter box assumedly) but there is no way to do so on this forum. I could email it to you if you like.

To reproduce, open the fiddle, take a Heap Snapshot in Profiler, click Create, take another snapshot, click Destroy, take a third snapshot. Compare Snapshot 3 to 1 and you will see +5 HTMLDivElements. Expand the Detached DOM Tree to see the jqx elements.

Paul

[pguzParticipant]

Thanks Dimitar, I’ve used that code and it seems fine for now.

Of course, that does not address the ‘return false’ bug. We are using v3.5 – will there be a bug fix applied retrospectively to that version?

Paul

[pguzParticipant]

Thanks Dimitar. It’s not a great workaround as it means the drop cannot be rejected if dropItem is null.

It would be a big help if in future dropItem is set to be the listBox itself if dropping on the empty portion. Currently I cannot find a reliable way of determining the drop location if dropItem is null. Previous suggestions found on this forum include trying to figure out the drop target from the mouse co-ordinates (which I doubt is reliable) or comparing listbox item counts in dragStart and dragEnd (but they are always the same as the item doesn’t get added until after dragEnd!).

In addition, please provide a dropTarget property for the listbox. I doubt it would be hard to expose the underlying dropTarget property from jqxDragDrop.

[pguzParticipant]

Thanks Peter. I’ve realised that I don’t need to be using displayField anyway – each row already has the id set via the dataAdapter.

[pguzParticipant]

OK, your editor doesn’t work as it didn’t insert the link despite using the ‘link’ button above.

Here’s the example: http://jsbin.com/sexupocecu/1/edit?html,js,output

[pguzParticipant]

Thanks Peter, I will do it that way. I assume that the bug has been noted.

Paul

[pguzParticipant]

Nadezhda,

I do not want to get the new item, I want to get the item being unselected, as I show and hide a delete icon depending on whether the item is selected.

It works perfectly well when filterable = false.

Please look at the fiddle again – args.item and args.index have values when filterable = true but not when filterable = false.

This looks like a bug to me.

Paul

[pguzParticipant]

Peter,

I can’t use rowselect as I need to know which column was clicked on. My click event handler is specific to the cell clicked on.

Re the grestures, I am talking about the conceptual difference between tapping and dragging gestures – the two are different concepts in the world of touch device usage. A tap is a quick press-and-release action. A drag is press-slide-release. It must be possible to detect the latter – e.g. if the user’s finger is in a different position on release, then do not fire the ‘click’ event.

[pguzParticipant]

Thanks Peter.

Unfortunately, I can’t use cellselect as I am using singlerow selectionmode.

I am not using the grid’s own scrollbars as I find them slow on mobile devices with large grids. Web page scrolling is much smoother.

Regarding your comment “cellclick is raised on tap, drag happens on tap and move” – dragging and tapping are different gestures and I believe that all widgets should differentiate between the two if possible.

Paul

[pguzParticipant]

Peter,

My point exactly – lines 30 and 31 of the sample mitigate against this bug by checking if the value of ‘direction’ is a string and converting it to a boolean. Your own code seems to acknowledge the bug.

My point was that it should be either a string or boolean at all times, not switching between the two.

Paul

[pguzParticipant]

Hi Peter,

You say that each widget has specific CSS classes applied, but my point here is that the grid and scrollbar are sharing a class for different purposes. I can understand that it may be desirable to have the same class for highlighting across all widgets, but I don’t think it’s appropriate in this case.

Paul

[pguzParticipant]

Are there plans to fix it?

Paul

[Author]

Posts