Archive for XPath

How to remove initial row in repeating tables (or delete all rows) with rules only

Posted in InfoPath, XPath, browser forms, browser-enabled, templates with tags , , , , , , , , on September 10, 2009 by alecpojidaev

Bookmark that post

Special thanks: Karl D. Swartzendruber

Form to test. Web browser forms OK.

First of all you have to place your repeating group into the non repeating one. So your field structure should be looking like that:

Field structure

Field structure

Then as you can see the simple rule f=cleaningGroup will delete all rows. Now we are getting to the point why it never been implemented before. As soon as you will try to assign any value to a group InfoPath will yell at you with the message: “You must select a field. Groups do not have values and therefore cannot be assigned to by this action.” Let’s prove that at least “cannot be assigned” part of that statement is false.

It’s time for some rule breaking.

Now we will screw up the group (“f” in our case) by giving it a temporary name. Create a field at the same level as your group formerly named “f”. Name that field … guess what? Right, with the name “f”. Now InfoPath UI won’t be objecting when you’ll try to create button rule f=cleaningGroup. Delete field “f”. Rename your group back to its original name: “f”.

A mutually exclusive check box (radio button) in a repeating section

Posted in InfoPath, MOSS, XPath, browser forms, browser-enabled, templates with tags , , , , , , , , , , , on August 26, 2009 by alecpojidaev

Bookmark that post

Clean XPath only solution. Browser forms OK.
The FORM to try.

Create following field/group structure:

fields
Assign 0 as initial value to rStarter field. Assign following XPath expression as inital value to the ChBx field:

(../my:rStarter = xdMath:Max(../../my:CheckG/my:rStarter)) and (../my:rStarter != 0)

Create rule at ChBx field.
This rule has 2 actions:

  • Assign rStarter to 2 * (. != “false”)
  • Assign rStarter to 1 * (. != “false”)

Place control you like (check box or radio button) on the layout. For check box default “Value when cleared” to false and “Value when checked” to true. For radio button limit amount of choices to 1 and set “Value when selected” to true.

Thats it. Happy codeless programming!

P.S. Actually that form looks as potentially a good example to demonstrate field updating concepts like “push” and “pull” and how they are interrelate with each other. In particulary it would be interesting to explain why the sequence of operators like i=2; i=1; which have no sense in any language can be useful thing in Infopath. (Kind of a statement, eh? My only hope here is that people familiar with volatile variables concept and multithreading are not reading posts about InfoPath)

How to check if your InfoPath form is “dirty”?

Posted in InfoPath, XPath, browser forms, browser-enabled, templates with tags , , , , , , , , on July 6, 2009 by alecpojidaev

Bookmark that post

1) Create field called InitialState
2) At open event assign InitialState field to the following Xpath expression:

.. Yes, it’s two dots :)

3) At the submit rule compare InitialState field with the following expression assuming it’s a rule condition at a button:
starts-with(., my:InitialState)
Make sure the InitialState field is a very last node in the myFields group fields list.
I also believe some people might find interesting the way I used conditional expression to parameterize output message.

Here is form to test

Form with more advanced XPath (InitialState can be at any position)

Infopath codeless programming (walkthrough) 3

Posted in InfoPath, XPath, browser forms, browser-enabled, templates with tags , , , , , , on June 18, 2009 by alecpojidaev

Other parts: 1, 2.
Bookmark that post

I hope this will be the last publication about codeless programming in InfoPath. In the first two parts I demonstrated few examples where we can see implementations of ‘while’ and ‘if’ like operators. The only area remained uncovered is block of code reusable by multiple controls (analog of procedure/function). Hopefully that approach will be able to address quite frequent complains about absence of ability to copy set of actions/rules across similar controls in InfoPath UI. The essential element of that approach is hidden field with shared set of actions/rules. Form to download

Happy codeless programming!

Infopath codeless programming (walkthrough) 2

Posted in Date Picker Control, InfoPath, XPath, browser forms, browser-enabled, templates with tags , , , , , , , , , , , , , , on December 30, 2008 by alecpojidaev

Other parts: 1, 3.
Bookmark that post

Updated: 3 more forms added at the bottom: “work days calculation (excluding weekends and holidays)”, “day of the week calculation” and “Days since form was created”.

Special thanks: Karl D. Swartzendruber

So what about so called “codeless programming” in InfoPath? As we all probably know, InfoPath can performed only 16 calulations without user interaction. But what if your business rules require you to iterate through 17 repeating elements? You will get a message box from InfoPath with phrase “The rules or code may be causing an infinite loop”. Yes, in InfoPath 16 is a very big number and 17 is considered infinite. To you and I this might seem stupid and arbitrarily restrictive, but Microsoft’s wisdom is greater than ours. Perhaps they know that 17th iteration would give us developers too much power. It would break the fine balance of Microsoft applications, make other development tools obsolete, and become unbearable for non InfoPath developers. But let’s drop the light irony and just accept that InfoPath already has more codeless programming power than mere mortals should ever need.

Today’s challenge is to find the difference in days between 2 datepicker controls disregarding the absence of datediff() function in InfoPath. We are going to show that the 16 iterations limit just can’t stop the true codeless programmer.

Disclaimer: During developing cycle author has been having in mind “finite automates” principles as well as primitive binary search.

Anyway, lets get to the business. Date Difference Calculation. Form to download.

Our recipy is the following: We will need 3 fields. 2 of them are date type fields with datepicker controls (startDate, endDate) and one (dayDifference) is a text type field represented by a simple textbox. All rules have exactly 1 action.

startDate rule:

condition expession: ../my:endDate != ""
field: dayDifference
string value: 0;4096

endDate rule:

condition expession: ../my:startDate != ""
field: dayDifference
string value: 0;4096

dayDifference rules:

MainRule:

condition expession:
xdDate:AddDays(../my:startDate, substring-before(., ";")) != ../my:endDate and contains(., ";")

field: dayDifference
xPath expression: concat(substring-before(., ";") + substring-after(., ";") * ((translate(xdDate:AddDays(../my:startDate, substring-before(., ";")), "-", "") < translate(../my:endDate, "-", "")) * 2 – 1), ";", substring-after(., ";") div 2)

finalize rule:

condition expession: contains(., ";")
field: dayDifference
xPath expression: substring-before(., ";")

second

Your form is ready!

What else can be done by applying same principles:

Here is form that shows amount of days since it was created
Form that shows current day of the week and day of the week from Date Picker control.
The tricky one: Work days calculation (business days)

That’s it. Happy codeless programming!




Posted under tags: Infopath, Date Picker Control