This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
1) <TableFields orderChanged="True"> has become <TableFields orderChanged="False">
2) All <SimpleVar>Col2 Flag</SimpleVar> have become <SimpleVar />
Although this is an example, this is REAL behavior I am experiencing in a workflow. The XML will change in the above ways SEEMINGLY AT RANDOM for random tables at random times. Running the workflow does not correct it. <SimpleVar /> will remain <SimpleVar /> and literally prevent my tables form working correctly and workflow from finishing.
I cannot share my main workflow or data due to security, but I am at least able to recreate the core of the issue as described here. Due to the seemingly RANDOM timing of the XML going bonk in my proper workflow, I have wasted considerable time on this thinking I am fixing issues but going in circles.
As @ImadZidan mentioned, your initial XML is invalid. In your column rules, you reference [Col2 Flag] In <SimpleVar>, but it doesn't exist as a <Field> in <Table Fields>. If the column doesn't exist in the input, the tool throws an error. If it does, then xml is rebuilt to add this field along with *Unknown as soon as you leave the xml window.
For <TableFields orderChanged="True">, while you can override the setting in the xml, it actually seems to be recalculated when the standard UI config window is reentered, based on comparing the order input fields to the order of the output fields. For the tests I've done with the attached workflow, if the output order doesn't match the input order the flag is set to true, otherwise it's false.
I wasn't able able to reproduce the case where the <SimpleVar>...</SimpleVar> is reset to <SimpleVar/>. Play around with the attached generic workflow and see if you can reproduce the exact steps that lead to this. If you can, post the results back here.
You can also use the attached to submit a case to email@example.com. If you decide to go this route, make sure that you have a detailed list of steps to reproduce the issue
You're right that I was missing the [Col2 Flag] in my table fields, but my issue (where the table tool changes the configuration) remained (testable via attached workflow and actions described below).
After more testing I realize my issue stems from the interaction between these items:
1) The python tool (present in my workflow) failing to send metadata
2) The table tool removing any selected="False"-like columns from the Table tool under certain circumstances.
For the following scenarios, assume the workflow 1) has a table tool which has been configured as desired 2) a python tool upstream from the table and 3) workflow has been run successfully with python tool not yet yielding the "no metadata to outgoing connection" message.
From this point, here here the actions I can take which will ruin the table configuration (by removing all selected="False" columns) :
1) Table does not have "dynamic or unknown fields" selected. I click around the UI such that the python tool yields "no metadata to outgoing connection" message. I then click on the python tool. I then click back on the table. BANG. Configuration destroyed. No issue here if "dynamic or unknown fields" IS selected. And no issue when clicking on any other tool (that I've tested).
2) I click around the UI such that the python tool yields "no metadata to outgoing connection" message. I then add a new tool between python and table. I then click back on the table. BANG. Configuration destroyed. Does not matter whether or not "dynamic or unknown fields" is selected.
3) Table does have "dynamic or unknown fields" selected. I save workflow before getting any warning/message concerning the python metadata. I re-open the workflow. BANG! Configuration destroyed. True for saving to gallery and desktop.
I wish I could fix the python issue natively but I may just have to get rid of it for simplicity.