Random Thunks

Stupid, stupid, stupid.

You can either apply that to me thinking that attaching a file to my InfoPath task form would be easy or MS for allowing such a nasty insidious bug to crawl out into production.

Here’s the issue. I have an InfoPath task form running under MOSS Enterprise forms services. Upon this form I have a couple of file attachment controls. One would thunk that given that file attachment controls seem to have been a part of HTML since the mid 1990′s (RFC 1867) that this should be a totally elementary operation.

Heh, think again.

I found this out the hard way when, after browsing to my file and pressing the Upload button I was met with a rather curt ‘The Selected File was not found’ error message. A hunt around the blogsphere bore only one low dangling fruit : A WorkFlow that Uploads a Document via a Task using an InfoPath Form. which I gave a try but to no avail.

Turns out the author was 99.9998% there – except for the the direction of one slash! So, rather than regurgitate the entire post, here’s the correct JavaScript segment you need:

<script type=”text/javascript”>
     aspnetForm.encoding = “multipart/form-data”;
</script>

However, when all’s said and done I have to ask the question, why? Why do we have to slice up the WkTaskIP.aspx page to add this functionality in? I guess tomorrow I’ll be one the ole Dog n’ Bone to MS PSS to pursue this one further.

So, for anyone else out there with this issue, here’s a string for the search engines to chow down on to help any wayward travelers like myself get to the answer they need (at least for now!): InfoPath Forms Services File Attachment The selected file was not found

C’mon MS – We know it’s the year 2007 because we’re smart. You know it’s the year 2007 because you released this next version of IP and called it InfoPath 2007. So what’s the excuse for the horrific simplicity and mid-90′s ‘features’ that are browser based forms within IP 2007? Like for example the horrendously simplistic table layout control.

I mention this after I read the following support posting: How to resize the controls on a Microsoft Office InfoPath form based on the width of the form which states that in order to allow a table to grow and shrink with the page you pretty much have to remove any chance of editing the table layout via InfoPath unless you remove said functionality – both require you to edit the underlying views XSL.

Whisky Tango Foxtrot? And God-forbid we should be able to use something like style sheets to format the form – that would be far too 21st century!

I understand that IP’s heritage is client based but in this day and age of MOSS I wonder just how many forms are being produced that target the client? So far all of ours have been form based. This being the potential case just when are MS going to wake up, smell the coffee and make IP a far more functional web based forms editor?

Yeah yeah yeah – I know that you can always drop to using webparts or full ASPX pages for this stuff but why should you? IP is a pretty rich tool for forms filling – so why should we be expected the reinvent the wheel when all we want is to fill in forms?

Hot on the heels on the March CTP, comes the next installment of SQL Server 2008, available here (180 day time limited trial). Don’t go round expecting an easy installation on a machine with 2005 installed – there are several gotcha’s out there (as detailed in the accompanying ReadMe). In addition you can forget about a side-by-side installation with 2000 – that’s right out (but who runs 2000 these days anyway? It’s so 2005!)

Unlike with SQL Server 2005, Katmai is not a mammoth change – in fact one could could argue it’s more like SQL Server 2005 R2. Among some of the new features within the engine are

• five new dynamic management views detailing memory usage,
• the ability to merge data into an existing table using an enhanced INSERT and new MERGE statements,
• a new TABLE based data type that can be used to pass rows of data into stored procedures,
• ‘Group Policy for SQL Server’ aka Declarative Policy which gives you the ability to set policies for multiple servers from one location and
• My favorite of favorites (in this post Sarbanes-Oxley world) “Change Data Capture” which is best shown using the following picture from the BOL:

Where was this feature way back on 2004 when we first had to pacify the auditors that we had auditing controls on SARBOX covered applications?

It bugs me when the very ‘supposed’ leaders on MS product ‘code consistency’ don’t follow their own rules. Case in point: MOSS Task Activity events.

For example, the OnTaskChanged event has the following signature: (object sender, ExternalDataEventArgs e)

However the sender is always null. In order to get at the task that raised the event one needs to get at ((SPTaskServiceEventArgs)e).taskId.

Here therefore, are some others I’ve found to help my fellow ‘flow’ers to hook up multiple events to the same handlers (although I’m hoping that SP1 might ‘correct’ the lack of sender consistency):

OnTaskCreated

(object) sender or ((Microsoft.SharePoint.WorkflowActions.CreateTask)sender).ListItemId

Notes:

1. To get the name of the task that raised the event use sender.ToString().Substring(0, sender.ToString().IndexOf(” “)).

2. You’ll need to populate ListItemId in the designer – due to the nature of when this event is raised, there is no real useful info available prior to the call.

OnTaskChanged

(ExternalDataEventArgs) e

Notes:

1. To get at the tasks underlying GUID use ((SPTaskServiceEventArgs)e).taskId.

2. (object) sender is always null

OnTaskCompleted

(object) sender

Notes:

1. The tasks GUID can be located with ((Microsoft.SharePoint.WorkflowActions.CompleteTask)sender).TaskId.

2. The tasks name can be isolated with sender.ToString().Substring(0, sender.ToString().IndexOf(” “))

IfElse

(object) sender

Notes:

The name of the IfElse activity that raised the event can be found using sender.ToString().Substring(0, sender.ToString().IndexOf(” “)).