Pages: 1
Print
Author Topic: Element are going blank in xft Form  (Read 2008 times)
jan.kostelansky@aerosofts
Member

Posts: 5


« on: March 31, 2014, 10:48:06 AM »

To the XMetal Comminity,

I have a form that is bound to a specific XML element, this form has text objects that display attributes of the XML element.
I'm expiriencing an odd behaviour when refreshing the form:

The text that displays the XML attributes switches to the default text value of the text object (example. Text1)
Has anyone came across that issue?

Please help this is pretty critical for our project
Logged
barbwire
Member

Posts: 44


« Reply #1 on: April 01, 2014, 12:20:19 AM »

To the XMetal Comminity,

I have a form that is bound to a specific XML element, this form has text objects that display attributes of the XML element.
I'm expiriencing an odd behaviour when refreshing the form:

The text that displays the XML attributes switches to the default text value of the text object (example. Text1)
Has anyone came across that issue?

Please help this is pretty critical for our project
Try to modify *.ctm files if you have any. They may contain example content for the elements and attributes.
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2551



WWW
« Reply #2 on: April 01, 2014, 01:38:07 PM »

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:
nested_xft_fix=true

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.
« Last Edit: April 01, 2014, 01:39:41 PM by Derek Read » Logged
Pages: 1
Print
Jump to: