I am designing an XDP form that uses mostly fragments developed for another form. The fragments were created by an Adobe consultant so I have to imagine they are constructed correctly. I have had this same issue in the past with fragments I too have created.
The problem is, when I drop the fragments onto my form in Design View, they rearrange themselves. As a header for each fragment, a text field with no caption is used (just to show text in a box). For some reason when all of the fragments rearrange themselves, everything stays in the correct order, EXCEPT the header field gets moved to the bottom of the fragment. If you open the fragment to edit it, however, everything appears fine. I checked the order in the hierarchy and it is also correct. The weirdest part is, when you view the form the fragments were originally created for, only one of them does this. The rest appear fine.
Could this be some kind of bug? Has anyone had this problem? If so, what did you do to fix it?
I am experiencing this problem as well, though we designed our forms ourselves. <br /><br />As a test, check out your form's XML source. We are seeing that the tool is adding a "<draw ...>" line that moves the fields within the fragment. We've tried deleting this line manually in the XML source, but the tool re-inserts it when we save the file.<br /><br />Please repost if you come across a solution, as we will do the same.
We've determined it has something to do with Positioned subforms. When they are positioned, the controls have an X,Y coordinate and that gets messed up at render time in a fragment. If you wrap everything directly under the fragment in a flowed subform it solves the problem. The issue there, unfortunately, is it changes all your path names and references. That is the issue we now face.
I don't believe it has to do with positioned subforms, because we are seeing the same behavior within fragments that are entirely flowed (western text, to be specific). Though I wonder if the extra layer of subform wrapping will do the trick...
Still seems to be a bug, but at least there's a potential work-around!
I can confirm that the subform wrapping didn't work here either.
One possible (and ugly) solution that I've seen some potential with is to edit the XDP file in a text editor (e.g., Notepad, Wordpad, Notepad++, Eclipse) and remove the extra lines of local overrides that LC Designer adds into the file. Note: you'll want to leave the line in there in order for the fragments to work (I think... not really sure what this line does exactly...).
Once these edits are done, we load the XDP files onto the Forms Server and it appears to do the trick. The problem is that you can't edit the files in Designer, or it adds the garbage back in.
Could you be a bit more specific about what line(s) to remove. I will try that, but I have to think there is a better solution. The strange part is that for us only SOME of the fragments are doing this. I have 5 fragments on the form and 3 of them are reversing. The other 2 are fine. I've been trying to compare them to see what the difference is. We've been looking in our TAB ORDER menu also. So far no luck.
Ok. Well for our issue, we found a workaround that works. Unfortunately it is not a solution, nor did we find a reason it happens. In our fragments that were reversing our hierarchy looked like this:
header (text field)
For whatever reason "header" and "content" were rendering in reverse order. In order to fix it, I simply dropped the header field inside the content field and put it to the top or that subform in the hierarchy. Now they render in the correct order. I don't know how well that may work for you, but for us that was the best solution we could come up with.
Good luck. Hopefully we can get some feedback from someone else. I fear I will run into this again someday.
I have talked to R&D about the issue and they believe it might be a bug. They woudl like to see the form and the fragments to see the issue. Can you post the form and all fragments, sample data and schemas (if applicable) to firstname.lastname@example.org and I will forward to them.
This is was a known bug in LiveCycle Designer ES (8.1) that was fixed in Designer 8.2 (now released).
The only workaround I know of is to manually edit the XML Source and specify all first-level nodes that appear in the referenced fragment in the order they should appear (basically, in the order they're defined in the referenced fragment). After doing that, the fragment should behave correctly from the referencing form. Just make sure you don't edit any of the properties on the objects inside the fragment subform from the referencing document.