Calculated Fields, XSL Sums, and Commas in SharePoint
I find that, programmatically, SharePoint is a witches brew of different technologies which work together as long as you don't need to do things your way. In this instance I'm creating a list of Invoices which will serve as the parent item to a list of Invoice Items. Each Invoice Item row contains (among other fields) a field for quantity, the amount for each item, and the total. The total field is a calculated field, displaying the product of the amount and quantity fields. Initially I had the total field set up as a number, which seemed to make sense considering I was working with an equation. Where it did not make any sense is when I put together a form which found all the Invoice Items for an Invoice and summed up the total field values to create an overall total for the Invoice. In my initial tests everything actually ran fine until I tried putting in an amount of 1000 for a particular Invoice Item. Or, rather, put in an amount and quantity whose calculated total was 1000 or more. It turns out that by the time SharePoint does the calculation and hands off the value to the XSL for transformation, there is a comma in the value which the XSL sum function chokes on. I either received nothing on the web page or NaN, and I could not find a simple way to format the total field through the SharePoint interface. I switched the total field to text format and that didn't help. I even switched the amount field to text and that didn't help. My original total field looked like this: =Quantity*Amount What I ended up doing after a mere 18 hours of research was keeping the amount field as a number, the total field as text, and using the following formula to calculate the total field: =TEXT(VALUE(Quantity)*VALUE(Amount),"0.00") The calls to VALUE are probably overkill, but in essence I told it to get the product and format it as a number with two decimal places. And, even though the total field is technically a text field, the sum function in the XSL operates on it properly. This technique could also help out in a worst case scenario where you do an XSL calculation on a numeric field in SharePoint -- create a calculated field whose sole purpose is to transform the numeric field into a plain vanilla version. Labels: nerdville, sharepoint
An interesting article on why us Windows users were so lucky to end up with the Arial font pre-installed on our systems rather than Helvetica. Short answer: Microsoft were cheapskates: When Microsoft made TrueType the standard font format for Windows 3.1, they opted to go with Arial rather than Helvetica, probably because it was cheaper and they knew most people wouldn't know (or even care about) the difference. Apple also standardized on TrueType at the same time, but went with Helvetica, not Arial, and paid Linotype's license fee. Of course, Windows 3.1 was a big hit. Thus, Arial is now everywhere, a side effect of Windows' success, born out of the desire to avoid paying license fees. Labels: graphic arts, nerdville
This Is A Test of the Emergency Broadcast System
I've just downloaded Windows Live Writer and hooked it up to this blog. Just testing to see how well it works with Blogger. So far it looks like it takes a copy of your template from Blogger and uses the CSS when you are writing, so you have an idea of what the final output is going to look like. Sweet. The functionality is also offline, so I don't have to be on Blogger's site when writing/saving/editing posts/drafts. One thing that it does seem to be lacking is the ability to use Blogger's label function. Maybe it's time to use the labeling/tagging function of a third party site. Update: Duh. It's a nomenclature issue, not to mention a near-sightedness issue. There is a categories field below the posting window (they are called "labels" in Blogger), along with a field for force-setting the publishing date. NICE. What's not so nice is the interface for selecting/entering the category. Update II: You can add plugins, of which there are a bevy. For instance, there is one for Picasa and for Flickr, which I often use for hosting images for this blog. SCHWEET. Labels: nerdville, tech
Coming: Text Displays On Shopping Carts
Text displays on shopping carts, which seems like the first step of an idea I barfed up a couple years ago. Via: UbergizmoLabels: nerdville
OK, this is the first method I've put in this set of free web services. Why GetGuid? I had a need to grab a GUID in javascript from time-to-time but had my doubts that it could be done in earnest in javascript. There are a few implements hanging around where random base16 characters are strung together in a GUID-like format, but this algorithm doesn't fall under the "official" designation of GUID and I guess allows for a greater chance of generating a duplicate GUID (although I think those chances are infinitesimal). So, this web service exists as it calls upon the GUID-creating ability of Microsoft SQL Server. I chose this route rather than the GUID methods in the .Net framework because I've been working on getting my database chops back up to snuff and this seemed like a pretty low-stress way of starting that. In any event, it should be a true GUID and technically the numbers should never duplicate.
Method: GetGuid JSON Parameters: - op -- set to "GetGuid".
- cb -- set to the name of your javascript function you want called back.
Returns:GUID in string format.
Labels: lpsws, nerdville, programming
So, every once in a while I'll run into a programming conundrum in something I'm working on and either wish there was something I could download and implement fairly quickly or that there was a web service hanging "out there" that I could hook in to. Well, I guess I'm going to start my own set of web services and leave them hanging "out there" for me to use, and anyone else who is brave enough to use something they are not hosting themselves. I'll be hosting it on my forthcoming company website at the following urls: http://lpsol.com/ws/soap.asmxhttp://lpsol.com/ws/json.ashxYes, I'll be providing both soap and json interfaces. The soap interface is generally useful in standard web services calls, although to implement into your own AJAX-based website or webapp you'll have to write a proxy running on your site which will then access this web service. Not so with the json interface, though. All you'll need to do is include the json url in your web page using a script tag and the proper querystrings to call the function you want, and the service will call back the function of your choice (specified in the querystring) and pass in the requested data as a parameter. While the jsoninterface doesn't include it's own description page, if you click the soap url above you'll find information on how to call each method using soap. When consuming a web service in the .Net environment you generally get a nice class and set of methods to call from the web service -- the Intellisense kicks in and shows you the parameters you need to pass in a what-not. Not sure how it works in other environments. For the json calls you'll have to specify the "op" and "cb" querystrings manually for each method you call. The "op" is short for operation and is the name of the method. "cb" is short for "callback" and is the name of the function you want the server to call back when it's done. For instance, when calling the "GetGuid" method (details on this method forthcoming) you will set "op" to "GetGuid", and if you want the server to call back your javascript method called "procGuid" after it's generated, you would set "cb" to "procGuid". Therefore, the whole tag would look like this: <script type="text/javascript" src="http://lpsol.com/ws/json.ashx?op=GetGuid&cb=procGuid"></script> If either of those parameters are omitted then an error is thrown by using an alert. Other parameters may be required on a per method basis. The data returned from both interfaces will formatted in a similar fashion. The packet will be in two pieces, an "error package" and a "data package" encapsulated inside a "return package." You can actually see this arrangement if you run the GetGuid method through the soap url or pasting the value of the src parameter from the above script tag in your browser address bar. The error package will always contain the following pieces of information: - Flag. This will either be True or False, indicating if an error occurred.
- Message. The error message.
- StackTrace. The stack of methods called leading up to the error. Probably not very useful to you, but useful to me in figuring out the problem.
- AdditionalInfo. This may contain any other useful tidbits I stuffed in there before pushing everything back to the browser.
The contents of the data package will vary. I'll try to include detailed information for each method. I have a few more idea for new methods that I'll work on at some point, and requests for new methods are also welcome. Lastly, in the event that these services gather any traction, I'll try to keep all related posts tagged with the "lpsws" label. Enjoy. Labels: lpsws, nerdville, programming
A hack to get the new Mac OSX Leopard running on a regular PC.I'm a bit skeptical, and don't have a spare PC to test this out. Anyone? Labels: nerdville
Holy Sweet Mother of Potatoes
A solid state hard disk, starting at 640 GB and fitting on a PCI card. The performance doesn't look too shabby, either. Looks like my kvetching about our state-of-the-yesteryear technology in our computers may be coming to an end. Via: "echef" at SharePoint blogsLabels: nerdville, tech
Not-So-Global Navigation In SharePoint
This is another fabulous adventure in nerdville. I'm posting this mostly for my own edification, so the three people who read this blog and are not finding themselves here via the General Lee, feel free to move along. I am still getting my head wrapped around the paradigm that is SharePoint. From one perspective, it's a great platform to starts or build your intranet on if you have a lot of money (I call it "intranet-in-a-box") and not a tremendous amount of know-how. You can start creating portals and sites in no time at all, create rudimentary data models to hold information, set permissions on everything, and then start pumping information into it. From the other perspective (that would be mine, or if I may be so presumptuous to call my perspective "the developer at large") it can be a complete PITA. I'm finding that even the slightest modification to the system which can not be handled via the web-based tools or even the new SharePoint Designer software requires time, patience, and a deep swear jar. The latest incident involves trying to use the same global navigation bar in the "MySite" portal as the parent portal. I would think this would be a fairly trivial task, but not really. Actually, it kind of is after googling the entire Internet and finally finding a solution (it's located in the comments). Of course, the solution didn't quite work as-is, so I'll regurgitate. In the masterpage of the offending MySite portal there is a "SharePoint:AspMenu" tag, which is where all the action is at. There are at least a couple, so find the one specifically with the "TopNavigationMenu" ID. Mine looks something like this: <SharePoint:AspMenu
ID="TopNavigationMenu"
Runat="server"
DataSourceID="topSiteMap"
EnableViewState="false"
blah blah blah />
Note the DataSourceID. This tells the control where to get the info it needs (namely the titles on the menu and the links they go to). This object containing the DataSourceID is located a little further down the page: <asp:SiteMapDataSource
ShowStartingNode="False"
SiteMapProvider="SPNavigationProvider"
id="topSiteMap"
runat="server"
StartingNodeUrl="sid:1002"/> OK, now we're getting somewhere. According to the aforementioned post and comment, this little bit of code provides a contextual data source for the menu at run-time. The way to force it to use a data source of my choosing (there are a handful of them defined in the web.config for the application) is to wipe that piece of code out altogether and replace it with something resembling the following:
<PublishingNavigation:PortalSiteMapDataSource
ID="topSiteMap"
Runat="server"
SiteMapProvider="CombinedNavSiteMapProvider"
StartFromCurrentNode="true"
ShowStartingNode="false"
TreatStartingNodeAsCurrent="true"
TrimNonCurrentTypes="Heading"
/>
And for this tag to be recognized on the page there must be an accompanying registration for it at the top: <%@ Register Tagprefix="PublishingNavigation"
Namespace="Microsoft.SharePoint.Publishing.Navigation"
Assembly="Microsoft.SharePoint.Publishing, Version=12.0.0.0,
Culture=neutral, PublicKeyToken=94de0004b6e3fcc5" %> So far, so good, except after doing this I received the following error message on the page: Could not load file or assembly 'Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=94de0004b6e3fcc5' or one of its dependencies. The system cannot find the file specified Huh? Turns out the problem here is simple -- the "PublicKeyToken" didn't seem to match correctly for me as quoted in the post. Along side that registration I put in were other registrations which had matching PublicKeyToken values. I simply copied that value over and voila, it worked. So far the only menu I can get it to display is the custom one you create through the process of customizing the site navigation for the specific MySite portal. I can't figure out how to set the site navigation to the same one as the parent portal, but as long as I have some control over it for the time being I'm fine with having to set the navigation in two different areas. Labels: nerdville, sharepoint
The Best SPAM Catcher of Them All
 It's called GMail. For some reason I've been experiencing an explosion of SPAM this week on the email account I've been using for, oh, about 10 years. With my regular GMail account I noticed that they have a wonderful SPAM filter which is just about spot-on with it's filtering. I'm already hosting the mail accounts for my new LLC there, so finally decided to spend the half hour worth of time switching my kings-x.com domain email over. For some reason the changes "took" pretty quickly. By the end of the half hour the email seemed to be pretty much arriving at Google's servers instead of the GoDaddy servers (I was using the one free email hosting account you get there with each domain). So far, so good. About 24 hours later you can see that GMail has already trapped well north of 200 SPAM messages. I'm not quite sure why a full fledged business would not use this free service. Labels: nerdville, sysadmin
