Simple SharePoint List Item Validation Example

Sometimes SharePoint validation can be touchy. This is a simple example of ...

If you answer "Yes" then you must also complete this other field.

VPN is a choice field. VPN Justification is a single line of text.

The formula is:

=IF(VPN="Yes",LEN([VPN Justifiction])>2,TRUE)

and the User Message is:

VPN justification must be completed

Simple and effective.

Setting a Due Date

This formula worked real well as

• a calculated default value 
• on a date only field 
• to set the due date to today plus two 
• and accounting for weekends:

=Today+2+IF(OR(WEEKDAY(Today)=4,WEEKDAY(Today)=5,WEEKDAY(Today)=6),2,0)+IF(WEEKDAY(Today)=7,1,0)

SharePoint Double Encoding Space in URL to %2520 - An Easy Solution

I got bit by SharePoint double-encoding a %20 (space) in a list name when I tried to rename a customized display form used in that list.

Now, mind you, these are two things I always avoid - spaces in list names and customized forms. But I inherited these, and then I proceeded to muck it up with the rename. The result was that links on tasks that went back to the list were double encoded - the % in %20 becomes an incredibly insidious %25, which is just a horrible thing in a web browser.

Now you might want to try some simple workaround or fix, like a redirect or something, but touching that %25 is real hard. I found a great solution using jQuery to rewrite the URLs. I did not try this but it seemed like it would work.

I found that if I renamed the list without any characters to encode, the links were all fixed.

Next I wanted to put the list back to the original name. This turned out to be impossible. No matter how I did this, SharePoint was nice enough to double encode the thing and make it %2520.

So the answer is to permanently change the URL for the list to not have any encoded characters (spaces, etc.). If need be, you could do some sort of redirect for anything with the old name, but this is largely unnecessary as SharePoint really does a good job with fixing all the URLS (just as it broke some of them).

Opening Form in a Popup from a Link

I know I figured this out more than once (who knows, there may be another version on THIS blog somewhere). That, and there are multiple ways to do this. It should also be noted that sometimes this is a bad idea and won't work right, so think about how it might not work and test it!

Take yer link:

http://yadayada.com/qa/_layouts/listform.aspx?PageType=8&ListId={F06E16DD-3D2B-4022-8E76-495BAAED3DDC}&RootFolder=

and transform it into:

javascript:OpenPopUpPage('http://yadayada.com/qa/_layouts/listform.aspx?PageType=8&ListId={F06E16DD-3D2B-4022-8E76-495BAAED3DDC}&RootFolder=&IsDlg=1')

Bingo!

Rant: What kind of CSS could do this?

I have thousands of SharePoint 2007 sub sites that use some old custom branding, but I don't blame the custom branding for the crazy behavior I have been observing.

I am doing one last version of the site template before we redo the whole thing for SharePoint 2010. In creating the site template, I noticed that the site home pages (webpart pages) started showing the webpart titles with a different color after opening the document library by clicking the title. This is sort of normal browser behavior for visited links, but it doesn't do it all the time.

When I first create a site from my previous template the links do not change after you open from them. I tried this on my North America, Asia and Europe farms and they all did the same thing. I really don't have time to debug the CSS (and I don't want to mess with it) - but I have time to rant. We don't want them to change after visiting.

Anyway, I need to edit the home page. So I add a new webpart to the page, edit it in a couple wonderful SharePointy ways (other screwiness and fun), and .... VOILA the other links all start changing. Definitely one of the funnier WFT SharePoint things I've seen lately.

The iPhone and the Large Law Firm

Warning - this post contains some of my thoughts about iPhone use at a large law firm from my perspective of an iPhone user who works in a law firm IT department. I have no practical experience with any level of iPhone integration in a large law firm.

Unfortunately, when one talks about things that law firms are commonly doing, it frequently doesn't include the largest firms. What works for most law firms may not work for one of the biggest. Yet there are some things that are common to most decent-sized firms. In large law firm IT departments, iPhones are very common, though probably not as prevalent as the officially supported (and subsidized) Blackberry. I know there has been some work by vendors to provide the necessary hooks to do some cool things with iPhones in large enterprises. It was encouraging to see this http://www.apple.com/iphone/business/profiles/sonnenschein-nath-rosenthal/, especially since it included SharePoint integration.

