Last night after attending the SharePoint User Group meeting in NYC Jason Medero, Randi Parrish and I went to SHIMIZU for dinner. This has to be one of my most favorite sushi places in NYC but that’s another post. Once I got back to the hotel after dinner I trolled the net for new information on SharePoint and InfoPath like I do every night and I was quite surprised that Microsoft InfoPath blog was active again and currently has a great series on “Designing browser-enabled forms for performance in InfoPath Forms Services”. It was a nice surprise for me because next week I’m starting a brand new project and its going to be very heavy in InfoPath 2007/InfoPath Form Services and workflow and have some new material to read is nice. Below is a list of all the links to the series at this point.

http://blogs.msdn.com/infopath/archive/2008/05/09/designing-browser-enabled-forms-for-performance-in-infopath-forms-services.aspx

http://blogs.msdn.com/infopath/archive/2008/06/19/designing-browser-enabled-forms-for-performance-in-infopath-forms-services-part-2.aspx

http://blogs.msdn.com/infopath/archive/2008/06/24/designing-browser-enabled-forms-for-performance-in-infopath-forms-services-part-3.aspx

http://blogs.msdn.com/infopath/archive/2008/06/25/designing-browser-enabled-forms-for-performance-in-infopath-forms-services-part-4.aspx

http://blogs.msdn.com/infopath/archive/2008/06/26/designing-browser-enabled-forms-for-performance-in-infopath-forms-services-part-5.aspx

http://blogs.msdn.com/infopath/archive/2008/06/30/designing-browser-enabled-forms-for-performance-in-infopath-forms-services-part-6.aspx

Cheers,
Michael

The SUGDC Regional SharePoint Conference was this weekend (Friday and Saturday) and to my understanding from talking to people that attended both days it was a great SharePoint conference.  I didn’t get to attend both days but just Saturday when I was speaking but I had a great time on Saturday hanging out with Paul Galvin, Becky Isserman and Bob Fox during the afternoon.  This conference was a little different for me because it was the first event I ever spoke at that people actually paid money to attend.  I’m really curious what people thought and I’m hoping that I’ll get some evaluations from the people that attended my session.  I really want feedback from people good or bad so I can approve on things.  When attending some of the sessions with Paul and Becky one thing that I noticed was that I really need to spend a lot more time on getting my slides to look a lot nicer and probably slow down a little when I speaking.  One of the things that I keep catching myself doing is speeding through my sessions trying to get as much content in a session as possible instead of maybe spending little extra explaining things.  One of the things that I really enjoyed besides speaking on InfoPath was having the extra time talking with Paul and Becky and a few other people at the conference.  It is really nice to sit down and speak with people that do the same thing you do and listen to what they are saying and pickup new ideals and making new contacts.  It's too bad that I didn't have the chance to come on Friday so I could see Paul's session because I really think he has done a lot of cool things and I think it would have been a great session.

When preparing my presentation I did a lot of research qualifying everything I would be presenting and I was really impressed with all the detail information on the MSDN site.  I found so much information in the MOSS and WSS SDKs that I was really impressed.  I remember doing SharePoint 2003 it took forever for any good stuff to appear but that’s not the case for MOSS and WSS v3.  Anybody trying to learn SharePoint shouldn’t have any problem doing so anymore.

During the Roundtable session that Becky and I were doing on Ajax and InfoPath Paul asked some really good questions and I will be blogging about them over the coming days because I've had a little time to think about them and do some research.  I truly still can't believe how big InfoPath 2007 and InfoPath Form Services really is.

The conference was a blast and I would like to thank Bob Fox, Gary Blatt and Gary Vaughn for giving me a chance to talk at the conference and I hope they let me come back in the fall.

Cheers,
Michael

This is a really old post that never made it because I just totally forgot about it until I read Paul Galvin's post http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!609.entry and I thought it was still worth posting because it's such a common problem and most people don't know that it happens.

So here it goes;

The last few weeks I have learned so many things when working with Josh Medero (Jason Medero brother).  Josh has been helping me out with my InfoPath 2007/InfoPath Forms Services project and he has accidently done a couple of things that I've never done or seen before but that's totally cool because it has helped me learn new things about InfoPath 2007 and InfoPath Forms Services.  As you probably already know this post is about another thing that I learned today.

