17 Replies Latest reply on Feb 17, 2017 1:48 AM by K.Daube

    Trapping "white document window"

    K.Daube Level 1

      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 files
      Open FM
      Open Simple Text
      Start Script for work with Dialog C
          Refresh ... script works correctly
      Open 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 files
      Open FM
      Open Markers and Tables
      Start Script for work with Dialog C
          Refresh ... script works correctly
      Open Simple Text
          Marke contents is default
          Check syntax operates on marker of prev. document! (known problem)
      Open Developer log
          Refresh ... script works correctly
      Switching documents etc all works
      Open From-scratch-CS-markers
          => White screen
          There seems to be one C marker in there
          Closing panel
          Closing FM is time consuming
      

       

      How 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") appears
      • Document is visible
      • Click either Yes or No and wait again (about 5 sec)
      • Document is closed, nex one is white

      Close FM with X

      Nothing 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 closes

      FM 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.

        • 1. Re: Trapping "white document window"
          Klaus Göbel Level 3

          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)

          • 2. Re: Trapping "white document window"
            K.Daube Level 1

            Hi Klaus,

            My script does not catch a close event - only these:

              Notification (Constants.FA_Note_PostActiveDocChange, true); 
              Notification (Constants.FA_Note_PostOpenDoc, true); 
              Notification (Constants.FA_Note_PostBookComponentOpen, true);

             

            I just started FM-13

            • Then I open one of the files I'm testing with
            • There are two scripts registered already :MathmLUpdate.jsx and NumberUtility.jsx
            • Start the script (it registers)
            • Open a panel by shortcut
            • Everything works as expected
            • Open another document
            • Zack- white document window

            The Script library displays the same scripts as registered as before + of course my script.

            For a next test I will outcomment all calls to SetDisplay. It is called to stop the flicker on certain actions on the document. There may be a wrong pairing (off- on) which leaves an off dangling.

            I had numerous tests without registering my script (oucommenting call to SetUpNotifications). During these 1.5h playing around I never had the White Document Window effect.

            Hence I primarily must look into the chain called from the Notify function - whether there is dangling a Display Off.

            But why the heck does CTRL+l nor executing a SetDisplay from within ESTK nothing to the display? These actions work in other cases.

            And why can the exactly repeated sequence of actions create random results - even if between tests I start FM twice to avoid "can not create Window" at the start of the script.

            • 3. Re: Trapping "white document window"
              Wiedenmaier Level 3

              Hi Klaus D,

               

              it's hard to follow and to understand what happens here exactly. If a you have a white document my guess is anyone sets display property to false. If it's set to false and document is saved, this setting is saved within the document. So if you open it again next time, document is white again.

              Could you check display property of this document?

               

              If you want me to have a deeper look into that, just send me your script by mail. And perhaps I can find out what happens here exactly.

              Markus

              • 4. Re: Trapping "white document window"
                K.Daube Level 1

                Thanks, Markus for the idea.
                At the time the white window appeared, I was able to save the document as MIF. The only occurrence of "display" is in these lines:

                 

                 <DShowAllConditions Yes>
                 <DDisplayOverrides Yes>
                 <DPageScrolling Variable>
                 <DViewOnly No>
                 <DViewOnlyXRef GotoBehavior>
                 <DViewOnlySelect Yes>
                 <DViewOnlyWinBorders Yes>
                 <DViewOnlyWinMenubar Yes>
                 <DViewOnlyWinPopup Yes>
                 <DViewOnlyWinPalette No>
                 <DFluid No>
                

                I have also checked the calling sequnces for SetDisplay - At the time of the white screen the display setting is requested to be 1, but remains 0 despite two calls for app.Displaying to become 1:

                ...
                ........CollectVariables(true)
                ..........PutRefPageCategory("Ref-Variables",[Array:#DOCname,#T1,#T2,#T3,#T4,#T5,#VAT])
                ............SaveCurrentLocation([Doc:[object Doc]])
                ............GetRefPagePara([Doc:[object Doc]],"Ref-Variables")
                ............GetParagraphs([Pgf:[object Pgf]],"Ref-Variables")
                ............RestoreLocation([Doc:[object Doc]],[Object:[object Object]])
                ........FillUserVars([ListBox:[object ListBox]])
                ........CollectMarkers([Array:[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker]],"#calc")
                ..........SetDisplay(false)
                SetDisplay - current: 0 => wanted: false
                ..........SaveCurrentLocation([Doc:[object Doc]])
                ..........GetFindParameters(3,"#calc")
                ..........RestoreLocation([Doc:[object Doc]],[Object:[object Object]])
                ..........SetDisplay(true)
                SetDisplay - current: 0 => wanted: true
                ........GetIndexNearestMarker([Array:[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker],[object Marker]],"#calc")
                ..........GetFindParameters(3,"#calc")
                ........RestoreLocation([Doc:[object Doc]],[Object:[object Object]])
                ........SetDisplay(true)
                SetDisplay - current: 0 => wanted: true
                ......DisplayMarker([Doc:[object Doc]],[Marker:[object Marker]])
                ......ActivateButtonsC()
                ......HideInsUpdButtonsC()
                UpdateDialogues wPalC.active  => White screen
                Notify triggered iNote= 26 sParm= null iParm= 0
                   object.Name=  undefined object.ID=  0
                ..RemoveMyNotifications()
                

                 

                At the time the white screen appeared I looked at consfile.txt (not disturbing the FM session). The last line at this time is 25. Then the closing of the FM session required the earier mentioned procedure and added a few lines to consfile.txt

                 

                Hence we have (most likely) trapped the cause of the white screen: app.Displaying is not set to 1 - but why?

                And there is still the question why this situation can not be repaired by CTL+l, or ESC w r, or a script in ESTK (#target framemaker) with just this: app.Displaying = 1;

                Function SetDisplay is quite simple:

                function SetDisplay (bWanted) { //=== Set display to on or off ====================================
                // 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 SetDisplay
                

                 

                From the trace (the complete log file is about 300 lines) you can see that the script is quite elaborous - If You still offer to look at it, please let me know.

                 

                It just comes to my mind: next test will be with bypassed SetDisplay (which is there only to avoid flicker during various operations).

                • 5. Re: Trapping "white document window"
                  frameexpert Level 4

                  Displaying is a Session (app) property and is not saved with the document.

                  • 6. Re: Trapping "white document window"
                    K.Daube Level 1

                    frameexpert  wrote

                     

                    Displaying is a Session (app) property and is not saved with the document.

                    Yes, I had this in mind, but needed to verify - my mind is not that reliable any more...

                    It just comes to my mind: next test will be with bypassed SetDisplay  (which is there only to avoid flicker during various operations).

                    Since in function, it was easy to let it do nothing - and lo and behold: there is only flicker, but everything works as intended! so this app.Displaying is not reliable as my trace demonstrates.

                    • 7. Re: Trapping "white document window"
                      Klaus Göbel Level 3

                      Hi Klaus,

                      the danger using notifications is, that you only get error messages in console somtimes. And sometimes NOT.

                      And it mostly ignores breakpoints when you are debugging.

                       

                      So if a script runs into an error, it may skip the rest of the code / function without any alert.

                      And so it could happen, that your function SetDisplay hasn't been executed and app.Displaying = 0 stayed alive.

                      So it may depend on where you called "SetDisplay".

                       

                      I'm just struggling with similar problems and the only way to trace the code is to use alerts and keep the console in mind.

                      • 8. Re: Trapping "white document window"
                        frameexpert Level 4

                        I haven't followed this thread or your post closely, but let me explain something important about the Displaying property. In earlier versions of FrameMaker, this property just acted like a switch; if it was already 0, it didn't hurt to set it to 0 again. So code like this wouldn't cause any harm:

                         

                        app.Displaying = 0;

                        ...

                        app.Displaying = 0;

                        ...

                        app.Displaying = 1;

                        ...

                        app.Displaying = 1;

                         

                        Somewhere along the line, Adobe made the property "stack-based" so that if you set it to 0 more than once, you have to set it to 1 an equal number of times. Not only that, but setting it to the same value multiple times seems to cause FrameMaker to hang. That is why I switched all my code to test the value before setting it.

                         

                        if (app.Displaying === 1) {

                            app.Displaying = 0;

                        }

                         

                        if (app.Displaying === 0) {

                            app.Displaying = 1;

                        }

                         

                        I can't remember when the switch was made, but I think it was with FrameMaker 11. I remember going through a period after the update where I had to update a bunch of old scripts (both FrameScript and ExtendScript) and plugins because of this new behavior.

                        • 9. Re: Trapping "white document window"
                          frameexpert Level 4

                          Here is an old post from another list by Russ Ward that shows that this is an FDK problem. Since ExtendScript and FrameScript are "wrappers" for the FDK, the problem shows up in them as well:

                           

                          Hi,

                          (compiling with FDK10 and running on FM11, Win XP, VS2008)

                          A warning here about a problem that took me more than an hour to figure out, because it was in such an unlikely place and the debugger gave no clues. In my setup, if I issue this:

                          F_ApiSetInt(0, FV_SessionId, FP_Displaying, True);

                          ...and the property is already True, FM11 will hang up for about 30 seconds. This didn't happen in earlier versions of FM. If I issue this, no hang:

                          F_ApiSetInt(0, FV_SessionId, FP_Displaying, False);
                          F_ApiSetInt(0, FV_SessionId, FP_Displaying, True);

                          ...but this does hang:

                          F_ApiSetInt(0, FV_SessionId, FP_Displaying, False);
                          F_ApiSetInt(0, FV_SessionId, FP_Displaying, True);
                          F_ApiSetInt(0, FV_SessionId, FP_Displaying, True);

                          So anyway, the gist is that you should test the current value before setting it to True. I was sticking this at the end of certain routines as a failsafe to ensure display restoration afterwards. On my machine, FM11 doesn't like it if display is already on. Complicating the problem is that the hang occurs when the code exits your function, not when you issue the SetInt() call, hence why the debugger was of marginal help.

                          If this is just an anomaly on my machine, then please disregard.

                          Russ

                          • 10. Re: Trapping "white document window"
                            frameexpert Level 4

                            BTW, this behavior was confirmed by someone on the FrameMaker team at Adobe, but I can't find the email right now.

                            • 11. Re: Trapping "white document window"
                              Wiedenmaier Level 3

                              Hi Rick,

                              thanks for bringing this background Information to FP_Displaying. I also ran into this trap several times, but I didn't know that this is put to a stack...

                               

                              And you are right, this is a Session property and it is not stored within the document. I mixed something up.

                               

                              But I remember a bug in some of mine code a long time ago.

                              I set any property to the document (I don't remember which one it was, yet). A few lines later I crashed FM with another bug in my code. (document was saved before).

                              After that I restarted FM and opened this document with "File > Open" by hand. And this document was always white. Other documents worked well.

                               

                              So there must be any setting or combination of document settings which brings up this effect.

                               

                              Markus

                              • 12. Re: Trapping "white document window"
                                Wiedenmaier Level 3

                                Klaus,

                                If you want me to give you a hand, feel free to send your code, with a short step by step description on how to reproduce this behavior by mail.

                                Markus

                                • 13. Re: Trapping "white document window"
                                  Wiedenmaier Level 3

                                  Hi Klaus G.

                                  https://forums.adobe.com/people/Klaus+G%C3%B6bel  schrieb

                                   

                                  the danger using notifications is, that you only get error messages in console somtimes. And sometimes NOT.

                                  And it mostly ignores breakpoints when you are debugging.

                                   

                                  I'm just struggling with similar problems and the only way to trace the code is to use alerts and keep the console in mind.

                                  First I have to say: This Editor In This Forum Is A PAIN :-) GRRR

                                  Sorry, just saying. and now to the topic.

                                   

                                  I never got this to work debugging notification or command events. This is also terrible. But I found out some best practice for me to work around this. Perhaps this is the time to share it :-)

                                   

                                  I always create a main script file. Here I create menus and register for notifications and here I implement Command and Notify callback, with a switch case.

                                   

                                  #include "dosomething.jsxinc";
                                  function Notify(notification, doc, sparm, iparm)
                                  {
                                      switch(notification)
                                      {
                                            case somenotification:
                                                DoSomething(doc, sparm, iparm);
                                                break;
                                      }
                                  }
                                  

                                   

                                  Within a case I only call a function which is implemented in further *.jsxinc files (extension doesn't matter, gives only a better overview in Explorer). These jsxinc files are included with "include" statement.

                                  These certain function take "doc, sparm, iparm" in function declaration of Notify-callback handlers, like:

                                   

                                  function DoSomething(doc, sparm, iparm)
                                  {
                                      //code here...
                                  }
                                  

                                   

                                  Within development process, I have a dev.jsx file, which calls these functions and sets certain Parameters, for testing and depending on the notifaction it should handle

                                   

                                  If only document is relevant, I call:

                                   

                                  DoSomething(app.ActiveDoc, "", 0);
                                  

                                   

                                  If a filename is relevant like (PreOpen Event) I call:

                                   

                                  DoSomething(app.ActiveDoc, "C:\foo.xml", 0);
                                  

                                   

                                  and so on.

                                   

                                  I made good experiences with that, and never hat big troubles when I do my integration tests. Of Course you need to know which parameter values are provided by certain notification. Here FDK reference could help and if not the old good message box handling works. But good luck with notifications which are fired very often like "BackToUser" and others.

                                   

                                  Hope this helps anyone.

                                  Markus

                                  • 14. Re: Trapping "white document window"
                                    K.Daube Level 1

                                    @Rick

                                    The 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 SetDisplay
                                    

                                    Hence 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.

                                     

                                    @Markus

                                    At 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 you

                                    It's somewhat a relief to hear that also seasoned experts have problems with ExtendScript and FDK - in particular with the lack of (some) documentation.

                                    • 15. Re: Trapping "white document window"
                                      Wiedenmaier Level 3

                                      > It's somewhat a relief to hear that also seasoned experts have problems with ExtendScript and FDK - in particular with the lack of (some) documentation.

                                       

                                      You're right. Documentation especially for ExtendScript could get much better, as - let's say it clear - there is not really one. But there is a reasonable documentation available for programming with the FDK http://www.adobe.com/devnet/framemaker.html and it is not hard to follow even if you have no C-experiences yet.

                                       

                                      In most cases follow these rules:

                                       

                                      1. Functions in C has all a prefix F_Api. In ExtendScript this is a method of the object, without this prefix. The object type where this method is definied is (mostly) the last F_ObjHandleT Parameter of each C function declaration.

                                       

                                      Examples:

                                       

                                      C: F_ApiSimpleSave(F_ObjHandleT docId, StringT saveAsName, IntT interactive)

                                      ES: doc.SimpleSave(saveAsName, interactice)

                                       

                                      C: F_ApiGetText(F_ObjHandleT docId, F_ObjHandleT objId, IntT flags);

                                      ES: obj.GetText(flags)

                                      (where obj is an FO_* listed a the beginning of function descriptions, i.e. FO_Cell, FO_Flow)

                                       

                                      2. Properties of objects in C has an Prefix FP_. In ExtendScript just skip this prefix.

                                      3. Constants in C (i.e. starting with FV_) are defined 1:1 within the ES Constants class.

                                      4. If you are reading this documentation especially sample code, skip all this memory allocation stuff like (F_Alloc; F_ApiDeallocate*, F_New, a.s.o). This is C specific and doesn't matter with ES.

                                       

                                      But to be honest. We are talking about programming. Most of the issues discussed in this Forum, can't be covered by documentation. I'm sure this is not possible to get this stuff done by any developer or writer. So you need forums, like this, blogs and a good developer support.

                                      All stuff can always be better than it is.

                                       

                                      This is not an FrameMaker/FDK/ES only problem. I develop against many APIs (Word, Trados, and several Web-APIs and more). Always the same if you come to implement your own specific use cases. My daily work is to find workarounds. All these applications/APIs are that complex today that not anything can be covered by documentation. It needs a lot of experience!!!

                                       

                                      And the good stuff on this is: With any of these problems you are getting better and better :-)

                                       

                                      So don't worry

                                      Markus

                                      • 16. Re: Trapping "white document window"
                                        Wiedenmaier Level 3

                                        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 set

                                        app.Displaying = 1
                                        

                                        as 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 event

                                        case 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

                                        • 17. Re: Trapping "white document window"
                                          K.Daube Level 1

                                          Markus, this is really a great answer.

                                          Both your recommendations work fine - i stick tot he second one: have only one handler, namely that for and test there for 'new document': PostActiveDocChanged.

                                          I already have left out the handler for Revert to Saved (), since the action triggers 3 events: PostOpenDoc (2), PostActiveDocChanged (105 and PostRevertDoc (29). I had expected that the action Revert to Saved woud trigger only the last event.

                                           

                                          Thank you, Markus, again for this great solution!