To me it seems like Apple's http://manuals.info.apple.com/en_US/Enterprise_Deployment_Guide.pdf misses the mark. I'm not sure how all large enterprises work, but I think most of them have no interest in providing the kind of support this manual suggests. I think they would prefer to carefully allow access to things like email, SharePoint or a Citrix Desktop from employee owned phones rather than owning and babysitting the entire operation. Coordinating phones from different carriers all over the world is much better pushed back to the individual (at least organizationally).

Various strata of integration could strengthen iPhone support in larger, more secure enterprises. Of course it starts with email, Lotus Notes integration being of interest to me. Sybase iAnywhere, IBM's iNotes, Notes Pro and maybe a couple other apps provide Notes email to iPhones. Mail should always work fine in this form factor, you just need to make the necessary security hops. There are a few others vendors that do some Notes database replication as well, but I don't see that as a strong draw since Notes has been dying as an application platform. Secure access to SharePoint servers providing mobile-optimized web pages could be useful, and fairly easy to establish. Attending meetings through a mobile device is a natural. A Citrix desktop might also be OK, but have you ever tried operating a desktop on a little touch screen? It's not a very useful capability.

Having a resourceful, always connected computer in my pocket has been great, and I don't expect to ever again be without such service. Integrating this level of mobile functionality into large enterprise will take some time and effort and I look forward to it.

Customizing SharePoint RSS Web Part

I will be brief, because this is pretty simple and obvious. I have my favorite reader (Google on my iPhone) and the RSS web part sometimes seems crude, but it is sometimes very useful when a site really is crying for relevant news.

Don't be afraid to mess with the XSL Editor. Just copy the contents into Notepad - that's your backup. Now start hacking away. If something goes bad, paste back in your backup.

You want to remove the titles? Just snip out the whole node: div class="groupheader item medium."

So have at it!

SharePoint Fast Search Conceptual Speculation

Excuse me while I think out loud here (what else is new). As someone who truly likes the SharePoint platform, and as an IT professional who had an opinion about Fast (that it was aptly named, a pretty good product and expensive) BEFORE Microsoft had anything to do with them, I have been trying to come to grips with what the Fast SharePoint marriage means to us all.

I think that to the portion of Fast's clientele that had no interest in SharePoint it may be an annoyance (that may be an understatement). Doubly so for any of them running it on something other than Windows. For the rest of us, though, it is supposed to be an easy path to a high quality enterprise search engine. It's funny, though, because I have been a proponent of SharePoint as a very good poor man's enterprise search engine. SharePoint 2007 search works well. Yes, it is a bit quirky, but it is pretty powerful. It has served us well (though not as an enterprise search engine, just for SharePoint search).

Microsoft isn't content to stand still, though, so they have added this great option. I have not worked with even a beta or demo of the product, and as far as I know, pricing has yet to be released, so my impressions are based on fairly thin marketing vapor, but it's still OK to start thinking about what it all means.

One would expect this product to scale better than OOTB SharePoint 2007 search, but I wonder if the this is really the case. After all, if you implement this product you probably will be taking it more seriously and devote more resources to it, so THAT will make it scale better too. Old SharePoint search can be scaled quite large without having to resort to anything magical. A million or two documents is a piece of cake.

But I would expect the product to deliver better relevance, with or without active intervention. I am anxious to seek how well search librarian tasks can be delegated - this is important functionality.

Unified installation doesn't look like it is really coming in 2010. From what I've heard, it may be in the same box (or on the same box) but the code base isn't really all that close to SharePoint. Unified administration, on the other hand looks like it IS in the box. But like I said earlier, administration needs to be distributable (think "librarians").

Soon it will be time to stop thinking about possibilities and testing the release product to see how it meets these expectations. Fast in SharePoint may democratizes enterprise search, but a lot will depend on pricing. Soon we will see!

Problems Indexing an EML Inside a ZIP in SharePoint

