Fixing Visual Studio 2012 defaults

Written by Cornelius J. van Dyk on . Posted in Annoyances, How Do I...

One of the biggest pet peeves I experienced when switching to Visual Studio 2012 was the fact that the default command buttons were changed.  In going for a cleaner look, many of the main command buttons most developers use most frequently, was removed from the toolbar interface and buried in the menu structure instead.

Personally, the buttons I find myself using most frequently are the Navigate Backwards and Navigate Forwards (image ), Comment Selected Lines and Uncomment Selected Lines (image ) and lastly Increase Line Indent and Decrease Line Indent (image ).

The Navigate functions are still there, but the Comment and Indent functions are buried deep within the Edit/Advanced menu.  While it’s true that the Comment functions do have hot keys attached to them, I hardly consider Ctrl+K,Ctrl+C for a single click to be useful to most developers save the few that know the hotkeys by heart.

As for the Indent commands, they don’t have any hotkeys and you’d have to click through Edit/Advanced/Indent to get the action.  Though small annoyances, these can be addressed by simply adding the commands back to the command bar.  Here’s how to do just that:

  1. Click Tools on the menu bar.
  2. image  
  3. On the popup menu, click “Customize”.
  4. After the Customize dialog window opens, click over to the “Commands” tab.
  5. Select the “Toolbar” radio button.
  6. In the dropdown to the right of the Toolbar radio button, select the “Standard” toolbar to work with.
  7. The toolbar’s controls will be previewed in the bottom left of the dialog window.
  8. To the right of the preview, click the “Add Command” button.
  9. image  
  10. In the Add Command dialog window that opens up, select the “Edit” category to the left.
  11. On the right, scroll down through the commands and locate the “Line Indent” command.
  12. Select the command and click the “OK” button.
  13. image
  14. The command will be added to the top of the Controls preview.
  15. image  
  16. Repeat steps 8 through 12 for the “Line Unindent”, “Selection Comment” and “Selection Uncomment” commands as well.  The interface doesn’t allow multi-select, though that would be nice touch in a future update.
  17. Once you have all the commands, use the “Move Up” and “Move Down” buttons to the right to arrange the commands in the order you wish them to appear on the toolbar.
  18. image  
  19. When you’re happy with the arrangement, click the “Close” button.  Your new toolbar should now reflect your favorite buttons again. 🙂
  20. image



InfoPath AND OR logic with boolean types and bit values in C based languages – Why your checkboxes are not working as expected

Written by Cornelius J. van Dyk on . Posted in Annoyances

OK, that’s a massive title for this blog post. 🙂 Nevertheless, if you’re having trouble with your InfoPath check boxes not having the desired effect in rules, then read on.

To simplify this explanation, I’m going to use a simple form with two check boxes and a button. The form looks like this:


As you can see, it’s a pretty simple form. The two check boxes simply bind to two fields and our data structure looks like this:


When we right click on each of the check boxes thus:


and then click “Check Box Properties” on the popup menu, we’d see the properties as expected thus:


As expected, the default state of the check box is “Cleared” and the value corresponding to that state is “FALSE”. The inverse is true of the Checked state having the value TRUE. This is all as it should be thus far.

Now let’s suppose that we want to hid the Button if either of the two check boxes are unchecked i.e. set to FALSE. We do this via the Rules on the Button control. If we look at the rule defined in this case, we see it looks like this:



As we can see, the rule is pretty simple and straight forward. Given that both check box controls have a default value of Cleared i.e. FALSE, we would expect the form, when loaded, to hide the button, correct?

This is unfortunately, not the case however, as you can see from here:


Check checking the first box, the button is still there:


When we uncheck the first box, the button disappears, as we expect it to.


Rechecking the box, shows the button again, even though it shouldn’t since the second box is unchecked. The same behavior is found when dealing with the second check box.

So what could possibly be the problem here?

