Hello,

It is slightly hard to understand since there seems to be many things happening.

Let me try to help with few

Block UI is not displayed in timely fashion:

• I’m uncertain how Skuid Action block UI exactly works, but


• if JQuery.blockUI(.) is ran via JS that might take few MS in the background to run before UI is blocked.


• It is like an Aync process, but you cannot use await.


• If block UI doesn’t appear after 500ms or few seconds then I would question if your JS is taking up all the processing power.


• I’m also unsure why your Block Ui is displayed at all if snippet unblocks it.


• An interesting test would be disabling JS Snippet action, and seeing if Block UI still only appears after modal dispalyed

Model actions executed twice

• More required event is triggered when model is required, AND
  


• the event is also trigger when the model loads (which is when page loads).


• Workaround:
  
  • have have an action sequence that is triggered on page load which updates a variable or a value in model, e.g. PageLoaded = True.
  
  
  • Add logic branch to model actions that checks for this value
  
  

JS

• Your message didn’t indicate what your JS does.


• If there are ASYNC functions executed in your JS snippet and they are not handled with Promises/async-await then your modal will start loading before JS snippet finishes.

Hope this was somewhat helpful

Best,

Lukas

Okay, thanks.

The UI block is applied by a skuid action. The javascript takes awhile to run (60-90 seconds). It calls 8 apex processes with “var result = sforce.apex.execute().” With console.log messages between each process, we see the js step through the script slowly. At the end is the unblockUI().

If we disable the js, the action block is displayed before the modal.

Maybe JQuery.blockUI() in the script will duplicate the Version 1 behavior.

sforce.apex.execute() is the cause of your issue. As mentioned before BlockUi() is not executed immedietly, therefore before it finishes executing sforce.apex.execute() takes up all the resources, and blockUI doesn’t finish until apex returns.

My suggestion would be add artificial sleep/wait of (maybe) 100ms to allow blockUI() to execute before apex is called. It’s hard to say how long it should be since I could not find explanation of why blockUI behaves like that (it’s async but you cannot use await).

Potentially, the artificial sleep/wait could be 10ms, it’s kind of ‘try and test it’, determine the wait at your own risk. If it’s too short you will might sometimes the behavior you see now, if it’s too long you are increasing how long the entire process takes.

I don’t know what is delaying what, but my solution is to wrap the javascript code in a setTimeout() function to delay it by 500ms. That allows the Block UI With Message action to have the intended affect. The script still has an unBlockUI() at the end to release the interface.

The page-include calendar also uses a skid-page-rendered event to run another BlockUI With Message action with an 8-second timeout to allow the very slow V2 calendar to populate.

These timings work in a test environment; I cannot guarantee them for production.

Ever get this working?