Variables within Tables in Insets

[ASnyder28]

We use insets. We have just upgraded to FrameMaker 11 recently. We share inset files in multiple "container" FrameMaker files. When a variable is within a table in an inset, when the inset is updated in any way, the inset does not respect the variable definitions of its "container" file.

If you sweep new variables into the container file, the inset updates. As soon as you update the file via a book update or update the inset itself in the container file, the inset reverts to its own definitions. The insets are properly set to inherit their formatting/variables/conditions/etc from their container files. If the variables are outside of a table, they inherit the definitions properly. Is this a bug? Has anyone else experienced this and fixed in on their own?

[Arnis_Gubins]

I just tried this and I don't seem to get this behaviour. If I update the variable and the imported flow is set to use the curren document features, the variables tak on the correct values regardless of whether or not their in a table.

When you double-click on the text inset in the table and get the Text Inset Properties pane, check the Settings to ensure that they have "Reformat Using Current Document's Format" enabled.

[ASnyder28]

We have never seen this behavior before either. I have been using FrameMaker for about 8 years.

We have the insets set with the settings described above.

What is interesting is the problem only occurs if we edit and save the insets. If the inset hasn't changed since our upgrade, it will use the variables of the container. As soon as we edit the inset, the inset's settings win. We tried updating the variables in the container after editing the inset and everything looks okay. As soon as we update the inset, the inset's settings win again. We have found this to be the case in every container/inset combination we have looked at.

We have also tried this in two different table formats to try to rule out anything that might be in the table format that would cause this.

Short of sweep the correct variable into every inset, we haven't figured out a fix for this.

The only thing I see immediately different from your inset example and our insets is we are using UNC paths and not a letter (mapped) drive.

Update***

I just tried to use mapped drives and it didn't change anything. It is appears as though the inset has to updated using the Update function when you double-click on an inset in order to see the behavior after changing the inset. If you update a variable in the container, it will update the inset, but as soon as you update the inset, the container setting isn't respected until you change the container's definition again. This doesn't seem to follow any inset behavior I am familiar with.

[Van Kurtz]

As soon as we update the inset, the inset's settings win again.

I am probably grasping at straws here...

If you have a container file open and update the inset file, the container file probably does not update immediately, even if set to automatic update. You may have to select the inset in the container file and click Update in the Test Inset Properties dialog.

Again, I am just guessing because I am not sure of the sequence of steps you are taking...or maybe I am completely wrong about my premisses.

Van

[Arnis_Gubins]

I've tried following your steps, but I simply don't see this behaviour happening. Several questions for clarification.

1. When you "edit" the text inset source, exactly what are you changing - the variables or some other content?

2. When you say the "inset's settings" win, do you mean that the source variable definitions used in the inset show instead of those in the container file?

3. When you "update" the inset, do you mean that you've made some sort of edit to inset source file and then do a Save on that file?

4. What precisely do you mean by "sweep the correct variable into every inset" ?

6. How exactly (menu, double-click the inset & update or close & open file) are you doing the inset updates in the container files?

[ASnyder28]

Here are the answers to your questions:

1. When you "edit" the text inset source, exactly what are you changing - the variables or some other content?

Any change to the file. I can open the file, press the space bar, and save. If I update the inset in the container, the inset shows the inset's variable definitions

2. When you say the "inset's settings" win, do you mean that the source variable definitions used in the inset show instead of those in the container file?

Yes. It is using the defintions that are in the inset upon updating the inset.

3. When you "update" the inset, do you mean that you've made some sort of edit to inset source file and then do a Save on that file?

Yes and then I double-click on the inset and click Update to manually update the container to reflect my changes.

4. What precisely do you mean by "sweep the correct variable into every inset" ?

Sorry what I wrote was a bit unclear. What I meant to say was in order to ensure the variables are displayed properly, the only thing I can see to do is to sweep the variable definitions I want into the inset before publishing.

5. How exactly (menu, double-click the inset & update or close & open file) are you doing the inset updates in the container files?

I usuallly double-click on the inset within the container file and click Update.

[Arnis_Gubins · Accepted solution]

Bug confirmed - specific to FM11!

Andrea sent me a sample set of files. I had misread Andrea's initial post and missed the part about the variable being within a table in the inset source file. I had been testing pulling the inset into a table... Doooh, whack! When this scenario is pulled into the container, the variable stays per the source *only* if it is in the table. The same variable used outside of the table in the inset source does take on the container value, so one sees both values for the same variable in the inset.

Testing in FM8, 9 & 10 shows that these versions behave as expected. I've also compared the MIF versions to see if there's anything different in the FM11 version, but they're identical.

Please file a bug report at: FrameMaker Bugs & Wish List

and reference this thread: http://forums.adobe.com/thread/1141254?tstart=0