Previously on Bob Klass.Info (I've been watching too much TV lately, re-watching several seasons of the "Dexter" series in the last few days):

"Friday, December 18, 2009

Adding Zip Search File Type in MOSS 2007

I am a little behind the curve on this. Better late than never.

1. Get the filter pack here: http://www.microsoft.com/downloads/details.aspx?FamilyId=60C92A37-719C-4077-B5C6-CAC34F4227CC&displaylang=en
2. Install it
3. Set up the item type in the SSP
4. Set up a new key for .zip in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\
5. Give it a value of {20E823C2-62F3-4638-96BD-90F4F6784EBC}
6. Restart the search service

That is the shorthand version! This is done for you in SharePoint 2010."

That was all fine and interesting, but then the real interesting stuff turned up. My Foxit PDF ifilter and standard MS text ifilters both seemed to function on files nested within ZIP files. But EML files did not (and EML's further have attachments!).

It turns out there is a property of the ifilter called "threading." This threading is simply an object property to say whether it works in single or multi-threaded modes.

A utility called IFilter Explorer will help you look at threading. I don't know if there is another tool like this anywhere or an alternative to this tool. Running this on my test indexer seemed to work OK, but it is old (in software years - like doggie years, it is about 80) and it seems to be an orphan (widow?). But it beats sifting through the registry manually.

Now it gets (unnecessarily) messy.

I was looking to find how EML indexing works. It uses:

• c:\windows\system32\mimefilt.dll
• content type message/rfc822
• GUID of {5645C8C2-E277-11CF-8FDA-00AA00A14F93}
• related PersistentAddinsRegistered of {89BCB740-6119-101A-BCB7-00DD010655AF}

I should have found the threading model set as "both" indicating that BOTH single threaded or multi-treaded daemons can use it. I found it marked as "Bo" in the two places in the registry.

I changed the first "Bo" entry to "Both" and the second one magically was fixed. Time to restart the services and re-try the indexing ... and ... it worked. Even PDF's attached to the EML inside the ZIP were indexed. This "Both" corrupted to "Bo" burned up a few hours of troubleshooting.

Dexter's usual actions would be justified if he could find a guilty party in this case.

Adding Zip Search File Type in MOSS 2007

I am a little behind the curve on this. Better late than never.

1. Get the filter pack here: http://www.microsoft.com/downloads/details.aspx?FamilyId=60C92A37-719C-4077-B5C6-CAC34F4227CC&displaylang=en
2. Install it
3. Set up the item type in the SSP
4. Set up a new key for .zip in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\
5. Give it a value of {20E823C2-62F3-4638-96BD-90F4F6784EBC}
6. Restart the search service

That is the shorthand version! This is done for you in SharePoint 2010.

Adding a New Text Search File Type

As heavy Interwoven document management users, we sometimes include Interwoven link files (.NRL files) in SharePoint document libraries. This doesn't give a whole lot of functionality in and of itself, but it is necessary. The NRL is a very simple one line text file that contains a library name and a document and version number. There are times when a user might want to search on the document number, so we needed to add the NRL as a searchable file type.

To do this, there are two places the extension needs to be added in the registry, and the SSP needs to know about the file type (Search settings / File types / New File Type). Your registry keys will look like the entries below. It would be good to verify the GUIDs with the TXT entries on your system. If you navigate in the registry to the locations below you will see how the keys look.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.nrl]

@="{C5BD8BA8-4209-4A15-B010-534AEB020A54}"

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.nrl]

@="{4A3DD7AB-0A6B-43B0-8A90-0D8B0CC36AAB}"

Naturally, this would extend to other text file types and of course you will do this in your test environment first, etc., etc., blah, blah.

Finding a SharePoint Database GUID / Restoration Tips

I needed to run the stsadm command preparetomove with the oldcontentdb switch (at least I thought I did) for a database that I wanted to restore in our testing environment. Running this command is supposed to fix sync issues when moving databases around.

Although there probably is a more efficient way to query the database (maybe a config database?) to get the database GUID, there is an ID parameter on some URL's. So I added the content database in Central Admin. After that you can take the ID from the URL for that database like so:

