Expanding Text Toggle - Format of expanding table depends on history

[Thomas Grehl]

Hi,

I have probably an edge case, but it is nagging me quite a bit: We use expanding text quite a bit, thousands of occurances in our projects. However, it seems that the format of the table that is used to hold the expanding part of the text is incosistent. Normally I find this:

<para styleclass="expandable heading"><image src="hmtoggle_arrow0.gif" [...]</image><tab /><toggle [...] </toggle></para>
<para styleclass="Normal" style="text-indent:-18px; margin-left:18px;"><table styleclass="Default" rowcount="1" colcount="1">

This results in a correct position of the single table cell. However, when I create the toggle in a line which has a different style than "Normal", the table (!) inherits this style which results in a wrong positioning of the table cell which is expanding. The "link" with the heading itself we format with its own style each time, but the table cell stays mis-formatted.
Even if I place the cursor in front of the table and apply "Normal" then, the indention and margin are not correctly set, I end up with something like this:

<para styleclass="expandable heading"><image src="hmtoggle_arrow0.gif" [...]</image><tab /><toggle [...] </toggle></para>
<para styleclass="Normal"><table styleclass="Default" rowcount="1" colcount="1">

which is not consistent with the default behaviour when starting right away with the Normal style.

I hope I made clear what my point is: the table position in the expandable heading should not depend on the style the line had when the toggle was inserted.

thanks,
Thomas

[Tim Green]

Hi Thomas,

There is a simple solution to this that will save you a lot of time and give you much more consistent results: Save a dummy version of each toggle type you want to use, along with all its formatting, in an XML snippet stored in your project folder. Then whenever you want to use that toggle type you just insert the snippet. You can use this method for any kind of reusable content -- for example complex tables that you often use.

[Thomas Grehl]

Hi Tim,

thanks, interesting workaround (we use snippets for other occasions), but not practicle in our case for several reasons. Mostly becaus we have many authors who each only write occasionally, so it is difficult to change their behaviour. Also, this opens the route to more problems - snippets can be linked or static, so this may result in more issues with consistency.
And honestly, the workaround is not far from "just make sure that on creation of the toggle the format is the right one" - authors forget this. A consistent behaviour of HM would be much preferred. Or at least a consintent way to update existing content without XML editing.

Thomas

[Tim Green]

Hi Thomas,

Snippets are not a workaround; they are the best possible way of doing this.

snippets can be linked or static, so this may result in more issues with consistency

Your users need to learn the difference between the two snippet modes. It's something they must know if they are going to use Help+Manual.

so it is difficult to change their behaviour

When they understand how much easier and faster it is their behavior will change automatically.

And honestly, the workaround is not far from "just make sure that on creation of the toggle the format is the right one"

That is not quite true. If you are making fully formatted toggles it replaces many individual formatting steps with a single click.

- authors forget this. A consistent behaviour of HM would be much preferred.

They won'tforget something that saves them this much work. Also, Help+Manual's behavior is consistent. When you create a new toggle it takes the format of the paragraph you are using. That is 100% consistent. If you don't want to use snippets then you just need to create a paragraph style.

Or at least a consintent way to update existing content without XML editing.

You should never need to do XML editing in Help+Manual.

[Thomas Grehl]

Hi Tim,

I understand your perspective, although it is not mine - which is ok.

My solution is a script to regularly crawl all XML files in all projects to fix this - in our environment the "cheaper" solution than changing infrequent users' behaviour.

thanks,
Thomas