bringToFront() works inconsistently on Macs

[ODuinn]

           I reported this issue to Adobe in April 2021 but the problem persists. The short version is that on my Mac (but not on my PC), for no apparent reason, bringToFront() works most of the time but not always.

           bringToFront() is used in a function called from pdf form menus offering a choice of a variety of pdf forms. The function opens the selected form as docB and imports the client's fdf file (which works without failure) and ends with docB.bringToFront(), which works with all of the available forms most of the time, but sometimes leaves the target pdf in the background. Regardless of whether bringToFront() is positioned in my function before or after docB.importAnFDF(), its position in the function does not cure the occasional failure to bring the document to the front.

           I would appreciate any suggestions that may eliminate the occasional failure of bringToFront().

[BarlaeDC]

Hi,

Are you able to share the code that you use so that we can try and replicate the problem?

[ODuinn]

In my code below, var pathAndForm represents the form to be opened, including its path. The target form can be any one of 20 available forms and always opens. The issue is that on a Mac, not on a PC, occasionally the form is not brought to the front; it remains in the background. It is not any particular form, it can happen with any of them. I have a MacMini and MacBook Air and this occurs on both. If I experiment with a number of the forms bringToFront() may not fail, or it may fail with one or two out of x, but usually only one or two, never all of the forms.

var docB = app.openDoc({cPath: pathAndForm, oDoc: this});

docB.bringToFront();

[BarlaeDC]

Hi,

If pathAndForm is a fully qualified path, then you would not need the oDoc parameter as this is used as a start for any relative path. Where are you calling this code from? if it from the application (menu item) then oDoc may not be a document and therefore may cause a problem.

[ODuinn]

bringToFront() is located in a folder level function. It is called from various cases in menu scripts that I created. The menus are opened from buttons. I lived with this occasional failure of bringToFront() for two years while using only an absolute path without the oDoc parameter included in the script. After adding the option to use a relative path and the oDoc parameter the failure of brintToFront() occurs no more or less frequently on the Mac, regardless of whether using either an absolute or relative path, and it does not occur at all on my PC/Windows OS.

[BarlaeDC]

Hi,

Many thanks from the response, based on the code you provided that was my best guess as to what could be going wrong, have you tried putting a try {}catch{} around the code and outputting ( or displaying a dialog to see if there is an error occuring?

try {
var docB = app.openDoc({cPath: pathAndForm, oDoc: this});
docB.bringToFront();
} catch (e) {
console.println( "error " + e)
}

[ODuinn]

Thank you. Yes, I have tried that but find no error. When bringToFront() fails, the form is opened and the data is imported but the form remains behind the calling form. 

[BarlaeDC · Accepted solution]

Hi,

In that case I have one final thing, have you tried adding a wait or pause into your code, in case the open and import is meaning the bringToFront() is being successfully run but because something else is happening to the document it doesn't actually work.

[ODuinn]

I think maybe this has solved the problem. I added

     this.delay = true;
     this.calculate = false;

at the beginning of my script and added

     this.calculate = true;
     this.delay = false;

at the end of it, then tested it. I have 20 documents that are opened and brought to the front with this script. I tested all 20 twice on my Mac without any failures of bringToFront(); I will mark your last suggestion as the correct answer. If I have failures down the road I will post again. Thank you for sticking with this. 

[BarlaeDC]

Awesome that it appears we have a solution 😄