Creating Action Object Inside Locked Project

In most cases, I create an Action object inside my functions, and then send those objects to a separate function that executes them:

function executeAction(project, action) {
  try {
    project.lockedAccess(() => {
      project.executeTransaction((compoundAction) => {    
        compoundAction.addAction(action);
      });
    });
  } catch (err) {
    console.log(`Error: ${err}`);
  }
}

However, I’ve come across some Keyframe removing actions (createRemoveKeyframeAction) that always fail in my functions. According to the forum post below, there are some action objects that can only be created after locking the project:

Indeed, createRemoveKeyframeAction works inside of project.lockedAccess.

Is there any way to tell which action objects have to be created inside of a locked project?

Thanks,
Ted

I don’t think there is a way to determine this currently, but it should be standardized.

To be safe, try and always create actions inside of a locked project whenever possible.

1 Like

It’s interesting, we’ve also noticed some functions allow creating actions outside of the lockedAccess on PC, but break on Mac.

It seems the safest bet is to always create the actions inside of the lockedAccess. Of course this does add some non-ideal syntax, but we’ve found a nice way around this with a Bolt UXP helper function that accepts functions that return actions, this way you can create the functions outside, but they’re actually generated inside of the lockedAccess context.

That way you can quite easily create action-returning-functions outside and pass them in:

const actions = clips.map(
    (clip) => () => clip.createSetDisabledAction(false),
);
await asTransactionSafe(proj, actions, "Set Enabled");
1 Like