Skip to main content
A
Anonymous
July 14, 2011
Answered

app.Displaying questions

  • July 14, 2011
  • 4 replies
  • 1087 views

I'm starting to feel like this is my own personal forum. Are there really no other relative newbies out there working to incorporate ExtendScript into their workflow? Regardless, I appreciate how quickly my quickly my past questions have been answered.

Anyway, this post is two questions, both regarding screen redrawing behavior.

1) After declaring app.Displaying = false at the beginning of a script, I found my screen was redrawing anyway. After a bit of testing, it seems that FM is resetting this property to true after certain blocks of code, so I've had to re-declare the property throughout the script. My question is whether this behavior is documented anywhere. In particular, I would like to know which specific actions trigger this property reset.

2) After sprinking delarations throughout my code, my document window no longer redraws while the script is running. The Structure View, on the other hand, continues to redraw throughout. Is there a separate property somewhere I need to modify, or (if not) is there a way to collapse/expand components of the FM Interface such as the Structure View via code?

This topic has been closed for replies.
Correct answer Michael_Müller-Hillebrand

Oliver,

Please try Rick’s suggestions.

From FrameScript programming I know that .Displaying = 0 should work fine – if used to early in the development cycle it renders your documents white… which is not useful if your script crashed before finishing and turning on .Displaying . So it might be a bug in the current implementation…

Regarding the UI it is unfortunate that we do not have any access to properties of windows and/or dialogs and/or pods and/or workspaces after the invention of the new UI with FrameMaker 9. Since the presence of many dialogs can really slow down script processing it would be useful to select an »Empty« workspace before doing any automated action. Equally useful it would be to be able to open documents minimized, floating or docked…

- Michael

4 replies

A
Anonymous
July 20, 2011

Just wanted to follow-up on this. As with so many of the problems and mysteries I face while coding, once I figured it out, the answer seems obvious.

The action that was resetting the displaying property in my script was the importing of formats from one document to another--including that that wonderful giant grab-bag of miscellany known as "Document Properties."

Because, of course, if I want to transfer my PDF Conversion settings, I must also want to import FP_IsOnScreen and FP_IsInFront. </snark>

A
Anonymous
July 15, 2011

Thanks, even if they weren't the answers I was hoping for.

I'll plan on some more testing to identify exactly where the reset happens, and submit a bug report once I have more detail.

@Rick--I just added the following snippit to my main library.

function fmUpdates(boolV) { //Toggle for several refresh behaviors

    app.Validating = boolV;

    app.ApplyFmtRules = boolV;

    app.Displaying = boolV;

    return;

}

Michael_Müller-Hillebrand
Michael_Müller-HillebrandCorrect answer
Legend
July 15, 2011

Oliver,

Please try Rick’s suggestions.

From FrameScript programming I know that .Displaying = 0 should work fine – if used to early in the development cycle it renders your documents white… which is not useful if your script crashed before finishing and turning on .Displaying . So it might be a bug in the current implementation…

Regarding the UI it is unfortunate that we do not have any access to properties of windows and/or dialogs and/or pods and/or workspaces after the invention of the new UI with FrameMaker 9. Since the presence of many dialogs can really slow down script processing it would be useful to select an »Empty« workspace before doing any automated action. Equally useful it would be to be able to open documents minimized, floating or docked…

- Michael

frameexpert
Community Expert
frameexpertCommunity Expert
Community Expert
July 15, 2011

Hi Oliver,

1) I haven't seen this yet myself, but nothing is documented very well at this point :-).

2) In the FDK, there are a couple of properties that you can set to speed up scripts in structured documents. Below is a quote from the FDK User Guide. Since ExtendScript is basically a wrapper for the FDK, I am assuming that these properties will work with ExtendScript, but haven't tested them yet.

<quote>Improving performance in FrameMaker clients


If you are using the API to create FrameMaker documents, you may need to add a large number of elements or element definitions at a time. By default, FrameMaker validates elements and applies format rules each time you add an element or element definition. This can decrease performance considerably. To keep FrameMaker from validating elements and applying format rules, set the FO_Session properties FP_Validating and FP_ApplyFmtRules to False.</quote>

With ExtendScript, you would be referencing the app object and the Validating and ApplyFmtRules properties. You could try this:

app.Validating = 0;

app.ApplyFmtRules = 0;

app.Displaying = 0;

// More code here.

app.Validating = 1;

app.ApplyFmtRules = 1;

app.Displaying = 1;

Rick Quatro

www.frameexpert.com
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices