doExecutePreview not firing executePreviewEvent (generally curious about events)

[Anonymous]

Hi,

I'm having difficulty getting the executePreview event to work.

Unfortunately, there is minimal documentation on the doExecutePreview() method and event firing, in general, that doesn't cover some areas of the subject. Some questions I would like to answer are when doExecutePreview() or doExecute() are called does the interpreter finish the block it's currently running (in my case the inputChanged event handler) and then enter the handler for the executePreview or execute event? After the call, does it immediately enter the handler for the executePreview or execute event, effectively doing a "return" from the current handler, not executing the rest of its code? Or a third possibility, after the call, does the interpreter enter the handler for the executePreview or execute event, execute that code, return to the handler from which it was called, and then execute the rest of the calling handler's code?

The current issue is I call doExecutePreview from the middle of my inputChanged handler and the executePreview event does not fire. The okay button is also not triggering execute event.

Any ideas for the cause of these issues?

[BrianEkins · Accepted solution]

You're correct that the documentation could be better.  This is some newer functionality that the documentation never got finished for.  I'm also not surprised that you're seeing the behavior you're seeing because it's not intended to be used in that way.

The doExecutePreview method was added for a very specific workflow; you're using a pallet to act as a command dialog.  A pallet is essentially a web browser.  It's possible that when your command is started that you can use some settings to not create a command dialog but also to allow your command to continue to run.  You can display a pallet that's displaying your HTML to gather input from the user.  When the user makes a change to the data in your pallet dialog and you want to reflect those changes in the graphics you would end up calling the doExecutePreview method which will then result in the executePreviewEvent being fired and then your command can do whatever it needs to do to update the graphics using the current values.

The doExecute method is intended to be used in a similar way except it would be used as the end of the command when the user has clicked the equivalent of the OK button in the pallet and the execute event would end up being fired.

In a regular command, you don't need to force any events to be fired but they'll be fired automatically by Fusion as a result of the current user interaction.

[Anonymous]

Thank you for clarifying Brian that makes a lot more sense. I have a few follow-up questions then about how events interact. 

I'm currently trying to create a command that initially creates 10 group command inputs (and 2 selections and 1 button (BoolValueCommandInput)) but hides 9 of them so only 1 is left for user interaction. The user can make another group command visible via the 'Add Pipe' button (until the limit is reached) and each group command has a 'Delete' button to turn its visibility off. Attached picture for reference.

I want the execute preview event to trigger if the command receives all required input for at least 1 visible pipe (aka group command) to show how that pipe would look and then show more and more pipes as the user gives each pipe's required inputs. 

This doesn't currently work since the execute preview event only triggers when ALL command inputs of the command are satisfied which includes the invisible commands. I tried to get around this with the doExecutePreview command which is where I ran into the initial issue. Is there a way to get around this and have the executePreview event fire "prematurely"?

Same question for validateInputs event since it also won't trigger until every command input is satisfied. 

[BrianEkins]

I think I've run into this before.  I think it's the selection inputs causing the problem.  Ideally, they shouldn't be considered is they're not visible but apparently that's not the case.  Instead of just making them invisible, also try disabling the selection inputs by setting the isEnabled property to False.  I think that if they're disabled, then Fusion will ignore them.

[JeromeBriot]

---

@BrianEkins wrote:

try disabling the selection inputs by setting the isEnabled property to False.  I think that if they're disabled, then Fusion will ignore them.

---

Unfortunatly: isEnabled property of the SelectionCommandInput objet