Highlighted

Trapping "white document window"

Advocate ,
Feb 13, 2017

Copy link to clipboard

Copied

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.

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

TOPICS
Scripting

Views

4.5K

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

Trapping "white document window"

Advocate ,
Feb 13, 2017

Copy link to clipboard

Copied

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.

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

TOPICS
Scripting

Views

4.5K

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Feb 13, 2017 0
Enthusiast ,
Feb 13, 2017

Copy link to clipboard

Copied

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)

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 13, 2017 0
Advocate ,
Feb 13, 2017

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 13, 2017 0
Engaged ,
Feb 13, 2017

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 13, 2017 0
Advocate ,
Feb 14, 2017

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 14, 2017 0
Adobe Community Professional ,
Feb 14, 2017

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 14, 2017 0
Advocate ,
Feb 14, 2017

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 14, 2017 0
Enthusiast ,
Feb 14, 2017

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 14, 2017 0
Adobe Community Professional ,
Feb 14, 2017

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 14, 2017 0
Adobe Community Professional ,
Feb 14, 2017

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 14, 2017 0
Adobe Community Professional ,
Feb 14, 2017

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 14, 2017 0
Engaged ,
Feb 14, 2017

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 14, 2017 0
Engaged ,
Feb 14, 2017

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 14, 2017 0
Engaged ,
Feb 14, 2017

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 14, 2017 0
Advocate ,
Feb 15, 2017

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 15, 2017 0
Engaged ,
Feb 15, 2017

Copy link to clipboard

Copied

> 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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 15, 2017 0
Engaged ,
Feb 16, 2017

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 16, 2017 0
K.Daube LATEST
Advocate ,
Feb 17, 2017

Copy link to clipboard

Copied

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!

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Feb 17, 2017 0