If you're a developer and have ever worked with InfoPath 2007 forms then you've probably have added a button to the form and have accidentally clicked the "Edit Form Code" button and launched Microsoft Visual Studio Tools for Applications (VSTA) and then closed it because you meant to click the "Rules" button.

When the VSTA window was closed I would have never have thought it would actually create anything and especially if nothing was saved.  For Josh it created an assembly for the form even though no code was added.  He never knew that an assembly was added to the form and I would have never known it but he was having other issues with his form and he sent it to me to open and preview. When I went to preview the form I got the following warning.

The reason that I got the warning was because I don't install VSTA on my laptop but VSTO instead.  After I say the warning message it started to get me wandering what was wrong.  First thing that I did was close InfoPath 2007 and then explored the XSN file and noticed it had a dll in it.  After I noticed this I opened the form backup and went into "Tools" -> "Form Options" and clicked "Programming" category.

The "Programming" category page shows that something was created and once I saw this I just clicked the "Remove Code" button to remove the unwanted assembly.  When I clicked the button the following pop-up came up and I clicked the "Yes" button to remove the code.

After I did these steps I no longer got the warning message when opening the form and Josh problems no longer existed either.  If you really don't plan to do coding in InfoPath with VSTA then I would suggest not to install VSTA that way this problem doesn't occur accidently.

Cheers

That's right it's time for the South Florida Code Camp and I'll be down there giving a new session on InfoPath 2007 and Visual Studio 2008.  For this session I'm thinking about changing a couple of things around and doing some really new stuff that includes C# code for updating AD and XMLFormView control for displaying an InfoPath 2007 form.  I'm thinking that the InfoPath 2007 form will be a data entry form that allows users to update their AD information.  I've been thinking about this new presentation for a while and since Visual Studio 2008 was officially released I figured that I should also change up the InfoPath part.  I'm really excited about building the new code and presenting it and after the code camp is over I'll post it on my Code Camp and User Group page.

All the information about the South Florida Code Camp can be found on the http://codecamp08.fladotnet.com/ website.  From what I heard while at Philly Code Camp from other speakers this code camp is suppose to be as big as or bigger than the Philly Code Camp one.  To see what sessions are currently on tap checkout the agenda page http://codecamp08.fladotnet.com/agenda.aspx.  The code camp is going to have 12 different tracks and that means tons of sessions.  The "SharePoint/ Office" track already has my "InfoPath 2007 and Visual Studio 2008" session and "Utilizing Visual Studio 2008 capabilities for better SharePoint Development Part 1 and Part 2" sessions on tap.  In my opinion this track is already shaping up to be a killer track.

I'm really excited about this code camp and I'm glad to have the chance to speak at it and I hope to meet some new SharePoint colleagues there to.  Well I'm about all posted out for the night.  Hope to see some of you there.

Cheers

In the post Using InfoPath 2007 Translate function to do what XPath lower-case function does I talked about how to use the “translate” function in a XPath expression box and today I just wanted to continue down the path of using XPath expression box and XPath to compare two values in a Condition statement. In a normal circumstance this would be a very easy thing to do because you would just go select the two fields you want to compare and boom you’re done but what if the two field values are not always the same case. Then what do you do? How do you make everything the same case for both fields? This is a situation that I ran into not long ago and below is how I went about solving the problem.

Whenever building a condition statement you only have the options of choosing an existing Field, Group or “The expression” for the first dropdown list and in normal circumstances this would be fine. In normal circumstances if I wanted to compare two values and they were not fields already in the data source and they would not be visible fields then I would create a new Group called “HiddenFields” and then add the fields to that group and populate them in an opening rule. An example of the condition statement that I’m talking about is below.

This works great if all you want to do is a simple comparison and the field values will always be the same text case. As I stated above what if you run across a situation when the text case is going to be different in each field but you still want to compare. You might be thinking that you can use the "Use a Formula" option for each field but unfortunately the "Use a Formula" option is only available for the third dropdown. Below you can see what options are available for each dropdown.

After looking at the pictures you might have noticed you don't have all the selections available in the first dropdown list that you have in the third one. You're probably thinking that this is going to be very difficult to accomplish but in all actuality it's pretty simple if you use the "The expression" option.

