InfoPath Dev

I have a browser-enabled form with a Date Picker bound to a query field on the main data source. I also have a Repeating Table bound to data fields on the main data source. I set up conditional formatting on one of the columns in the repeating table that compares a data field on the main data source (which contains a date) with the date that the Date Picker is bound to. If they match, then the value in the cell should displayed normally; if they don't match, the value in the cell should be italicized.

The results are inconsistent:

1) When I test it in visual studio, it works correctly.
2) When I publish it to OFS and allow the browser to run it in the InfoPath client, the text is always displayed normally.
3) When I use the OpenIn=browser option to force the form to be rendered in the browser, the text is always italicized.

Does anybody know why this would happen and how to fix it?

Thanks in advance!

Additional information: The Date Picker is set to always post back when the value changes. The "changed" event for the field to which the Date Picker is bound executes the main query to load new data in the Repeating Table.

Try placing an expression box or a plain text version of each date where you can see them. Perhaps what is happing is has nothing to do with the date, but the time portion of the date... For example you might find that you are trying to compare:

2007-03-12 against 2007-03-12T00:00:00

or something like that.

Thanks for your response! I tried it adn it appears that there are multiple, separate problems.

1) In debug within Visual Studio, the format of the fields match and it works.
2) After publishing to OFS and allowing the browser to open the form in the InfoPath client, I get the *old* version of the form without the new fields I added! What's up with that?
3) Forcing the form to render in the browser, I get the new form, but the Date Picker adds "T00:00:00" to the value when it is used to change the date.
4) I think part of the problem stems from the fact that InfoPath decided at design time that the date fields are text fields instead of date fields. (The data comes in from a web service as an XmlDocument.)

You might need to do some work to get some cleanup to happen the, like haveing a rule one the field which sets the field with a substring of itself... or perhaps have your comparison just compare the strings before any "T" character (if it exists).

Not sure why the web site is serving up the old form...

Here's what I've figured out so far about the web site serving up the old form:

I publish the new version to a directory that is available to the admin account. Then I go into Central Administration | Application Management | Manage Form Templates and I upload the new version choosing the option to upgrade the form template if it already exists. It creates a job that requires me to use the stsadm command in order to execute, which I do. I have a web site that is part of this farm. In that web site I have a Form Templates list. The list contains an older version of the template. I use the URL to the form in this list in *both* cases. If I allow the browser to open the form in the client, it appears to use the version in the list; if I force the form to render in the browser, it uses the new version that was uploaded to the farm. If I upload the new version directly to this Form Templates list, then the InfoPath client gets the new version.

Could be a local caching issue?

I thought that might be a possibility so I scanned my hard drive for *.xsn files and didn't find anything that appeared to match. Is there a common place where InfoPath form templates would be cached locally?

On the other hand, if it *is* a local caching issue, then loading the new version directly to the Form Templates list probably wouldn't have caused the new form to be loaded, but it did.

Another reason I don't think it's a local cache problem is that when I have had a different version cached on my machine in the past, InfoPath pops up a "Form Template Conflict" dialog asking me to tell it which one to use. I just got this message for a different form, by the way, and I searched my hard drive for the xsn file, but couldn't find it. I have no idea where the client caches local copies of form templates or how to view the list of cached form templates.

Since you are loading from a browser, I would recommend clearing out the browser cache. You can also clear out the InfoPath form template cache, by launching IP and removing the forms from the Fill Out A Form dialog box.

Beyond that, this is outside my scope... someone else will need to jump in to assist.

Okay, I tried both suggestions and there is no difference. IFS still sends the version updated at the farm level to the browser, and the version that was previously loaded to the Form Templates list to the InfoPath client. Strange.

Perhaps it is the farm that is caching these things? I'm out of ideas here--so just wild guessing at this point. If you can get the updated form one way, but not another, then there's something that needs fixing about that other way (obviously).