Try splitting up the js and jsx into more events, maybe try a small $.sleep to give the different js engines time to catch up.
I.e what happens if you send an update event to the js script and then do a sleep on the jsx?
Better still If you break up the script into a conversation, let's say you have 100 squares you want to draw on the page, draw 10 then send an event from the jsx to the js that you have drawn 10, don't continue with the next 10 until the js send a message to the jsx to continue. This should give time for each of the js engines to update. Breaking a long running script up like this can also greatly improve it's performance.
If you set enableRedraw to false at the beginning of your script, it will impact any visual components of the application. That has always been the issue from ScriptUI to Flex Extensions to now and not surprisingly HTML extensions.
In ScriptUI, the workaround was to create a new window for every step the progressbar while removing the previous one. In Flex Extensions, I am not sure I ever got this to work but I imagine popping up a new window would have produced the same effect. And that would be the same stuff in a HTML Extension. The progressbar would be a poppup window you would close/open at every stage so it will be graphically updated.
I tried in the past yo commute enableRedraw on the fly (false then true then update PB then false then etc. ) but it was never concluent.
Thank you both for suggestions!
The HTML window can't be moved while the script is running etc... still no way to make a cancel button, and the the graphical interface is not updating. CEP/HTML5 doesn't seem quite ready. ScriptUI works better in CS6 than CEP/HTML5 does in CC.
There is need for a "doevents" command or "update UI" command. Something that you can call for the user to interact with the interface, and to make the interface redraw.
Back to the "Sleep(5000) test": After waiting for the script to produce 8 items*5 (seconds of sleep), in my InDesign document, the div tag with its progress bar is shown in the html interface.
Doing one or a few items at a time with repeated calls from the js part would perhaps make a difference. Not sure. But perhaps it's the jsx part that is locking up everything in the UI, despite the fact that events from the jsx are handled in the js. Then the problem would not be altogether a "single thread" issue(?).
Anyway, we have all database interaction in the jsx part, making it hard to break the loop up that is going on, and moving it to the js part. So I haven't tested this suggestion.
Changing "sleep" into "alert" made the html interface redraw, so Loic's is right that there needs to be something that really requires a redraw for the interface to update.
The ScriptUI progressbar however always showed up fine for me, and updated step by step in CC and earlier versions. I had no need to create a new window for every step in ScriptUI, as you write about Loic.
"So why not use the ScriptUI progressbar – if you think it's working", someone might ask. Well, Adobe not being able to fix the ScriptUI treeview bug we rewrote our user interface in HTML5, and so I thought we shouldn't keep the old ScriptUI progressbar either – blending different techniques – but replace it with an HTML version. It's also no good practice to let anything show from the jsx part, where ScriptUI is situated. Showing interface stuff is the responsibility of the HTML/js part of the code.
The enableRedraw setting is never changed by my Script. Nothing is seen on the document in InDesign CC until the script is completely done, despite the fact that Enable Redraw is set to True in the Scripts panel menu all the time.
There is certainly plenty of room for improvements in the User Interface part of CEP/HTML5 extensions. Trying to find workarounds for things "not thought of" is not funny... and I had hopes that the change of technology would mean some improvements, a more loosely coupled interface and better UI redraw was one expectation that was not met.