http://qapt03ms:8800/_admin/oldcntdb.aspx?DatabaseId=%7BF6FD3F98%2D1044%2D4728%2D8C6D%2D2A22140FFC13%7D

%7BF6FD3F98%2D1044%2D4728%2D8C6D%2D2A22140FFC13%7D

F6FD3F98 - 1044 - 4728 - 8C6D - 2A22140FFC13

Then you can run the command:

C:\>stsadm -o preparetomove -contentdb servername:databasename -oldcontentdb F6FD3F98-1044-4728-8C6D-2A22140FFC13

Operation completed successfully.

You can see that a couple characters get stripped from the beginning and end (%7B and %7D) and the "%2D" are the dashes.

I've done restores without cleaning it up this way but I figured it's time to start doing it the right way.

Take Control of Your SharePoint Crawl Schedules, Content Sources and Indexes

All my farms were set up (the old way) with one server running Central Admin, and generally I use that for an Indexer too. On top of that, I use a certain utility (which I am not at liberty to discuss in detail) which also runs on the Central Admin server(s). This can sometimes put an intense burden on one server (while the others are loafing).

One thing I am going to do, is load balance my Central Admin and spread it (and that certain utility) around. My setup now is just plain wrong. But in my defense, at one time it was right, and when we did our sanity checks with other experts, it still was right. Once things started getting heavier (indexing 500 GB, then over 700GB of content), there isn't much room for error. Our data center is miles away, but I think I can hear the little fans in those blade servers cranking like mad from here. VVvvvvvv...

Until I redo my Central Admin sites, I have to be cautious about what activities that over-burdened server is doing. One thing I do is turn off indexing when I know I will need those resources. Indexing takes disc space and CPU. I've seen big full crawls fill up lots of temporary space. Be sure to factor this in. It's so easy to take control. You can stop a crawl, but better yet, just don't let a new one start. Change the schedule to fit your activities. Use something like "Every 20 minutes from 8:00 AM for 810 minutes." That will start the last incremental at 9:30 PM, and at 10PM, you should have all the resources of that server for other tasks.

This relates a bit less, but one of my regrets on my setup is that I didn't separate things into different content sources. The logical thing would be to break it up by web app. I will do this soon too. That way you can prioritize (by starting one first) or set separate schedules for different content.

In a really large site, I suppose you could use separate SSPs and manipulate where they are and what they are indexing. We started to go down that path, but if you keep everything together, and just watch how you set up content sources and crawl schedules, you can get a whole lot of useful search indexing (out of not much hardware). Under one SSP, you can have a universal, site-wide index, with no additional setup.

Fixing SharePoint Search Propagation Problems - Part II

As a continuation of Fixing SharePoint Search Propagation Problems ...

In my previously described situation (stuck on propagation with a few other issues thrown in), the problem recurred, and repeating the procedure (moving the index file location on all query servers) again provided relief.

Since I needed more than a few hours of relief and I could see nothing new was making it's becoming available to search, I also stopped indexing. Over night, this allowed propagation to clear itself. Since all was well, I boldly turned indexing back on. More good results - all the new content made it to the query servers and continued to do so. I still may have issues because after a while, the propagating status once again seemed stuck, but content is getting added and we are otherwise healthy (otherwise - that is a big qualification).

It would be great to get an in-depth explanation of what the services are doing when they report various statuses. I wish I could give one - I want to get this explanation. My own experience has been that although monitoring the services can be alarming, they work well. Indexes are built and updated quickly, even when things do not appear to be working very well. This from a person whose life has been made much more stressful by having to watch over this system.

Fixing SharePoint Search Propagation Problems

See also Part II

I have been baby sitting my SharePoint search engine lately. I have some long term fixes I am planning to deploy, but in the mean time, things sometimes go bump!

The latest problems surround the engine sticking on "Computing ranking" and then today a propagation issue. The indexer eventually found itself unable to communicate with the query servers. This got ugly fast. Search results turned to garbage. They would cross scopes and return all kinds of erroneous stuff.

