I guess yes in one scenario, one could wrap everything inside it's own span.

Good for me! I'll take that!

Thanks again

Regards,

I think you have a typo in your fix:

you need to set elem, before name. Also, having set elem, you could use it, rather than calling
$("#"+nm,"#"+frmtb) again (or drop elem altogether, and use nm=celm[0].name).

On basdub's idea for multiple inputs - I'm missing the point. Each customelement is associated with a single cell in the grid, so why would you want to post multiple values to the server?

I can see how you could want eg a datepicker and timepicker for a cell that contained a date-time. But you can do that anyway - and its still only a single value going to the server.

More generally, you /receive/ the data for the cell as a single item, why not post it back the same way? And if you do need multiple values, you can use json encoding (or any other encoding you like) to pack them into the one field...

And finally (!) I think the custom_value function should be passed the same element that custom_element created (as it does now) - if it wants multiple inputs wrapped in a span, it can create its own span 🙂

Mark

I'm just saying that the provided solution could be made EVEN MORE FLEXIBLE, as stated in POST 4 and in POST 6,  by setting the customelement class on the SPAN element and send the ENTIRE SPAN to custom_value function.

That way someone could even make ajax call to create MORE THAN ONE INPUT, SELECT, … element inside one custom_element. For example, someone could have another jGrid with mutiselect enabled as a custom element.

I think that Mark is right. We should not be limited to input elements only, but to have a freedom to put what we want (this is the primary goal of the custom elements - otherwiese you can use the standart input and do evrething what you want with him)

I have put the fix provided from Mark and tested it and it seems to work. Beside from this there was another copy paste problem

The fix is in GitHub. Will be happy if it will work for you too.

Best Regards

Tony

I said in the post 4 that i would recommend to simply put the ".customelement" class flag on the <span> tag that surrounds the custom control.

Maybe the span should be sent to the custom_value on a "get". Then, you can work with whatever is inside that span and return the appropriate value.

All in all, that was a good catch from you. The "input" is way to much strict.

Regards,

Basdub said:

But why does a customelement have to be an input? Why couldnt I use a textarea, or a select, or something of my own devising (eg, a fixed datepicker, not associated with an input).

Shouldnt it be something like:

Mark

If someone wants to have a custom element with multiple input or whatever, this might not work properly.  I would recommend setting the customelement class "flag" on the span element.

This could eventually allow the custom element to send an additional set of itemSSS that could extend the current postdata

So instead of having

We could have

Just a thought

Ok, i got it to work. Assuming we want to keep the span surrounding the customelement.... which i think is good!

In grid.formedit.js around line 543

Replace

With

Also, in the same area of the code inside the "try" there's an undefined cm. Replacing "cm" with "this" fix the issue.

All of this might need to be applied in the grid.inline.js too.

If I have time, I might send Tony a push request for this.

Maybe the "customelement" class should be set on the span element

Just to have this as a seperate topic. The value from the custom input field is not sent to the server. The fix is very easy and might apply also for inline editing.

In file grid.formedit.js around line 543. you will find the following:

In that situation, $(this) is in fact the container of the input element => <span class=”FormElement”><input…

Therefore it will never have the class customElement.

Solution:

Change

to

PS: There might be a better way to get the child control. Would like to learn it!