The Edge [of all] Journeys

“i planted the gun in the dirt”

[intrigued father]:

“oh? is it going to grow into a gun tree?”

[the Z who has it all figured out]:

“when we water it – it will.”

8 weeks and counting…

Only a short time left before we hit the road! We are selling stuff, donating stuff, throwing away stuff. Makes me realize how much stuff I really have. Makes me wonder why I have so much stuff anyway. I’m looking forward to living in a smaller space. There will be a lot less to clean. Less space to accumulate stuff. I’m trying to organize and simplify, but for some reason, this means buying more. I need new bins and new containers and drawers and folders to keep everything in it’s place. I am buying more stuff as I’m trying to get rid of stuff. It’s getting very complicated to live simply. It would be easier to throw everything out and start over completely. Hmmmmm…. that’s an idea.

[reaching for pretend popcorn]:

“i’m watching a show. it’s a long one. first there’s Curious George, and then there’s George Washington…”

[wise and understanding father]:

“Oh, George Washington? What’s that about?”

[matter of factly]:

“robots.”

“atchaforcanu!”

[translation finally achieved through the tireless efforts of several frustrated linguists]:

“watch how far i can yell!”

[migrated from http://edgedev.blogspot.com]:

It seemed simple enough at first. All I wanted was a way to dynamically pull data from Lists and Document Libaries into InfoPath. Oh, but did I forget to mentioned that I also wanted the data filtered BEFORE it hit InfoPath because the Lists and Libraries might be massive (go figure). Trying several things, it became obvious that I needed a faster/better/easier method than any of the following:

1. Using a baked-in InfoPath data connection to a List is easy, but it retrieves ALL List items and leaves filtering to the controls. This is obviously a horrible method when working with large data sets.
2. Using custom code-behind on the InfoPath form to query SharePoint via the object model is perhaps the cleanest method, but adds code-bloat, is not very modular, and requires extra maintenance.
3. Using a web service data connection from InfoPath to SharePoint web services (like http://[site]/_vti_bin/lists.asmx?op=GetListItem) would be perfect, except that InfoPath does not form the xml in the SOAP request correctly (i.e. the way that SharePoint is expecting) and returns an error. Actually, this boggles my mind. Somebody please correct me if I’m wrong here and/or if there is a clever workaround that I couldn’t find / figure out. This seems like an incredible oversight on Microsoft’s part for 2 products that are supposedly designed to play nice together.
4. Since I’m in a K2 blackpearl environment, I also thought about using a SmartObject, which rivals option #2 for cleanest method, but it also adds an additional maintenance tail outside of InfoPath and requires additional wiring inside the form.

Looking for a solution, I stumbled on this article – http://blogs.msdn.com/infopath/archive/2007/01/15/populating-form-data-from-sharepoint-list-views.aspx – at the InfoPath Team blog which formed the basis for a new idea:

To summarize – if you don’t want to have to read through the whole article yourself: This little known feature allows you to pass GUIDs for Lists and Views, along with filter parameters, in the URL querystring to owssvr.dll and dynamically retrieve an XML “results” file. Furthermore, the URL itself can be used as the file location for an “XML Document” data connection in InfoPath.

The main hurdle is that, once the data connection is created, it doesn’t seem on the surface like there’s a way to dynamically update this file location to retrieve a different XML Results Document from a List or Library based on related fields in a form that has been opened. Well, it turns out that the InfoPath object model exposes this property and lets us manually execute the query.

In my particular scenario I wanted to retrieve a group of documents (metadata) from a massive Document Library where a DocumentColumn matched a particular FieldValue in the form opened. Here’s what I did:

1. [Optional] Create a View of the List or Doc Lib that contains the specific fields you want retrieved into the Form
2. In the Form, add a new Receive > XML Document data connection
3. For the “location of the XML data file…” in the wizard use:
   http://[server]/[site]/[list]/_vti_bin/owssvr.dll?Cmd=Display&List={LIST_GUID}&XMLDATA=TRUE
4. [Optional] Include &View={VIEW_GUID} if you want to pull data and columns from a specific view that already exists or was created in step 1.
5. Note: the GUIDs in the querystring parameters can be in either format:
   a. “{xxxxx-xxxxx-xxxx-…}”
   b. “%7BF498875E%2D5A645B%2D…” (as copied directly from SharePoint generated URLs)
6. Complete the data connection wizard – this will add the unfiltered data connection results schema to the Form (you do want the unfiltered schema). Make sure the following settings are set as you complete the wizard:
   a. “Access the data from the specified location”
   b. [UNcheck] “Automatically retrieve data when form is opened”
7. To add the repeating table that will hold the query results, find the xml/rs:data/z:row repeating group in the new data connection and drag it onto the form
8. To complete the solution, a little code-behind is necessary (but it’s minimal and a LOT less code than method #2 mentioned at the top). There are probably several ways to do this (like wiring the code to a button or another event), but here’s my basic approach:
9. Since the ID will already be stored in the form data by the time the user opens it (in the context of a K2 workflow), I use the form’s Loading event to modify the connection URL and execute the connection.
   a. In InfoPath Designer: Tools > Programming > Loading Event
   b. In Visual Studio Tools for Office: Insert > Loading Event
10. The following code will append – at run time – the filter parameter and value from a field in the form to the XML Data Connection location URL and execute the data connection to retrieve the hits:

// we need to instantiate a typed data connection object
// to modify the query and execute the results
FileQueryConnection dc = (FileQueryConnection)(this.DataConnections
[“NameOfXmlDataConnectionCreatedThroughWizard”]);
// next, we append the filtering values from the form field(s)
// to the existing URL already stored in the data connection
// –see notes for description of readNode()
dc.FileLocation += “&FilterField1=DocumentColumnName&FilterValue1=” +
readNode(“/my:myFields/my:FieldInForm”);
//finally, we execute the data connection to return the results
dc.Execute();

Notes:

• readNode is a little helper function I add to all my InfoPath forms so that I can quickly retrieve the value of a node without having to jump through navigator objects every time I want to get something. It looks like this:
  public string readNode(string xpath)
  {
  return MainDataSource.CreateNavigator().SelectSingleNode(xpath,
  NamespaceManager).InnerXml.ToString();
  }
• I think the SharePoint URL trick supports multiple FilterFieldX and FilterValueX parameters, so in theory, you could build pretty sufficient queries using the querystring alone. For example:
  “&FilterField1=ColumnName1&FilterValue1=Value1&FilterField2=ColumnName2&FilterValue2=Value2”
  This trick might also be leveraged throughout other events in K2 workflows since it returns standard XML and the query results are stored in /xml/rs:data/z:row.

Use this knowledge wisely. And have fun.

“here, dad, i made this robot for YOU……… but it’s for ME……..”

[mother dresses him in a shirt with big shiny buttons]

“i’m a robot!”

[migrated from http://edgedev.blogspot.com]:

This one really had me wrapped around the axle for a bit, and ye ol’ trusty google let me down. Not a single applicable hit when I searched on [“form definition” “for dataObject”] so when I figured it out quite by accident I thought I’d contribute to the googlesphere and maybe help someone else out who might run into this. If anyone does. Ever. Ok, maybe no one else will ever have this happen to them, but it happened to me I promise.

I thought I’d go and customize the Document Information Panel for a Content Type – totally harmless right? Well, InfoPath didn’t seem to think so. And when I tried to attach to the Content Type’s schema as the basis for a new form (or when I tried to customize it straight from the link in the Content Type settings) i got this:

Removing both Site Columns from the Content Type and trying again, I was able to launch the schema for the form. Grrr… Hmmm…

So, was there anything weird about those columns? Well, they were look-up columns on a list with the multi-select and unlimited length in documents options checked. But what if I added them back to the content type and tried again?

Adding the first one back and trying again it worked! Alright. Adding the second one … NOPE! Crash and burn. What gives? Well, this must obviously be another stupid Microsoft bug. Incidentally, both look-up columns are based on the same column of the same list. I have a “From” and a “To” column that point to the “Display Name” column a master Names List. But I won’t be able to do both and still customize the Doc Info Panel. Bummer. Unless I can come up with some sort of work around (unlikely). But I’ll update this if I do.

[a few hours later]

Alrighty then. The enemy can be tricked. If you HAVE to be able to do this (like I do) here’s what you do:

1. change one of the site Columns to point at a different look-up list column than the other one
2. this will let you open the doc info panel successfully even with both site columns pointing at the same look-up list (albeit at 2 different columns within that list)
3. in the field properties in infopath, open up the control populated from this look-up list column and change it back to the column you want to pull in
4. in the Site Column change it back to point at the the right look-up column as well.

Voila! Happy ending. If I hadn’t wasted hours on something that should work anyway.