I was getting pannicky, all the while hoping I would not have to reset content. This I thought would very likely be a total fix, but drastic - the all new index would be pretty meaningless for quite a few hours. Resets of services and things were not going to fix this problem. Since the indexer seemed to have lost contact to the shares where the indexes were supposed to go, I decided to change the locations for the index files on the query servers.

In case you forgot, you do this in Operations > Services on Server > Office SharePoint Server Search Service Settings. For each of them, I put it in a brand new location. This didn't seem to help at all until they were all done. Then it all came back (fairly quickly). I still have a stuck on "Computing ranking" problem, but I have more reasonable content. I still intend to do that "Reset all crawled content," but I can do it in off hours.

See also Part II

PDF Ifilters in SharePoint - Follow Up

I would like to add an addendum to http://bobklass.blogspot.com/2009/04/pdf-ifilters-in-sharepoint.html.

I was not aware of PDFLib's ifilter until I was near the end of my testing and procurement a few weeks back. Since I still had a pretty good test setup for this, and I needed to do some final QA, I decided to test PDFLib too.

Before you can test PDFLib you will need to get yourself a license from their sales group. They give you a reasonable testing period and the process is painless.

In today's test, PDFLib's installer didn't add both of the registry keys I mentioned in my last post, only the first.

• [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf]
  
• [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf]

The GUID for PDFLib seems to be {47A1AF35-C345-475d-AE68-EB07E948BD07}

I added the second manually. I would guess it is not important if you have MOSS.

My test set was not a very challenging bunch of documents (about 680 MB, 1200 documents). In some previous tests, Adobe was much slower (as anticipated) but in the ones today, they all three were similar. I previously was running the test after resetting the content. On today's I did full crawls (to save time??).

Interestingly, the quality of Adobe was much lower. The same search terms produced far fewer hits with Adobe while Foxit and PDFLit had the exact same results. It almost seemed anomalous, but my main objective today was to review the installation process (I have beaten that to death, no?) and give PDFLib a quick test, so I don't have time for further tests.

We already bought Foxit. I may have been able to save a little money with the way PDFLib is licensed, but I think I made the right choice because of Foxit's more foolproof installer. Hopefully I can add one more follow up article once I have been running Foxit in a large production environment for a while.

PDF Ifilters in SharePoint

See also http://bobklass.blogspot.com/2009/06/pdf-ifilters-in-sharepoint-follow-up.html

We have more PDF files than anything else in our SharePoint sites, by a huge margin. We also have some pretty over-sized hardware, so up until recently, we have been able to get by with the single-threaded free Adobe ifilter.

When the Foxit ifilter was released I did some testing and could not see sufficient benefit to make the change. I am pretty sure my testing was flawed, as others have confirmed the superior performance of the Foxit ifilter. I carefully retested it and with a relatively small sample size (less than 2000 files) I got a benefit of not quite double the throughput. I think that with a larger sample the benefit would be greater, but the successful test is sufficient for my needs and allows me to justify this purchase.

Checking Ifilter Registry Entries

Along the way I experienced some difficulties. The instructions for installing the Foxit ifilter are very simple, and sometimes they work as they should, but not always. If you are doing a first time installation of a PDF ifilter, follow Foxit's instructions carefully. For a replacement of Adobe, you simply uninstall the Adobe ifilter and then you install Foxit. I did this uninstall/install cycle a couple times. Either of the uninstalls may not always happen cleanly, so you may need to get out your SharePoint/IIS/Windows hammer and do a bit of tapping.

As I was testing, I was getting an error on all the PDF's that there was no ifilter installed. I ended up manually modifying two registry keys, at first just to put back Adobe so I could test that. Then the uninstall/reinstall worked, but I still checked it just to be sure. My problems could have been from not following procedures (starts, stops, etc.) or possibly from the install / uninstall not being complete. Checking these keys was a big part of my solution.

The two keys are:

• [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf]
  
• [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\Search\Setup\ContentIndexCommon\Filters\Extension\.pdf]
  

