Using .field().set()

omairhamid

This used to work in my inline editor. When I changed a field (called "voted" to "Yes", it would change the value in another column "responseStatus"). It has no effect now (it still works in the modal Edit form). What could have happened?

editor.dependent( 'members.voted', function ( val, data ) {
    if (val == "Yes") {
        editor.field( 'members.visitStatus').set( 'Voted' ).submit(); 
    }
} );

colin

Hi omairhamid,

When you say it "used to work", and "it has no effect now", what's changed inbetween? Did you update your code, rename fields, or update the Editor versions, etc? It would help to understand what could've broken.

Cheers,

Colin

omairhamid

The only thing really was I downloaded the 2 new/updated .js files after paying for the license...

I know I should have more details, but I don't know what else really changed. But, I guess to start, does how I am using .field().set() make sense even?

Can I share the live site URL and credentials in a DM with anyone that's interested?

Thank you

colin

Hi again omairhamid,

I've been able to reproduce kind of what you're seeing, and a recent change may have impacted it - we're looking at the code now.

Two things.

1. your usage is wrong on the command chain - submit() can't be chained to the set(), so if you do want to submit the new value (which would terminate the edit) then issue it as two commands, i.e.

editor.dependent( 'members.voted', function ( val, data ) {
    if (val == "Yes") {
        editor.field( 'members.visitStatus').set( 'Voted' );
        editor.submit();
    }
} );

1. if you're certain it used to work (which given the incorrect syntax above, the code may have also changed at some point) you can download the version you were on before - the license grants permission to use all similar versions.

Hope that helps,

Cheers,

Colin

allan

What's happening here is caused by a change that was introduced in Editor 1.7.1:

Individual cell selection and editing wasn't working (multiItem example).

That was for this example which wasn't behaving correctly before. Specifically, the problem is if you select cells to edit on multiple rows, if we have the whole row being editable it would show a "Multiple values" message, even although that isn't what you wanted to edit.

On the other hand, with that change in place, it means that only the item being edited can actually have its value set (or read).

Realistically, I think the use case presented here is more useful "in the real world" than allowing multiple cells over multiple rows to be edited together - although that is something that I would rather keep if I can.

I'm going to have a bit of a think about this and what we can do and I'll post back. Until then. using an old version as Colin says should allow this to work as before.

Regards,
Allan

allan

The change I've implemented is to introduce a new scope option into the form-options object. This lets you choose if you want the behaviour from 1.7.0 and earlier, or 1.7.1+. By default the old style behaviour will be used, as I suspect that will be the most common use case.

This fix will be in 1.7.3 which I'll release either today or tomorrow.

Regards,
Allan