Skip to main content
Nintex Community Menu Bar

When running through some operations it may be beneficial to block the UI, and while processing update the blocked UI message every so often with a new message.


The most apparent way to do this is simply call blockUI again and specify a different message, but when this is done the UI momentarily unblocks and then the new block with the new message animates in and re-blocks the UI. This is not ideal for instances when you’d want to keep the UI blocked, but just update the message.


Here’s a way to update the message without momentarily unblocking the UI:


It’s a function called in the same way as you would call $.blockUI except if the UI is already blocked instead of blocking it again it will just update the block with the specified message.



example usage:


skuid.custom.blockUI({message: 'New or updated block message'});



//&nbsp;skuid.custom.blockUI(obj)<br>//&nbsp;blocks&nbsp;the&nbsp;UI&nbsp;with&nbsp;specified&nbsp;object&nbsp;as&nbsp;parameters&nbsp;to&nbsp;the&nbsp;blockUI&nbsp;function<br>//&nbsp;if&nbsp;the&nbsp;UI&nbsp;is&nbsp;already&nbsp;blocked,&nbsp;will&nbsp;instead&nbsp;update&nbsp;the&nbsp;existing&nbsp;block's&nbsp;message&nbsp;with&nbsp;obj.message<br>//&nbsp;rather&nbsp;than&nbsp;momentarily&nbsp;removing&nbsp;the&nbsp;block&nbsp;and&nbsp;replacing&nbsp;it&nbsp;with&nbsp;a&nbsp;new&nbsp;block<br>//&nbsp;as&nbsp;the&nbsp;standard&nbsp;blockUI&nbsp;function&nbsp;would&nbsp;do<br>skuid.custom.blockUI&nbsp;=&nbsp;function&nbsp;(obj)&nbsp;{<br>&nbsp;&nbsp;&nbsp;&nbsp;if&nbsp;($('.blockUI.blockMsg.blockPage')&nbsp;!==&nbsp;undefined&nbsp;&amp;&amp;&nbsp;$('.blockUI.blockMsg.blockPage')P0]&nbsp;!==&nbsp;undefined&nbsp;&amp;&amp;&nbsp;obj&nbsp;!==&nbsp;undefined&nbsp;&amp;&amp;&nbsp;obj.message&nbsp;!==&nbsp;undefined)&nbsp;{<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$('.blockUI.blockMsg.blockPage')P0].textContent&nbsp;=&nbsp;obj.message;<br>&nbsp;&nbsp;&nbsp;&nbsp;}&nbsp;else&nbsp;{<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$.blockUI(obj);<br>&nbsp;&nbsp;&nbsp;&nbsp;}

};


Thanks for sharing this idea, Mark.

I have a couple followup questions.

  • Are you building in v1 or v2?

  • Where have you noticed that UI momentarily unblocks between messages? In custom JS snippets, the Skuid action sequence, or both?


With the team we’ve been able to reproduce the UI momentarily unblocking between messages in v1 but not in v2.

Yes I’m still using v1 currently. There are some key features that exist in v1 but not v2 so we unfortunately can’t transition to v2 at this stage. (one feature in particular is the ability to customize CSS on the page / add CSS classes to elements)

Thanks for the quick response, Mark.  That totally makes sense. The product team is currently considering ways to integrate this functionality into v2 in a way that makes sense. I’m passing on this feedback from you as a +1 for that idea.
 
My understanding is that the main need to have CSS at the page level is to be able to assign certain styling to page elements based on different user input and actions, does this ring true for you? Do you have a need for page-level CSS that doesn’t fit in this description?

Please do let us know the other issues that are important for you to see before moving to v2 if you haven’t already given input elsewhere in the community.


Yes adding custom CSS to certain elements to control styles is great, and really needed for our implementation.

One of the most important parts of custom CSS for us is setting up custom styling on certain elements specifically for printing. For instance creating a custom “no-print” class that we can apply to certain elements to make them not show up on a printed page, or re-styling certain elements to have a better printed layout or sizing.

Another CSS class applied to an element customization we’ve found extremely helpful is the ability to make the tabs of a tab set hidden via:


.hide-tabs &gt; ul:first-of-type {<br>&nbsp;&nbsp;&nbsp;&nbsp;display: none !important;<br>}

This enables you to create a tab set where to the end-user the tabs are not visible, but in the page editor they are visible, which when paired with Display Logic on a per-tab basis allows for some new and extremely beneficial uses of tab sets.

A “hide-tabs” tab set can act as both a “comment” for the editor indicating what a particular tab is for, as well as act as a way of organizing conditional display logic based sections / elements on your pages.

Before you’d need to do something like create a series of wrappers on the page that each had different display logic which would be confusing as an editor to work with and navigate around the page editor to figure out what you were looking at. Now with the “hide-tabs” tab sets you can label your tabs so as an editor you know precisely what they are for (but the end-user doesn’t see your labels), and the conditional display sections are all are organized together in tabs rather than having to scroll around the page trying to figure out which display logic section is which and where it’s located.

Thanks for sharing Mark, that’s super handy.

And yes… styling for print.

Sidebar Buttons
Nintex Community Home Contact Nintex Support Check Nintex Status
Terms & ConditionsCookie settings