Skip to main content
New Participant
February 20, 2020
Answered

FM19 don't refresh the preview after copy a graphic by script

  • February 20, 2020
  • 1 reply
  • 1410 views

Hi,

 

I have a function that copy a selected graphic n-times to special places in my document.
After that i delete the selected graphic.

When i use the function a second time with an other grapic the gui show me the preview of the first graphic instead.

 

It happens since FM19 in FDK and in ExtendScript.

 

With this simple function i can reproduce the Bug:

function CopySelectedGraphic()
{
    test_run_count++;
    var graphic = null;
    var doc = app.ActiveDoc;
   
    if(doc.ObjectValid()) 
    {
        graphic = doc.FirstSelectedGraphicInDoc;
        if(graphic.ObjectValid() && graphic.constructor.name == "Inset")
        {
            var  new_g = doc.NewGraphicObject(Constants.FO_Inset, doc.CurrentPage.PageFrame) ;
            new_g.Width = graphic.Width;
            new_g.Height = graphic.Height;
            new_g.LocY  = (15 + (test_run_count * 25))* METRIC_MM;
            new_g.LocX  = 90 * METRIC_MM;
            new_g.InsetFile = graphic.InsetFile;                                
  
            graphic.Delete(); 
            
            doc.Redisplay();
        }
    }
}

Initial situation:

 

Steps:

  1. select "Graphic A"
  2. execute CopySelectedGraphic()
  3. select "Graphic B"
  4. execute CopySelectedGraphic()
  5. select "Graphic C"
  6. execute CopySelectedGraphic()

 

End situation:

 

After that the preview of "Graphic B" is wrong.
You see it happens only at "Graphic B" and not on "Graphic C".

 

Guess:

Inset.Delete() releases the ObjectID and the next Document.NewGraphicObject() reuse this ObjectID. If the dimensions of the selected/new graphic match the last deleted graphic, FM19 reuse the wrong preview.

 

Workarround:

Click on Zoom-Button "-" and then on "+" again.

This topic has been closed for replies.
Correct answer CSchuh

Yes that helps to automate the workaround.

 

Same in FDK:

docId = F_ApiGetId(0, FV_SessionId, FP_ActiveDoc);
displaying = F_ApiGetInt(0, FV_SessionId, FP_Displaying);

if (!displaying) F_ApiSetInt(0, FV_SessionId, FP_Displaying, True);

F_ApiSetMetric(FV_SessionId, docId, FP_Zoom, F_ApiGetMetric(FV_SessionId, docId, FP_Zoom) - 1000);
F_ApiSetMetric(FV_SessionId, docId, FP_Zoom, F_ApiGetMetric(FV_SessionId, docId, FP_Zoom) + 1000);

if (!displaying) F_ApiSetInt(0, FV_SessionId, FP_Displaying, False);

 

The 2 additional GUI refresh cycles are still annoying. I waiting for a Bugfix.

 

Chris

1 reply

Brainiac
February 20, 2020

Hi,

 

I was able to reproduce this. It definitely seems like a bug. I could not find any way to make the preview change with actions on the graphic object.

 

However, your UI workaround gave me a clue for a script workaround. I did a programmatic change to the document zoom and it had the same effect. That is, it restored the correct preview. I did this in ExtendScript after changing the graphic InsetFile:

 

doc.Zoom = doc.Zoom + 1000;
doc.Zoom = doc.Zoom - 1000;

 

It seems you have to alter the zoom at least 1%. So, I think you could use this as a workaround in your code.

 

Hope this helps,

Russ

CSchuhAuthorCorrect answer
New Participant
February 20, 2020

Yes that helps to automate the workaround.

 

Same in FDK:

docId = F_ApiGetId(0, FV_SessionId, FP_ActiveDoc);
displaying = F_ApiGetInt(0, FV_SessionId, FP_Displaying);

if (!displaying) F_ApiSetInt(0, FV_SessionId, FP_Displaying, True);

F_ApiSetMetric(FV_SessionId, docId, FP_Zoom, F_ApiGetMetric(FV_SessionId, docId, FP_Zoom) - 1000);
F_ApiSetMetric(FV_SessionId, docId, FP_Zoom, F_ApiGetMetric(FV_SessionId, docId, FP_Zoom) + 1000);

if (!displaying) F_ApiSetInt(0, FV_SessionId, FP_Displaying, False);

 

The 2 additional GUI refresh cycles are still annoying. I waiting for a Bugfix.

 

Chris

Bob_Niland
Community Expert
February 20, 2020

re: I waiting for a Bugfix.

Have you filed a bug report?.