Their multi-string value should be the appropriate GUID for the classid for the ifilter you are using (I think that's what this is):

• {987f8d1a-26e6-4554-b007-6b20e2680632} Foxit
  
• {4C904448-74A9-11D0-AF6E-00C04FD8DC02} Adobe 6
  
• {E8978DA6-047F-4E3D-9C78-CDBE46041603} Adobe 8 (or 9 or 64 bit??)
  

You also need to be sure to start and stop the search services and why not throw in an IIS reset while you are at it (hammer). Of course a reboot has the same effect (more hammering). After doing that, to make your tests cleaner, it's good to get the setup primed. You can do that by running it twice (reset the content in between), or just enough the first time to be sure that everything is running. If you monitor the index you will see a minute or two delay on an un-primed setup.

I am looking forward to getting this into a production environment with hundreds of thousands of PDFs. I hope I won't need my hammers, but at least I know where to look if it doesn't seem to be working.

See also http://bobklass.blogspot.com/2009/06/pdf-ifilters-in-sharepoint-follow-up.html

Launching Directly into Lotus Notes Applications

Launching Lotus Notes directly into an application is dangerous to workstation stability. To qualify this statement, launches with versions up to 6.5.x were always unstable. I am an ex-Notes developer and a little behind. I am just getting into 8.5.1, but I am not going to retest this behavior until 8.5.1 is completely rolled out (and the need arises).

There are a number of ways to do launches directly - .lnk files, shortcuts into a document, the Notes://ServerName/Directory/DatabaseName.nsf format embedded in HTML. All of these work. Sometimes. For a while. If everything works out OK. But they will consistently fail and cause Notes to crash. 

It would be great for a Notes guru, who somehow still cared about version 6.5, etc., to come along and tell me I am wrong. I welcome that. If anybody has had good experiences with Notes launches, let me know.

A little history: we use the Lotus Notes email platform because of it's ability to handle many terabytes of mail. It has aways been the most scalable and secure mail product. I have worked with Notes as an application platform since version 3 (1993), and it has always been one of my favorites. We put a moratorium on new Notes apps several years back. I was fortunate to have been assigned to creating our SharePoint environment, starting in 2005. 

Along the way, there have been several attempts at links like this, and they have always failed. Also keep in mind that we work in a fairly well controlled environment - standardized desktop and server setups, etc., and it still always fails. I am not anxious to try this again with Notes 8x, but I guess that will be necessary at some point.

Easy Way How to Find SharePoint Subsite Size

Revision: All the following was fine and dandy for SP 2007, and maybe if you don't have access to Powershell. If you do, just do this:

$used = (Get-SPSiteAdministration -Identity ).DiskUsed

$used

_______________________________

I was looking for a GOOD way to find out the size of subsites. It seems a lot of people are struggling with this. You could try SharePoint Designer. That's fun. When you ask it site properties, it will give you a different answer depending on what document libraries or lists you touched. Obviously that is not going to be reliable.

I'll cut to the chase (although I was trying to be as wordy as possible). This isn't a GOOD way, but it is a very simple way: 

• open the site in Windows Explorer
• navigate to the root of the site or subsite in question
• right click, properties

That may be a little resource intensive - it takes a while to open. I think it may have to open a lot more than it appears just to get you that number, but there it is in the properties window. Piece of cake.

Post Script: http://www.codeplex.com/SPUsedSpaceInfo is a console app to get a CSV listing of sites and their size. Beware that the setup is pretty heavy handed - a Dotnet 3.5 SP1 installation starts right up if you aren't there already. 

Time Zones and Site Templates in SharePoint

This little problem had blog entry written all over it. We use a site template created in the SharePoint user interface (not Visual Studio) in several farms. Maybe we should stop that practice as it is starting to slow us down, but that's how it is currently deployed. 

Besides being a pain because the template needs to be re-saved in each site collection in order for our stuff to work right, we also have to do it to set the regional settings because:

• When you save a site template in the SharePoint GUI, it saves the regional settings in the template.
  

Use this to your advantage!

See also my blog entry about how simple and straight forward time zone issues are in SharePoint: http://bobklass.blogspot.com/2008/06/regional-settings-are-simple.html.