When using the "The expression" option there are a couple of things that you can do to make your life a lot easier when building the XPath statement. If you first build the formula for the third dropdown list before changing the first dropdown list to "The expression" then it will copy everything you did into the XPath statement. I usually set the second and third dropdown list values before switching to "The expression" option in the first dropdown list. If you do it this way then you should get something like the below image when you switch.

The formula should look like this.

. = translate(my:HiddenFields/my:Field2, "ABCDEFGHIJKLMNOPQRSTUVWYXZ", "abcdefghijklmnopqrstuvwyxz")

The formula is now 2/3 the way done and now all we have to do is build and add the formula for the first field. The easiest way to do it for this example since the fields are in the same "Group" is to copy the current formula and replace the "." with it and then change the "my:Field2" text to "my:Field1". You might be saying that field box is too small and you wish you had more room to view the formula. If that's the case then open "Notepad" and do all you're editing in there and then paste it back into the field when you're done. At the end the condition box should look like the image below.

The formula should look like this.

translate(my:HiddenFields/my:Field1, "ABCDEFGHIJKLMNOPQRSTUVWYXZ", "abcdefghijklmnopqrstuvwyxz") = translate(my:HiddenFields/my:Field2, "ABCDEFGHIJKLMNOPQRSTUVWYXZ", "abcdefghijklmnopqrstuvwyxz")

Having the flexibility to add a formula to your fields when you compare them should open your world to a lot of new options.  Well it's time for me to get back to work and start preparing for my next gig that starts next week.  I'm pretty excited about this one because it sounds like I'll be doing a lot of cool SharePoint development work.

Cheers

On Saturday when I was adding my finishing touches to my demo for the Philly Code Camp I ran into an error with Visual Studio 2008 VSTO and InfoPath 2007. Whenever I tried to run my InfoPath 2007 form in debug mode I got the following error.

"Microsoft Office InfoPath does not recognize some or all of the command line options. Exit and restart Microsoft Office InfoPath with the correct command line options"

When I discovered this error and found out that it happened with a brand new project my heart started to beat a little faster (ok lot faster) because I knew the pressure was on to fix the problem before my session started. I started to do searches on the internet and I couldn't find any answers and then I did one final search and I found some link that talked about a similar error with Visual Studio 2008 Beta 2 and another office application. It mentioned about updating Office 2007 with a patch to fix the error. After reading that I looked at the version I was running and notice that I wasn't running SP1 for Office 2007 and decided to install that and see if it would fix the error. Luckily I had internet access at the code camp and started the download and about 30 minutes later I got it downloaded and installed. Then I crossed all my fingers and toes and tried the debug mode again and it worked. By installing SP1 for Office 2007 fixed the problem. I'm sure there will be many more little things pop-up and if I run into them I'll be sure to post them.

By the way Philly code camp rocked the house and I'm glad that I got a chance to speak.

Several days ago Joe and I found ourselves wanting to make sure we made the InfoPath “UserName()” function return all lower case characters and we decided to use the common XPath function “lower-case” but was surprised because it didn’t work. With a little research I found that we could use the InfoPath “Translate” function instead. I must say that it’s a little frustrating that some common XPath functions don’t work and you have to find the work around but if you do any InfoPath development you come accustom to it. Below is what we tried that didn’t work and what we did that did work.

What didn’t work: lower-case(xdUser:get-UserName())

What did work: translate(xdUser:get-UserName(), “ABCDEFGHIJKLMNOPQRSTUVWYXZ”, “abcdefghijklmnopqrstuvwyxz”)

Basically for “Translate” we had to specify every letter in the alphabet in UPPERCASE and then lowercase to make sure every character will get translated. For more information on “Translate” checkout this link http://office.microsoft.com/en-us/infopath/HA012330391033.aspx and do a search for “Translate” for the official description (It’s towards the bottom of the page).

If you foresee yourself using this more often then something to consider is creating a “Template Part” for this. It would be very simple because it would have two fields one called “translate_uppercase” and another “translate_lowercase” and each field default value would be the alphabet in the correct case. Then whenever you would want to use the “Translate” function you would add the “Translate Lower Case Template Part” to the form and build the expression as translate(fieldname, translate_uppercase, translate_lowercase). This would be a lot simpler than typing in all those letters and if you have more than one person doing InfoPath development it would create a standard way of doing it.

Cheers

Thursday was another good day because there were several things that reminded me of things that I already knew but hadn't blogged about.  Anybody that works with InfoPath knows or should know that InfoPath is tightly integrated with IE and the below details is one example of this.

