Trapping "white document window"

Question

Dear fiends,You know, the last 10% are the most cumbersome ones...With my script I get a "white document window" after opening of document files. I can not reproduce the behaviour reliably neither within FM (with menu) nor with ESTK (invoking only one function without menu). Even if the white screen appears, ESTK does not show a halt or error.Painstaikenly repeating the actions (after a double FM-restart - see later why double) the effect may happen or not:------------------------------------------------------------------------ ESTK, different sequence of filesOpen FMOpen Simple TextStart Script for work with Dialog C    Refresh ... script works correctlyOpen Markers and tables     => white screen    Working on the markers possible (but I don't see what)    CTRL-l does not do anything    Running SetDisplay from ESTK does not change the situation    Where are we stuck?    Closing panel    Closing FM is time consuming------------------------------------------------------------------------ ESTK, different sequence of filesOpen FMOpen Markers and TablesStart Script for work with Dialog C    Refresh ... script works correctlyOpen Simple Text    Marke contents is default    Check syntax operates on marker of prev. document! (known problem)Open Developer log    Refresh ... script works correctlySwitching documents etc all worksOpen From-scratch-CS-markers    => White screen    There seems to be one C marker in there    Closing panel    Closing FM is time consumingHow to catch the reason for these white screens?I can work on the document, but don't see the results...Closing FM after appearance of "white document window":Method one:For each open document:Click on X to close document, wait (15 sec) until dialog "save yes/no") appearsDocument is visibleClick either Yes or No and wait again (about 5 sec)Document is closed, nex one is whiteClose FM with XNothing happens for at least 20 sec, so I click into the window which becomes white.Click on X again => "Adobe FrameMaker is not responding"OK => Cancel => FM disappears.Method two:Close FM with X and wait until the dialog "Select the files to save before closing" appears (30 sec)OK => wait at least 10 sec, then the dialog closesFM is still open und hence i click on X=> "Adobe FrameMaker is not responding"OK => Cancel => FM disappears.Why restart FM a second time before next test?If I use the script just after a restart of FM (after the white screen happening), I get "Window can not be created" errors). Hence I need a second restart of FM. Then the script can be started again.

Wiedenmaier · Accepted Answer

@RickThe SetDisplay as I have it should fulfill the stated requirements:function SetDisplay (bWanted) {// Arguments bWanted: true => set display ON; false => display OFF // Reference Rick Quattro  if (bWanted) {  if (app.Displaying === 0) { app.Displaying = 1; }  } else {  if (app.Displaying === 1) {app.Displaying = 0; }  } } //--- end SetDisplayHence I have no clue why at a certain stage it stops working - that is, does not switch anymore.Having inserted a return before line 4 to bypass this function cures the White Screen problem, but of course leaves the user with a flickering screen.@MarkusAt least part of method to debug is present in my script - I will put it together with test files in a ZIP and send it offline to You. Maybe You find a reason for the coupling of Console output with the panels (if closing the console any panel will also be closed) - but again, not in all cases.@All of youIt's somewhat a relief to hear that also seasoned experts have problems with ExtendScript and FDK - in particular with the lack of (some) documentation.Dear Klaus D.,First thank you for providing your code. I think I've got the reason:At some certain point FM is not able to reactivate app.Displaying again. At this point you can setapp.Displaying = 1as often you want. app.Displaying is still 0.Your code is well so far. You are de-/activating app.Displaying correctly*). But I found out, that this happens, when your function UpdateDialogues() is called on PostOpenDoc event. But this same function works well, if it is called when PostActiveDocChanged is fired. Switching documents always works very well as often you are doing this.But after calling UpdateDialogues() in PostOpenDoc-event-handler, this function is called again after that in your PostActiveDocChanged-event-handler.For some reason FM doesn't like this. It comes to a state, where changing app.Displaying is not possible anymore.So I've found two solutions for you:Solution 1: setting object as current document after it is opened (line 6). You have a handler for checking current document to that in your globals variable, in PostActiveDocChange eventcase Constants.FA_Note_PostOpenDoc: // 2 another doc has been opened if (object.Name === "") { // new document PaletteDocSettings(); // set up ref page etc. } UpdateDialogues (object); goVal.oCurrentDoc = object ; break;Solution 2: Think about if you really need the PostOpenDoc event handler, as PostActiveDocChanged is called afterwards. If not put the if clause to PostActiveDocChanged event handler, and this also works.*)SetDisplay function is a little bit smarter and better readable if you implement it like this:function SetDisplay (bWanted) if (settings.bDebug) {  ....  } if (app.Displaying != bWanted) { app.Displaying = bWanted; }} //--- end SetDisplay(but of course this is up to you)Hope this helps. Let me know if Problem is solved in your environment, too.Markus

Klaus Göbel · Answer

Hi Klaus,my first and quick guess is:there's a registered script in the background that catches the "close"-event. (reason for the slow ending)In that script there's "display = 0" (the reason for white screen)

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded