Home Forums General XMetaL Discussion Element are going blank in xft Form Reply To: Element are going blank in xft Form

Derek Read

Reply to: Element are going blank in xft Form

The client has contacted XMetaL Support for assistance. Here is the gist of their issue for interested parties.

They have nested elements (parent / child) with a different XFT form assigned to both a parent element and one or more of its children. The original design of the software did not support this as it is optimized to render an element's XFT form and then assume there is nothing else to render inside that element (so children are skipped and any forms attached to them do not “run” whatever code they may contain). This is only an issue when the forms for parent and child are displayed before or after the elements.

There are several ways to get around this issue. I list them in order from “best” to “avoid if you can”.

1. Design your forms so a single form covers a given parent element and all of its content (including children if present). If at all possible this is the best solution. The Journalist sample customization demonstrates something like this with its author.xft form.

2. Design your customization to use “popup” forms (instead of embedded). This will work as well as #1 but obviously means having a different type of UI.

3. Enable an INI setting:

Enabling this INI setting may dramatically slow down the refresh and redraw of any document containing embedded XFT forms. This speed decrease will vary depending on how many XFT forms are in the document, the size of the document itself, complexity of the element nesting and the actual code being run within each XFT (if they interact with each other or change something in the document). It may be acceptable if your document only embeds a few XFT forms.

This INI setting was added for a specific client that had spent a long time coding up a set of XFTs (something approaching 100). Their users were living with the limitations of not being able to see some values in some forms for a long time without complaining. We implemented this INI setting to help their developers avoid needing to recode everything (which would have been ideal). Under normal circumstances an XMetaL customization should not need to use this INI setting (see #1 and #2 above).

The original intended purpose for XFT was to maybe include a few embedded forms for entering document metadata or similar — embedding XFT forms in a document will cause rendering speed to slow (and this is an exponential thing, so a few are OK, but “many” can slow some rendering down dramatically). Every XFT form instantiates its own copy of the Windows Script Host (separate from the WSH that XMetaL itself uses) so the more you have embedded in a document the more memory and CPU cycles are used.