Hi,
I have constructed a ‘table’ by using a pair of nested repeating groups. See attached file.
My problem is that the XML output is “sparse”. That is, empty cells do NOT produce empty XML tags. See example, below.
So, when I find “tic” as a value, I do not know what column it came from.
Also, it seems that the order of the cells is not maintained. “tac” comes before “tic”, even though it is right of it.
A perfect solution would be to output the numbers in parenthesis (red arrows) as XML elements, along with the value.
Question:
What is your suggestion for passing the row/column location of the cell to the XML output?
Thx,
M.
<_NonW2Rows>
<_LineNbr>24 From SCHEDULE E Attached</_LineNbr>
<_NonW2Columns>
<_NonW2Income>tac</_NonW2Income>
</_NonW2Columns
<_NonW2Columns>
<_NonW2Income>tic</_NonW2Income>
</_NonW2Columns>
</_NonW2Rows>
コメント
3件のコメント
Hello,
Are you using standard or custom XML export?
If you are using script export, you may use “for” operator instead of “foreach” operator during cycles' iteration. So you will know the exact indexes of each cell you're dealing with and you may use this information to include it into exported content as you want.
Hi,
I am currently using the standard XML export.
I would prefer to keep it that way, but I have downloaded, and am studying, the custom XML export scripts.
I'm think that I can:
1. Add two service fields to the Doc Def in FC.
2. Populate those fields from a Script Rule.
Questions:
1. Is that a reasonable approach?
2. Which field should I attache the script to? The group containing the two nested repeating groups? The outer repeating group? The inner repeating group?
3. Should that script be VBScript or an external C# assembly? Which is better at accessing and manipulating the object model?
Thx,
M.
Hello,
1. Yes, your approach seems reasonable (in fact it is the same approach that we tried to describe). Please note that "service field" is an existing pre-determined field type in Document Definition and it cannot be filled with repeating group instance number, so we are rather talking about "additional custom field" filled with a script.
2. You should implement the script on higher level that the repeating group block located itself e.g. on the level of Document Section. The table/repeating group instance itself "does not know" how many there are instances or what will be its' relative number, so you'll need to look at the collection "from outside".
3. All functions within one module must be written in the same language. Should that be C# or VBScript doesn't matter. The external assembly could be used as well, it's up to you.
サインインしてコメントを残してください。