The issue here is the way in which InfoPath deals with the Boolean data type. Keep in mind that InfoPath was developed with C# and C++. All C based derivative languages share the same common handling for null values. In C based languages, a boolean value is defined thus:

bool myValue;

The thing to note is that a boolean value is represented by a single bit in the data stream which is either turned off i.e. false or turned on i.e. true. In C based languages however, the declaration of a variable such as the above, does NOT assign any value to the variable and the value is considered to be unknown or NULL until assigned.

We can debate the merits of null values all day long, but the short of it is that a boolean value could actually have 3 values per se.

We have already looked at our Check Box control in detail and we have found that it can either have a Checked or Cleared value representing TRUE or FALSE. The control itself does not have any way to represent a null value, but we must remember that the control is almost certainly bound to a data value somewhere. The data value is a distinctly different object value that is synched with the value of the check box. As such, it’s governed by a separate set of rules so let’s take a look at the data field properties.

When we locate field1 and right click it, and click “Properties” on the popup menu we see this:


The fact that the Default Value property of the data field allows a value of “(Blank)” to be assigned means that the data field can represent null values. This is where state comes into play. If we consider the fact that the check box control can only have TRUE or FALSE values (Checked or Cleared), and we keep in mind that the data field value is synched with the control value, then what is happening here?

The answer lies in the timing of synchronization between the check box control and the data field. In order to preserve resources and cut down traffic, most controls are event driven. That means that the control doesn’t actually update it’s underlying data field value unless the value of the control itself changes. As such, when the form is first loaded, the check box has a value of Cleared i.e. FALSE while the data field does not have any value and as a result, InfoPath assigns the “(Blank)” or null value to the field. This results in a mismatch of state i.e. the data field value does not represent the visual value displayed in the check box.

Due to the fact that InfoPath rules operate on the underlying data field values rather than their bound control values, the formatting rule we had defined for the Button would be checking if the check boxes had a FALSE value. Since upon first load their value is in fact null rather than false, the rule fails the check and does not hid the button as we expected.

When the check box is checked, the TRUE value is synched with the data field and when it is unchecked, the FALSE value from the check box is synched back to the data field. That is why after checking and then unchecking the check box, the button is hidden as expected.

Though I believe allowing “(Blank)” to be a valid value for the data field is a design flaw, the reality is that it’s unlikely to change so we need to be aware of this kind of behavior when designing InfoPath forms.

Special thanks to Chuck for working through this logic with me until we were able to identify what was causing this odd behavior.



SPFarm.Local is null in SharePoint 2010 causing C# Console App to throw a “Object reference not set to an instance of an object” error

Written by Cornelius J. van Dyk on . Posted in Annoyances

This one is one of the more annoying errors you’ll encounter in SharePoint development. The simple reason for that is because the error you’re receiving is bogus. I mean, sure it’s a “valid” error since the SPFarm.Local is actually null and you’re trying to reference it, but it doesn’t actually lead you anywhere. As a SharePoint developer/admin/architect, you will often be faced with the need to iterate content in the farm. Every good SharePoint developer knows that it all starts with the simple statement: SPWebService svc = SPFarm.Local.Services.GetValue<SPWebService>(“”); This should NEVER fail, unless you don’t actually have a SharePoint farm on your DEV box, but naturally you do, right? 🙂 So then why would you ever see the below from your debugger window? image[18] The problem stems from the architectural nature of SharePoint. SharePoint as you know, has been purely x64 based since the 2010 version. Add to that the fact that most utilities we write in the C# world to pull information from SharePoint, are Console apps, and you have the ingredients for our problem which is caused by Windows attempting to run a x86 based app under a x64 based architecture. Now where this should normally work, it doesn’t in this case. The real problem is that no architectural error is thrown. The code simply returns null and does not work. It can lead to many frustrating hours of debugging. Since console apps are by their very nature x86 based, it’s very easy to make the mistake of compiling your console app to the x86 architecture. If we go to the project properties for this console app, we’d find the following: image_thumb[14] The “Platform target” is the setting we’re interested in. By default Visual Studio 2010 will set this value to x86 for console apps. It’s easy to forget to reset this value when quickly knocking out a console app. Here’s how this should be set: image[38] Once we make this simple change and press F5, we’ll be able to step past the problematic line of code and continue on our merry way. Hopefully this article will save someone some time and frustration.