In the last post I mentioned that I was working with a new guy that will be taking over my work and whenever he opened a form in "Design Mode" his form text looked so much larger than mine and at times his text would wrap and mine wouldn't.  This morning it bothered me enough that we looked at what the problem was and we discovered that it was "Text Size" IE setting.  Below images of the same form but if you look really close you will notice that the labels are different sizes.  This is caused by the "Text Size" menu option being set at different levels.

When we changed the "Text Size" menu option to be the same as mine then the forms looked identically the same.  To change the text size in IE 7 click Page menu button next to Tools and then navigate down to Text Size and below is a screen shot of the Text Size menu option.  The second image is another example of getting to the same menu option and is pretty close on how to do it with IE 6. 

This situation will most likely stay with me for a while because it will be something that I will want to tell future clients to watch out for because it could truly be an issue help desks would need to watch out for.

Cheers

This week I started cross training a client employee on what I’ve been doing for the past 5 months because I’m leaving the project soon and start to look for a new project. Yesterday during our first session we discussed InfoPath Template Parts and how to build them and use them with existing InfoPath Forms. One thing that was brought to my attention again was how it interacts with an InfoPath Form when an existing control is being updated. When I discovered this the first time I forgot to blog about it but this time I didn’t want to pass up the opportunity because I think it’s pretty important to understand if you are going to use InfoPath Template Parts.

When building a new InfoPath Template Part you define the data source and then design the template part or you design the template part and let that define your data source. Once done you save it and then add it to the InfoPath designer when a form is being designed. At that point you then add it to the form and it magically appears and the new fields are added to the data source. All that is the straight forward stuff but now things start to get a little more complicated when you go back and modify the template part. If you go back to the template part and make a visual change (meaning not adding a new control that updates the data source) and save the changes and add it back into the InfoPath designer and update the existing control on the form everything works just fine. Now if you were to update the same template part but add a new control/field and save the changes and add it back into the InfoPath designer and update the existing control on the form everything appears to work just the same but it actually does one extra thing, it appends all the fields to the main data source again with the new one.  Logically you would think it would just update the existing structure with the new field but it doesn't.  If you’re not paying attention this could cause some major problems if things are not cleaned up. To clean things up just delete the original fields and then move the new fields to the location of the original fields and rename the new fields to the names of the original fields (sorry that’s so confusing).  It's pretty easy to do because InfoPath should have only added "_1" to the end of the new fields or the next number available.  If you don’t do the clean up then any existing data will still reference the original fields and won’t show up on the form because the form now points to the newly appended fields. This is sort of messy but I’m sure it’s done this way to preserve the original structure just in case it’s needed. That’s the only logical reason that I can think off at this point.

After writing this I sort of think the reason for not doing it before is because it’s so confusing to understand the situation without physically seeing it. With that being said I’m thinking about buying some capture software to create a video of what I’m talking about and hope this will give more clarification of what I’m talking about.

Cheers

Since I’m waiting on my plan again to Raleigh from Newark, I wanted to share the following little example.

Just recently we had a new form that needed to be built and it had a small unique design situation. The form had an area that needed the ability to have multiple rows and a single total field. The repeating row had a large dropdown list and 6 more fields to be scrunched onto a single line and to be honest there wasn’t a way to do this gracefully with a repeating table. The designer and I had a quick IM/phone conversation about it and we decided to do it as a repeating table but also a repeating section and then we were going to have the client choose the one they wanted. Naturally she worked her magic and came up with the following examples. The “Reason” field will be the one turning into a dropdown list. The items for this field are going to have the length of 25 characters (just trying to draw a mental picture for you guys).

Repeating Table:


Repeating Section:

When the designer showed me the forms I couldn’t believe my eyes how much cleaner the repeating section was. I knew the client was going to love the repeating section and I was right. Big kudos to my designer for creating another great form and I’m sure there will be many more to come.

For this form we were totaling the “Amount of Deduction” field and were having the total appear in the “Total Amount of Write-Off” control. The “Total Amount of Write-Off” is an Expression Box control and not a regular field. The Expression Box control used “sum(fieldname)” formula. We use the Expression Box control because it’s a simple thing to setup and we don’t have to worry about storing the total value.

Hope everyone has a great weekend and comments are always welcome.