While I'm In Nerdville...
I'm putting up this post for my own posterity, as the next time I blow up my Exchange Server configuration I'll hopefully have enough bread crumbs laying around allowing myself to fix the problem in an expedient manner. That is, in less than an hour rather than a whole week. This little story is actually an epoch, so you can either bail out or buckle up. I had a bangup week when the church server blew up, because that same week I also messed up my access to my Exchange server. Typically Outlook will talk with Exchange Server over using RPC (remote procedure call) protocol over the Internet. RPC allows one computer to pass commands to another computer over the network. RPC uses port 135 on your computer and is typically blocked by ISP's as access to port 135 (and therefore the RPC service on any computers listening) can wreak all sorts of neat havoc, as you can imagine. So Microsoft introduced HTTP over RPC, effectively wrapping RPC calls inside of the same protocol used for web surfing. I won't go into the gory details of how to enable this on an Exchange Server as there are two great how-to articles I've used here and here. In my original setup of this I had deviated from their recommended plan and used plain HTTP rather than HTTPS for the simple reason that I did not want to pay for a server certificate for the box. These can cost anywhere from 75 to 300 bucks per year. Neither of these articles really touched on how to use straight HTTP for RPC. After sufficiently messing around inside the RPC folder properties in IIS I got it to work on a regular basis both in and outside my local network by using NTLM authentication without also enabling basic authentication. On the client side in Outlook I configured the Exchange account to use NTLM authentication on the HTTP connection. Every time I fired up Outlook I would receive a username/password challenge, and after I passed through that Outlook worked hunky dory. Until the day I installed a SharePoint site on the same server using the same default web site that the Exchange server was using for RPC. After wrestling through a few rounds of SharePoint installation struggles I told it to can the website it was using in IIS. Oops. Bye bye HTTP over RPC, bye bye Outlook Web Access, and bye bye some other projects I was hosting there for client review. First I had to create a new default app in IIS including a place for it to live. Then with a little finagling I was able to reconstitute all the folders Exchange Server had built in the default app with a little help from this thread. Replacing the RPC folder was a sinch, and then I basically just went and redid everything those two aforementioned articles told me to do. Except this time when I tried to log into Exchange from Outlook I kept getting prompted. Over and over and over. Every once in awhile it would log in, but most of the time not. The authentication just wasn't taking, and I tried six ways to Sunday to fix it either in IIS or in the account settings in Outlook. From my research it appeared that it just wasn't going to work without switching the connection over to SSL and changing the authentication mode from NTLM to basic. When you do that, Outlook requires SSL. The nerve. I'm a complete idiot when it comes to SSL, certificates, etc. I know I could install the service on my server that would allow me to issue certificates to my own websites (thereby allowing my to connect to them via SSL) but since my server is not an official certificate authority (CA) I knew that Outlook would choke when trying to log in (it did, I tried). When I used Internet Explorer to surf to the area that Outlook was trying to access, I would get one of those big ugly warning dialogs pop up telling me the certificate looked valid but the CA is not found or trusted. I tried installing the certificate through that dialog into my trusted root certification authorities (through internet options in your control panel) but it would never stick. What did finally work was exporting the certificate from the server through IIS. I viewed the certificate in IIS for the RPC site, and then chose export. The certificate export wizard fires up, which for some reason does not appear if you try to export the certificate through the certificate authority control panel. The wizard allows you to include the private key in the certificate, which I did, and this causes the export format to be a personal information exchange (. pfx) file. I told it to include all certificates in the path, enable strong protection, and to leave the private key after exporting. After exporting I hauled this key over to my laptop and imported it into the trusted root certification authorities. Bingo, it stuck, and when I tested in IE it worked without popping up a big ugly dialog box. The final test, using Outlook, also passed. It prompts me once the first time I log in, but then connects and is happy. I can also see that Outlook is using HTTPS for the connections to Exchange Server when snooping the Exchange Server connection status window. See, when I had the whole shooting match configured for HTTPS without actually implementing HTTPS, Outlook would fall back to TCP/ IP on the local network. Great at home, not so much when accessing through the Internet. The benefit of going through this pain and anguish is that now my email communication is encrypted. All it cost was about a week of my life and 1/16 th of an inch of my hairline. Labels: nerdville, sysadmin
Be Master Of Your Domain(s)
Well, I blowed up the server at my church real good. Actually, the hard drive went and I hadn't been keeping religious (ha-ha) backups, so a lot of stuff went bye-bye. The most unfortunate thing of all was that the server was master domain controller for the Active Directory network. In fact it was the only one. When I resurrected (ha-ha) the server I created a new domain for it to master. I wasn't quite sure what the consequences of bringing a server back under the same domain would be for all the users, so I let them continue to log in with their old credentials. Once I got the server back up and running I was faced with the daunting task of moving everybody over to the new domain. This generally means recreating their accounts on the server and then copying the contents of their old documents and settings folder over to their new documents and settings folder. This may copy stuff over but generally all the settings will be out of whack -- icons not where they are supposed to be, wallpaper and colors don't look right. I'm not quite sure that Outlook is all the same when you switch over, either. Then I discovered a nice little registry hack on the Microsoft web site. After switching a computer or two over using this method I was able to get the entire process down to about ten minutes per computer. A synopsis of the steps: - Log in on the computer under the local admin account.
- Back up the contents of the docs and settings folder of the old domain account.
- Change the computer identity to be under the new domain. You'll need the domain admin account info to do this, of course. Note -- once you do this, the user will not be able to access their documents and settings folder using their credentials from the old domain.
- After you've successfully joined the new domain you'll be prompted to reboot the computer. Do it.
- When logging in again, log in with the domain admin account.
- Go to the computer management for the computer. Under users and groups, open the "administrators" folder under "groups."
- Add the domain account for the user to the admin group. Sorry, I know this probably violates some folk's domain policies, but if you don't do this the new account has a really hard time getting to the new folder.
- Log out.
- Log on to the computer using the new domain account.
- Log out.
- Log on to the computer using the domain admin account.
- During the last log on using the new domain account a registry setting was added to the computer for that account. Crack open regedit.
- Go here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
- Under this folder you'll see a handful of other folders with cryptic names. These are settings folders for all the accounts that have logged onto the machine. In each of these folders is a setting called "ProfileImagePath." Find the folder that as the location of the old domain account docs and settings folder in there. For example, if the user name is "mavickers" look for %system root%\documents and settings\mavickers. Often times the domain name will have been appended after the username with a period. "mavickers.olddomain", for instance.
- Copy the old ProfileImagePath location to the clipboard.
- Find the folder corresponding to the new domain account you've created. Generally it will be the last or next to last folder in the list.
- Open the ProfileImagePath setting for the folder and paste the value from the old account into it.
- Close regedit.
- Go to the documents and settings folder for the old domain account and open it's properties.
- Go to the security tab.
- Add the new domain account to the list on this tab.
- Give that account full access.
- Click the advanced button and at the next window click that checkbox at the bottom which tell it to apply the security settings to all the children of that folder.
- Click OK until you're back out at the desktop.
- Log off.
- Pray.
- Log in with the new domain account.
- Voila, everything should look just as it did before.
The only thing I've noticed that doesn't work exactly right is that email passwords in Outlook do not carry over -- you have to reenter them. Oh well. Beyond all of this KEEP GOOD BACKUPS. Since this disaster I've moved all data to an external RAID 1 enclosure which is backed up nightly to Amazon's S3 service using S3 Backup. Labels: nerdville, sysadmin
The XCOPY 256 Character Barrier
For old schoolers, if you find yourself in a pinch using XCOPY to copy a bunch of stuff from one location to another and find yourself 37 folders deep and running into the 256 character limitation of XCOPY, try XXCOPY. If you don't then feel free to ignore this post. Labels: nerdville
Winchester Technology: I'm Not Dead Yet
"Robert X. Cringely" of I, Cringely writes about an upgrade to hard disk technology that he is invested in, standard hard disk platters made of lighter, thinner aluminum or titanium foil. The result is more platters in a drive, more information packed on the platters, and a dramatic reduction in energy consumption. While the initial focus of the technology looks like mobile devices, the technology looks like it has application for the desktop: The technology in question replaces the aluminum or glass platter in your hard disk drive with a "platter" made from stainless steel or titanium foil that is 22 microns or 25 microns thick, respectively. The materials cost more but we use so much less of it (the disk is so incredibly thin) that the total material cost is substantially less. This "floppy" material has the same kind of magnetic coatings used on standard disk drives and our drives live on the same technology growth curve as those others. The way we obtain greater storage density is simply by putting more platters in a drive (say 12-15 instead of 4-5 in an enterprise 3.5-inch drive) because they are much thinner and can be stacked closer together. The only parts of the drive that are significantly different are the platters and the heads and the heads vary only in having an extra slot. There is no rocket science here, but what science there is is patented.
Lot's more in the original article. I'm mostly for removing high-speed, low-margin-of-error moving parts from the computer, but this technology looks very intriguing. [ via LockerGnome Nexus ]Labels: nerdville, tech
Solid State Drives Ramping Up
Here's another one coming out this year, this time by a company called PQI (kind of ruins the alliterative branding that was happening). This one doubles up both the storage capacity of prior announcements (to 64GB) and the estimated on-the-street pricing (to $2k). Hard to imagine what a perfectly quiet PC is going to be like. I'll have to be content with listening to the sound of the ringing in my ears. [ via Engadget ]Labels: nerdville, tech
|