Thanks, so I'm going to be more precise as I think that this discussion could
help others.
I'm dealing with repeating recursive structure like
function
--name
--code
----function
----name
----code
function
--name
--code
Function name is selected through a drop list box filled from a list stored
in a secondary source which includes the same recursive structures, that's to
say that describes functions wiht different recursive levels (but only none
repeating, of course).
drop list box properties/data/list box entries allows to select the
secondary source and entries which could be very powerful but unfortunately,
the three fields entries, values and display name do not allow xpath
expression, contrary to the icon bubble legend seems to say. Only the xml
tree can be selected for entries and for values and display it's even worse,
only its direct attributes may be selected.
In my case, I want :
1) at first, allow user to select any function name of the list and not the
one of the selected level (defined with entries), So an xpath expression
like //function/name instead of /function/name that entries only allows.
2) replace name with code in the result as name is interesting only for
user. It seemed that value and display name could have been designed for
that but it doesn't work for the same xpath reason.
So, the solution is to export form files (file/export) and modify it to
insert the right xpath expession. I did it and it nearly works (look at
view1.xls, search for xsl:template match=Function and change the for-each
xpath expression). But here are my xsl limits. The result is that the drop
list is well filled with all the function names, regardless their levels but
when I select one of them, I also get a red dotted rectangle around the drop
list telling me that the value is not allowed. This probably comes from an
incomplete modification but the problem is that I don't see where is the
corresponding control code.
I guess, that the problem will be the same if I try to change code using
display name and values that are in the same area.
Thinking to that, I'm wondering once again the design purpose of display
name and values as if I think that it could solve one of my problem, I think
also that It should not be very user friendly to let him choose a value and
display another one, so it would be better to fill another field
automatically.
By the way, I think that I'll have to modify the two xsl:template(s)
mode="_12" with mode="xd
reserve" in order to protect my code from Infopath
modification, like I saw in P.Halstead's book "developing solutions with
Infopath/p117"
So, finally (!), questions are :
Where is the control code of fields in extracted forms ?
What are the real purpose of display name and value, is there a bug that
does not allow full xpath expressions like in some other infopath dialog
boxes ?
Isn't it a better way to use only IE to edit those modified forms, instead
of taking them back to Infopath.
I hope this will be useful.
Thanks for answers and sorry for my broken english.
Greg Collins said:
1) What exactly is happening, 2) how did you get to there, and 3) what do you want to have happen?
--
Greg Collins [InfoPath MVP]
Please visit:
http://www.InfoPathDev.com
So, thanks to Greg Collins, it's possible to modify the view1.xsl which comes
from files/extract form files to precise xpath expressions that do not allow
(for this version I hope) properties/data/list box entries. I got just a
problem as I'm not very good with xsl : where are the validation controls
stored ? In view1 ? I didn't found how the red dotted rectangle was setted.