Beware – MOSS migration of SPS Listings generates problematic Site Columns

Written by Cornelius J. van Dyk on . Posted in Annoyances

OK, so if there’s one thing that drives me insane, it’s when people complain and criticize something without having a solution at hand. I always believe that if you have objections or criticism to how something works, you should be ready to defend your position with suggestions on how to do it better. This is especially true in politics, but I apply it to my life in the software world as well. That is why I don’t generally as a rule blog about product oddities that I’ve discovered, UNLESS I also have a workaround ready to demonstrate in the same blog entry.

I’ve been working on our SPS to MOSS migration for quite some time now. We had quite a bit of pre-existing content though I wouldn’t describe it as anything more than medium size. Nonetheless, we did have some interesting obstacles to clear, such as our use of custom area definitions, which turned out to be unsupported per PSS. We had to work around that issue by reverting back to standard area definitions, a process which I documented in this KB.

I have today confirmed what appears to be a bug that could cause lots of frustration. It certainly has caused lots of frustration to us over the last couple of weeks as we worked to isolate and identify its cause. The problem originates with the use of “Listings” in SPS 2003. We used Listings everywhere because its automatic linking functionality made life easy for our content editors. We had run the “/” site collection, which represents the portal areas, through the migration process and started cleaning up, branding and customizing our portal. Despite our utter disappointment that Listings had been dropped as a content type, we worked to address the issue. It’s during this process that we were customizing Site Columns and Site Content Types. Our listings had used a property called “Group”. Group was defined as a Choice field with 3 values:

  • Overview
  • Highlight
  • Resources and Information

Anyway, after the migration, Group was defined by MOSS as a Custom Site Column that sourced from the Page type.

We then proceeded to add Group as an existing site column to the Article Page site content type under Page Layout Content Types.

You can see from this screen shot:/

That the Zip/Postal Code which is a pre-existing Site Column which we added to the Article Page content type as a column, shows up in our properties. So too does the CvDGroup which is a recreation of the choice column that Group represents, but the Group column simply does not show up. It does not function as expected in proliferating out through the site collection.

We confirmed that if you actually deleted the Article Page content type and then add it back as a content type, then the Group column will show up. This is obviously not a desirable situation as it would not be practical to remove the Article Page content type in each site in the portal and then add it back again. Besides, you can’t delete a content type unless all references to it has been removed and/or deleted. That would mean deleting all article pages on all sites, removing the Article Page content type from all sites, deleting the Article Page content type from the portal, adding the Article Page content type back to the portal, adding the Article Page content type back to each Pages library on each site within the portal and then finally recreating all article pages off this new type. Not practical…

So, what’s the warning then?

WARNING! Do not attempt to use migrated site columns anywhere with your content types.

WORKAROUND – Instead, simply recreate the migrated site column manually as a custom site column. It can be made identical and will function as expected without any side effects.

Not quite the ideal solution, but it will keep you out of hot water and save you hours of frustration. I’ll be filing a bug report for it and will post here if it is resolved/fixed.



Tired of not being able to save your WSS sites as templates because they exceed the maximum template size?

Written by Cornelius J. van Dyk on . Posted in Annoyances

Well, courtesy of my buddy Todd Klindt, here’s a little unknown STSADM command that you can use to change all that once and for all. The command you need is:

    STSADM –o setproperty –pn max-template-document-size –pv 524288000
The –pv value is the value, in Bytes, that you wish to set the limit to. The maximum value that can be set is 500 MB or 524288000 Bytes. Note: STSADM will crunch away at this command for a while so be patient and PLEASE do NOT terminate STSADM midstream!