JSpot

VSTO with Outlook 2003

noreply@blogger.com (Jerry Hanel) — Tue, 21 Jul 2009 19:08:00 +0000

I'm creating a VSTO plugin for Outlook 2003. My problem? I'm using DevStudio 2008 professional.

It has a project template for Outlook 2003 add-ins, but be warned. It is far from complete.

I was able to build my add-in, but distributing it became a nightmare. A royal, amazingly difficult, pain in the gluteus-maximus.

So, how'd I get it installed? First, I had to make sure that the Visual Studio Tools for Office Runtime was installed on each PC.

You can download that here

Next, I had to make sure that (and THIS is the undocumented part that caused me SERIOUS headache) the Primary Interop Assemblies (PIA) for Office 2003 were installed on each PC.

You can find those here.

Next, I had to copy the DLL(s) to the user's hard drive and register each one as able to run. Apparently VSTO (understandably so) has a very very tight security policy. You ahve to register EACH dll that you want to use, and any DLLs that THOSE use. Basically, if you copy it, you register it.

In order to register the DLL's I used a batch file

echo Setting Security... REM Turn off prompting for a minute. "C:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol.exe" -polchgprompt off REM Register each DLL using the FULL PATH to the DLL. REM Repeat this line for each DLL that you want to register. REM I used the same [Project Name] and [Description] for each DLL. "C:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol.exe" -u -ag All_Code -url "[Full Path to DLL]" FullTrust -n "[Project Name]" -d "[Description]" REM Turn prompting back on. We're done. "C:\Windows\Microsoft.NET\Framework\v2.0.50727\caspol.exe" -polchgprompt on

After setting up all of the applications and security, we now have only one thing left to do... tell Outlook where to find it's new add-in. You ahve to do this via Registry settings.

I put everything into HKEY_LOCAL_MACHINE instead of HKEY_CURRENT_USER. It seemed to work, but some people suggest against this on the forums. I prefer it, so use which ever one suits you best.

You can find the registry keys to set here at the bottom of that page.

After *ALL* of this, I was finally able to get my add-in off the ground. I hope this sincerely helps someone else.

Clean PropertyGrid selectors

noreply@blogger.com (Jerry Hanel) — Fri, 30 Jan 2009 20:10:00 +0000

Over the past week, I've been working alot with the PropertyGrid control. These controls are great if you have a bunch of wildly-differing or unknown classes. You can feed the class to the PropertyGrid and it allows the user to directly manipulate the object.

The drawback, many times the field names or values are not user-friendly. In fact... they can be completely ugly.

The key is being sure that your classes are PropertyGrid-friendly. Each field should specify some compile-time attributes like the ones below:


        [
         CategoryAttribute("2 - Bottom"),
         DisplayName("Bottom Diameter"),
         Description("The diameter of the bottom attachment.")
        ]
        public virtual double BottomDiameter {
            get
            {
               ...

However, what happens when you want to edit something that's not a primitive like double or string?

I had several fields that could take a string as input, but would parse the string and result in a specific object. I've found a very nice, clean, simple solution for this. Before I'd stumbled on this solution, I was using UITypeEditor.

First, I would have to identify all of the properties that I want to mangle with this UITypeEditor.


    [
     EditorAttribute(typeof(ObjectSelector), typeof(UITypeEditor)),
     DisplayName("The Object List")
    ]
    public SomeObject O
    {
        // ... get, set ...
    }

I would create a UITypeEditor that relied on a corresponding form (which was nothing more than a form containing a listbox at 100% width and height.)


    class ObjectSelector: UITypeEditor
    {
        IWindowsFormsEditorService editorService = null;

        public override UITypeEditorEditStyle GetEditStyle(ITypeDescriptorContext context)
        {
            return UITypeEditorEditStyle.DropDown;
        }

        public override object EditValue(ITypeDescriptorContext context, IServiceProvider provider, object value)
        {
            // ...
            // Define some variables...
            // ...

            if (provider != null)
            {
                editorService =
                    provider.GetService(
                    typeof(IWindowsFormsEditorService))
                    as IWindowsFormsEditorService;
            }

            if (editorService != null)
            {
                MyDropdownForm f =
                    new MyDropdownForm(
                    (SomeObjectThing)value,
                    editorService);

                // Populate the listbox on the form before displaying it.
                f.Populate();

                editorService.DropDownControl(f);

                value = f.SelectedObject;

                if (value == null) return null;

                // if the two objects are actually the same object, then return.
                if (value.Equals(OldValue) || f. SelectedObject == OldValue) 
                {
                    return value;
                } else {
                   // ...
                   // Populate my new object as-needed.
                   // ...
                }
            }

            return value;
        }
    }

I would then have to include a form MyDropdownForm:


    public partial class MyDropdownForm : UserControl
    {
        private IWindowsFormsEditorService editorService = null;

        public object SelectedObject = null;

        public MyDropdownForm (
            object CurrentValue,
            IWindowsFormsEditorService EdService)
        {
            InitializeComponent();

            editorService = EdService;
            SelectedObject = CurrentValue;

            ObjectList.SelectedIndexChanged += new EventHandler(ObjectList_SelectedIndexChanged);
        }

        void ObjectList_SelectedIndexChanged(object sender, EventArgs e)
        {
            SelectedSObject = SegmentList.SelectedItem;

            this.editorService.CloseDropDown();
        }

        internal void Populate()
        {

        // ... you get the idea...

        }
    }

This was alot of code. the worst part is, if I wanted to change anything about how it worked, I needed to add two new files to my project. And they were clunky files, at that.

That is... until I discovered TypeConverter. This simplified things INCREDIBLY. I still had to identify the properties, but the Attribute was much more concise:


    [
     TypeConverter(typeof(ObjectConverter)),
     DisplayName("The Object List")
    ]
    // NOTE that it is a string. Use the private in the get and set to
    // use the object's StringParse(str) method.
    public string O
    {
        // ... get, set ...
    }

    private SomeObject _o = new SomeObject();

The rest just became very easy.


    internal class SegmentConverter : StringConverter
    {
        public override bool GetStandardValuesSupported
            (ITypeDescriptorContext context)
        {
            //True - Show the Combobox
            //False - Just take/set the string.
            return true;
        }

        public override bool GetStandardValuesExclusive
            (ITypeDescriptorContext context)
        {
            //False - Editable
            //True - ReadOnly
            return false;
        }

        public override StandardValuesCollection GetStandardValues
            (ITypeDescriptorContext context)
        {
            // Do whatever you have to do here to get your object into a list
            // or array of strings. Luckily, I already had one of those methods
            // in a static Data-Access Object.
            List objNames = daoObject.GetNames();

            return new StandardValuesCollection(segNames.ToArray());
        }
    }

This is MUCH simpler, faster, easier, and more maintainable. I hope this little review helps someone else to build the best PropertyGrid-enabled objects!

A lesson in Extension Methods

noreply@blogger.com (Jerry Hanel) — Wed, 28 Jan 2009 14:14:00 +0000

With C# 3.0, you were given the ability to extend any object. That's right... if some object objFred has a method that takes two parameters -- string and int -- and you need it to take string and double, you can now "roll your own".

I needed to do this very thing this week. In my class, I needed to make a call to a system class. But I needed it to return one of the objects I'd created instead of a double or string.

Yes, I could have just created a method in my own class to handle this, but I wanted to logically keep the method as part of the main library.


public EngVar ConvertToEng(this string str)
{
    if (String.IsNullOrEmpty(str)) return null;

    EngVar V = new EngVar();
    try {
        V.Parse(str);
    } 
    catch 
    {
        return null;
    }
}

Now, within my code (as long as this is in scope), intellisense has a new method called ConvertToEng() for every string in my project. Could I have just used the Parse(string x) method within my code? Yes. But having it handy within intellisense makes coding much faster. And I've found that, for my mind, having it hang off of 'string' makes much more sense.


    ...
    
    string MyString = "E15ft/s^2";
    
    ...
    
    EngVar V = MyString.ConvertToEng();

This just seems to me to be much cleaner and more logical to read.

ListView SelectedIndexChanged vs ItemSelectionChanged

noreply@blogger.com (Jerry Hanel) — Thu, 22 Jan 2009 22:09:00 +0000

I stumbled upon the most frustrating C# dilemma to-date.

I was trying to work out a solution to an issue, and -- naturally -- when an item was selected in my list of items, I wanted to do some magic. What would you reach for in this case? The standard SelectedIndexChanged event. That's what we use in Lists, ListBoxes, or even ComboBoxes. That should work in ListViews too... right?

Wrong. ... sometimes.


private void SomeList_SelectedIndexChanged(object sender, EventArgs e)
{
    // Tell me which item in your list just changed... you can't.
    // You only know that SOMETHING changed. Worse than that... for 
    // each item that changed, this event fires, but you don't know
    // which one it was nor if the selection went from selected
    // to unselected or the other way around.
}

The event exists, so you can use it, but the "sender" is the actual ListView object, and the EventArgs does not contain any handle to let you know which item was selected/unselected. When a user un-selects an item from the list (with six or seven more still selected), I needed to know which one they disabled so that I could do some more magic. But without keeping a list of previously-selected items around, I couldn't immediately tell which one was freshly un-selected.

ENTER: ItemSelectionChanged.

This is the correct event to be using in these cases. It exists (apparently) only for ListViews. Why the change? I'm not sure. Backward-compatibility, maybe? Who knows!

The thing that makes this most useful is that it has an event manager that is much more defined. This event manager returns not only which item is changing, but it tells you whether it is changing from selected to unselected (or vice-versa) and which index it is in the overall list. It's a very beautiful thing.

So the next time you use a ListView control, keep this little gem in your back pocket.


        private void SomeList_ItemSelectionChanged(object sender,
                         ListViewItemSelectionChangedEventArgs e)
        {
            // Note the ListViewItemSelectionChangedEventArgs item.
            // It is a HUGE name, but very important.
        }

Tag-Data Pairs

noreply@blogger.com (Jerry Hanel) — Mon, 19 Jan 2009 17:55:00 +0000

Recently, someone asked me if Tag-Data pairs was a good idea. That's kind of like asking if elephants are good ideas: Sure, if you need a tree pushed over. Not so much if you need something that can fit through your front door.

As with any design question, what parameters are limiting the idea?

In general, yes... Tag-Data pairs can be a quick human-readable format that handle non-object-data efficiently. But if you need data that is hierarchical or object-oriented (as most data is), then no. If you need something more than a handful of fields, or if you need these fields to be grouped or bundled in a hierarchy, then use XML. There are a ton of tools built into the .NET platform for handling XML data.

However, in my previous job, XML was much too bloated for their Nazi-style bandwidth usage. They had to pay per byte of transfer, so each character transferred was precious. In those cases, we actually did use tag-data pairs.

It was quick, lightweight, simple and human-readable. The most annoying part of a TDP packet was that the data inside was not incredibly easy to get at. For example, if you needed to know the person's last name, you had to parse the TDPs into pairs, then loop through to find the tag that matched "LastName".

In order to fix this, we needed a lightweight solution that would convert the TDP strings into something more usable... and back again once the values were modified.

Enter the TDP class. In the end, the implementation of it was almost brainless, but the elegance was in its simplicity.


public class TDP : Hashtable
{
    public string Sep1 { get; set; }
    public string Sep2 { get; set; }

    public TDP()
    {
        Sep1 = "=";
        Sep2 = "|";
    }

    public TDP (string initialString)
    {
        Sep1 = "=";
        Sep2 = "|";
        Parse (initialString);
    }

    public string ParseString
    {
        get
        {
            return ConvertToString();
        }
        set
        {
            Parse(value);
        }
    }

    private void Parse(string value)
    {
        this.Clear();
        string[] Pairs = value.Split(Sep2.ToCharArray());

        foreach (string pair in Pairs)
        {
            string[] arr = pair.Split(Sep1.ToCharArray());
            this.Add(arr[0], arr[1]);
        }
    }

    private string ConvertToString()
    {
        StringBuilder sb = new StringBuilder();

        foreach (string key in this.Keys)
        {
            sb.Append(key + Sep1 + this[key].ToString() + Sep2);
        }

        return sb.ToString();
    }

    public override string ToString()
    {
        return ParseString;
    }
}

Managing the data became nearly trivial:


class Program
{
    static void Main(string[] args)
    {
        TDP tdp = new TDP();

        tdp.ParseString = "Cheryl=Beautiful wife|Jerry=Cheryl's Husband|Time=3:00pm|";

        Console.WriteLine(tdp["Jerry"]);

        tdp["Jerry"] = "Awesome programmer";
        tdp["New tag"] = "Some new tag";

        Console.WriteLine(tdp.ToString());
    }
}

Securing the code with 'License'

noreply@blogger.com (Jerry Hanel) — Sat, 17 Jan 2009 19:47:00 +0000

Recently, I've decided to lock down some of the code at work. We've had a problem with some of our code walking out the door without our permission.

I'm not pointing fingers, but hey... we've gotta stop it from happening. Right? In the end, we need to make sure that our software checks a license file to make sure it has the rights to run.

Enter System.ComponentModel.License. This is a .NET structure for building your own licensing model. Within this setup, you can "validate" your license however you want to. My license "calls home" to make sure that it has permission to run. Or, you can check a license file on the PC. Or make the user enter a password. You can even have the thing look for a registry entry. Hey. It's up to you.

Let me show you a quick example of a license library that I've created that will require a flat file on the PC with the words "All Good". If this file exists, the license is good to go.

I know this particular example is not secure, but I wanted to keep it simple for the sake of example. In order to pull this off, we need to first create two classes that we'll use later.

MyLicense


    public class MyLicense : License
    {
        private Type type;

        public MyLicense(Type type)
        {
            // use this to get the GUID... which we will use as the LicenseKey.
            this.type = type;

           string txt = File.ReadAllText("c:\\myLicense.lic");
           if (txt != "All Good")
           {
               throw new LicenseException("Unable to validate license");
           }
        }

        public override string LicenseKey
        {
            get
            {
                // Simply return the application's GUID
                return type.GUID.ToString();
            }
        }

        // Required.
        public override void Dispose() { }
    }

MyLicenseProvider


    public class MyLicenseProvider : LicenseProvider
    {
        public override License GetLicense(LicenseContext context, Type type,
            object instance, bool allowExceptions)
        {
            // I want to catch any file errors and throw a license error instead.
            try
            {
                // Use this flag to license the runtime of your code from the 
                // development of your code.
                if (context.UsageMode == LicenseUsageMode.Runtime)
                {
                    MyLicense L = new MyLicense(type);
                    return (License)L;
                }
            }
            catch (Exception ex)
            {
                throw new LicenseException(type, instance, ex.Message);
            }

            return null;
        }
    }

With these two classes, we can now lock down our code with our simple license file. Note: The License model from Microsoft requires that it be applied to a class, not a program or static object.

Our Program


    [LicenseProvider(typeof(MyLicenseProvider))]
    public class MyClass
    {
        License Lic;

        void MyClass()
        {
            // The very first thing we're going to do is see if we 
            // have permission to be here.
            Lic = LicenseManager.Validate(typeof(MyClass), this);
        }
    }

Now, we've got the base code. But what does it do? When you create an instance of "MyClass" to be used in your code, it -- of course -- runs the constructor. The first line of the constructor is :


Lic = LicenseManager.Validate(typeof(MyClass), this);

Thanks to the pre-processor line of LicenseProvider, it knows which class to call: MyLicenseProvider. Since MyLicenseProvider is a type of LicenseProvider, the License engine in .NET knows that GetLicense exists, so it gets called, which calls an instance of "MyLicense".

NOW we get to the good stuff. Inside this license library, you can do ANYTHING. However you want to validate your license is up to you. I'm going to simply open a file, if it even exists, and see if it has the right string in it. If so, we're golden.

However, if the license process should fail or return null for any reason, the LicenseManager from the constructor in our class will throw a LicenseException and the whole thing will come to a screeching halt.

Nice, isn't it?

And now, you know the basics for locking down your code. How you choose to handle these basics for doing more in securing your code is up to you.

P.S. And for you developers... keep in mind that you can require a development license SEPARATE from your run-time license, giving you the ability to make money from your work without the fear of it growing legs and breeding like roaches in the cesspool of internet piracy.

HTML Cache Problem

noreply@blogger.com (Jerry Hanel) — Thu, 15 Jan 2009 16:23:00 +0000

I was working on the web site this morning, and I noticed a typo. "No problem!" I tell myself. I'll just hop on over and fix it. So I did.

I then went back to check my newly-corrected word. I wanted to see the work of my sheer genius. Okay... I know it's a single spelling correction, but it's the little things that make me happy. The problem was, it was still wrong.

Then it dawned on me... my browser was wrong. The website it self was right, but I was looking at a cached version. And all of you loyal readers out there would be seeing that typo all the time if you've been here before. My reputation would be ruined. Well... almost.

But being the perfectionist that I am, I still had to fix it. It is a simple fix, really. All I needed to do was add a line of meta data to my HTML page. If you have a server-side application -- such as a PHP page -- that needs to re-generate its information, or if you have JavaScript that updates frequently thanks to other services, you can use PRAGMA:NO-CACHE.

While this is not a 100% shot that the browser still won't cache your page, most of the popular borwsers (IE, Firefox, Safari, etc) obey the PRAGMA:NO-CACHE convention.


<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">

Just add that as the first line of your file and you're done. Oh, right... that is for HTML1.0 specification. What about HTML1.1? Well, there's the curve ball. An HTML1.1 site should use CACHE-CONTROL instead of PRAGMA.


<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">
<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">

Why? Who knows. Some geek in the world convinced another set of geeks somewhere that the name PRAGMA made no sense, so CACHE-CONTROL was adopted as the new standard. For safety and just to be sure, I usually add both of the tags to my site so that I know it will always load the latest version of my page.

Yes, I'm adding more work to my web server. Yes, I could use "EXPIRES" instead. But the amount I'm adding at this point is negligible, so I'm okay with that. I'll save EXPIRES for a future article. At least people will get the typo-corrected versions of the articles.

Command Line Parsing

noreply@blogger.com (Jerry Hanel) — Wed, 14 Jan 2009 14:00:00 +0000

I recently had a case where I needed to handle a series of command line arguments. I needed to know if flagA had been set with flagB, but not with flagC and flagD.

Ripping through the list of command line arguments is easy enough, but tedious, so I wrote my own CommandLine class that lets me reference flags by name. For instance, if I need to check to see if flagA exists, I can just say cmd.ContainsKey("flagA").

The best part is that it only modified my master source by one line:


CMD cmd = new CMD(args);

I thought that this little ditty -- while being trivial in concept -- was worth sharing. If you find it useful, let me know. Also, if you have comments, feel free to post them.


    public class CMD : Hashtable
    {
        public CMD(string[] args)
        {
            if (args == null) return;

            for (int x = 0; x < args.Length; x++)
            {
                if (args[x].StartsWith("-") || args[x].StartsWith("/"))
                {
                    // take off the "-"
                    string key = ((string)args[x]).Substring(1);

                    // We have a flag. Is it a TF or a value flag?
                    if ((x < args.Length - 1) && (!args[x + 1].StartsWith("-")))
                    {
                        // VALUE flag                        
                        this[key] = args[x + 1];
                        x++;
                    }
                    else
                    {
                        // True/False flag
                        this[key] = true;
                    }
                }
            }
        }
    }

Once you've defined the class, accessing the command line arguments becomes trivial. In the example below, I have a simple console application that needs command line parsing. Once CMD is initialized, I can access CMD from anywhere, and access all of my command line parameters by name.


    class Program
    {
        static CMD cmd;

        static void Main(string[] args)
        {
            cmd = new CMD(args);

            // Do some magic stuff here
        }
    }

Virtual vs. Abstract

noreply@blogger.com (Jerry Hanel) — Tue, 13 Jan 2009 16:00:00 +0000

So, I know I'm going back to Object Oriented 101, but I've forgotten how powerful certain keywords can actually be. That is, until recently.

I was asked to build a product that would be flexible enough to kiss it's own behind, but easy enough to maintain that non-programmer-types could mangle out a few lines of code to keep extending this. (i.e. engineers).

Yeah. That's what everyone wants, right? And the general answer is usually "and people in hell want water." But this time, I think I've actually found a solution to one of their issues.

Enter "VIRTUAL". It's a subtle change, but one that's Oh-so-important in this case.

Let's say we have an object called circle. That object has a method called GetRadius(). GetRadius does exactly what it sounds like. It returns the distance from the center of the circle to the edge.

Now, if we create a new object that inherits circle, let's call this one doughnut...mmmmmmmmm.... doughnuts... the term GetRadius becomes a bit more tricky. Are we talking about the inner circle or the outer circle? Lets say that we want it to be the difference between the two.

So, how do circles apply to the issue of kissing your own behind? Let me show you.

Library 1 contains our first object; Circle.


public class Circle
{
   public double diameter { get; set; }

   public Circle (double OuterD)
   {
      diameter = OuterD;
   }

   public virtual double GetRadius_Virtual()
   {
      return diamter / 2;
   }

   public abstract double GetRadius_Abstract()
   {
      return diameter / 2;
   }

}

public class CircleCollection : List<Circle>
{
}

Now, if we want to extend this library by creating new DLLs that inherit the Circle class, we can still add them to CircleCollection because they are, in fact, a type of circle. So if someone creates a new DLL called Doughnut, we might have:


public class Doughnut : Circle
{
    public double innerDiameter { get; set; }

    public Doughnut (double OuterD, double InnerD)
    {
        diameter = OuterD;
        innerDiameter = InnerD;
    }

    public override double GetRadius_Virtual()
    {
        return (diameter - innerDiameter) / 2;
    }

    public override double GetRaidus_Abstract()
    {
        return (diameter - innerDiameter) / 2;
    }
}

Since DOughnut is a type of Circle, we can add it to the previously-defined CircleCollection class with no problem.

But let's take a look at the results of the numbers. We've defined doughnut the same, whether it is abstract or virtual, but the numbers will be different depending on HOW we ask the program to reference the object... as a Circle or as a Doughnut.

When I loop through all of the elements in my CircleCollection, as Circles, we get some interesting results. Let's loop through a few and get the radius. First well get it by Virtual, then we'll get it again by abstract.


CircleCollection C = new CircleCollection();

C.Add(new Doughnut(10,8));
C.Add(new Doughnut(9:5));
C.Add(new Circle(10));
C.Add(new Circle(9));

foreach (Circle circ in C)
{
   Console.WriteLine(circ.GetRadius_Virtual() + ":" + circ.GetRadius_Abstract());
}

You would think the answer for the left number would be the same as the right, but they are different for doughnuts. The Virtual will always be whatever the deepest answer in the tree is. In this case, doughnut was the deepest in the heirarchy.

However, the abstract version will always be the answer from the requested type, in this case Circle (note: foreach circle...).


Output:
1:5   <--- doughnut
2:4.5 <--- doughnut
5:5   <--- Circle
4.5:4.5 <- Circle

The first number for each of the "doughnut" objects used the code within the doughnut class, while the second number used the code within the circle class. THAT's the difference between Abstract and Virtual.

So, back to the engineers. As long as they inherit their new objects from my base type, all my libraries (which use "virtual") can reference the items in the collection by their base type.

Since all of my base types are collections of other types (i.e. EngineeringObjectCollection) I can loop through my collections as I normally do. If they have created their own types and override the functionality of one of my methods, then I'll use their code. If not, I'll use mine. No extra coding on my part is required. No messy reflection. No fuss, no muss.

And just like that, the code can now kiss it's own behind... well, provided the engineers can access the "clsBehind" object with the prgObject.Kiss() method. But you get the idea.

Now, all this talk about doughnuts has made me hungry.

Javascript getElementsById()

noreply@blogger.com (Jerry Hanel) — Mon, 12 Jan 2009 15:14:00 +0000

Okay... I know the moment I post this, I'm going to get a million messages that an ID is supposed to be unique to the page, thus there should never be more than one. Thus, "Get ElementS By Id" is a misnomer. There is no such thing. You can only "Get ELEMENT By Id."

In a perfect world, you would be absolutely correct. But JavaScript is far from perfect, especially when you add in cross-browser dependencies.

I ended up with a control that generated HTML for me, which was very nice. Unfortunately (as I always tend to do) I wanted to fiddle with the output to make it just like I wanted it. Change a font here. An alignment there. Add some text to the top of each block. Set a margin. Put some padding on it so it doesn't blend into other text... you know. The usual stuff.

I could have solved most of this with CSS, but I needed to add some javascript (one line per block) to manage some of the data in it. *IF* I could get a handle to each DIV, I could assign a proper ID to it so that it would be unique, thus I could reference it later with a simpler JavaScript function.

But the code that was generated didn't give me any clean way of deciphering its DIVs from any other DIV in the form. The code that was generated looked similar to the following:


<DIV ID='Block'>
   <DIV ID=INNER>Do some nifty stuff in block 1.</DIV>
</DIV>

Now this isn't the extent of it, but you get the idea for the purposes of this demonstration. The important part here is that I don't have a name. All I have is an ID. And Javascript doesn't allow for document.getElementsById(...)

So I wrote my own.


function getElementsById(id)
{
   var divs = document.getElementsByTagName("div");
   var arr = new Array();
   
   for (var i=0; i < divs.length; i++)
   {
      if (divs[i].id == id)
      {
         arr[arr.length] = divs[i];
      }
   }

   return arr;
}

This gave me exactly what I was looking for, works well in both IE and FireFox (I haven't tried Opera or Safari. Sorry.) and I could then loop through the returned elements and assign a proper "ID" to it so that it would fit into the nice perfect world that we've all come to expect and love.

More File Permissions

noreply@blogger.com (Jerry Hanel) — Sat, 10 Jan 2009 16:00:00 +0000

In doing more research with file permissions, I've found that MS shares file permissions and directory permissions. (if you dig into the enums enough, you'll see duplicate values for multiple enum settings)

I thought this was odd until I realized why. The FileSystemRights enum contains values for both FILES and DIRECTORIES. So, ListDirectory for directory access is the same flag as ReadData for file access.

This may seem trivial until you want to list the contents of a directory, but not actually allow a person to view the file... which is exactly what my boss asked me to do.

"Easy!" I said as I jumped to my desk. Until I discovered that -- for reasons unknown to me -- we must use file inheritance.

So when the file inherits "ListDirectory" from it's containing folder... it is, in fact, inheriting the "ReadData" flag for the file.

In short: If you use file inheritance, and you specify ListDirectory, you cannot make the file ReadOnly without going to the file and explicitly denying ReadData for a user. (UGH!)

Rounding errors...

noreply@blogger.com (Jerry Hanel) — Fri, 09 Jan 2009 16:55:00 +0000

This week, my life has been plagued with rounding errors. I have a library that converts to/from different units of measure. This library is used within several objects with the idea to store distances in memory all in meters. Then, if the user wants to see that measurement in feet, or inches, or miles, or kilometers... you get the idea.

Here's my problem... Some calculations need to be done in feet. Others in inches. With this nice, neat, creative library, this should be EASY... right?

I couldn't have been more wrong.

The library uses the following units for conversion from meters to feet and inches. Keep in mind that I'm keeping all units in meters in memory.


double ft = meter / 0.3048;
double inch = meter / .0254;

To keep it in meters in memory, when the user inputs a number, I have to convert that number from its respective distance into meters. I use the following conversions for that.


// if given inches
double meter = inch * 0.0254;

// if given feet
double meter = ft * 0.3048;

Since it's divide for one, and multiply to put it back, it should come out the same... right? WRONG!

Take a look at an input of 220 feet:


// Store the value in memory...
double meter = Convert.ToMeter(220); // 67.056

// convert that back into "feet" for display.
double ft = Convert.ToFeet(meter); // 219.99999999999997

That's right. 67.056 / 0.3048 rounds to 219.9999999... NOT 220. Keep in mind that 67.056 isn't a rounded number itself. That's the actual, complete number for 220 * 0.3048.

In my calculations, I then tried to say "if (Feet entered by user) == (Feet previously entered by user) then go do some stuff" and it never would.

Here's the magic bullet for this issue: First, determine how many significant digits you care about. For most of my calculations, 8 digits is absolute overkill. So, for cases like this, I will use 8 as my cutoff.

My conversion class now has a property called "SignificantDigits" that defaults to 8. Inside my conversion routines, before I return the value, I round the value to the significant digits. So far, that's been working very well for me.


// Forcibly round to 8 significant digits to prevent arbitrary rounding errors.
double ft = Math.Round(meter / 0.3048, SignificantDigits);
double inch = Math.Round(meter / .0254, SignificantDigits);

For those needing a very accurate number, you'll have to set the significant digits count so high that this approach will not be feasible. But for the average Joe making the average calculations, this is a quick fix.

C# File/Directory Permissions

noreply@blogger.com (Jerry Hanel) — Thu, 08 Jan 2009 16:50:00 +0000

Today's code problem comes from my real-world experience. I was working on an app to help manage file-rights here at my job.

The frustrating part was that it looked so simple. The default code from Microsoft shows that this is almost trivial:


// Get the directory security object.
DirectorySecurity dSecurity = Directory.GetAccessControl(dirName);

// change the rights on the object.
dSecurity.AddAccessRule(new FileSystemAccessRule(account, 
    rights, controlType));

// Set the new access settings.
Directory.SetAccessControl(dirName, dSecurity);

But when you do it this way, you can no longer see the checkmarks in the default security tab. You have to go into "Advanced" to see your permissions.

Why?

Because doing it this way sets all of your permissions as "special" permissions, not any of the default standard permissions. Note that your file permissions are set properly. The rights really are set. You just can't see the nice little check marks in windows.

I did some research to set the ACE (Access Control Entry) so that the checkmarks would re-appear, and found the following snippet of code:


dSecurity.AddAccessRule(new FileSystemAccessRule(
                            IdentityReference, FileSystemRights, 
                            InheritanceFlags.ContainerInherit |
                            InheritanceFlags.ObjectInherit, 
                            PropagationFlags.None,
                            AccessControlType));

So if I just do this after I set the new security the magic little checkboxes will reappear, right? YES! They did. But then all of the checkboxes for all OTHER users of that file or directory went away!!!

(*sigh*)

So, after doing some research, testing and playing, I've found a hack that will re-set the nice little checkboxes in the security tab. It's ugly. It's painful. But it works.... mostly. (more on that in just a second.)



DirectorySecurity dSecurity = Directory.GetAccessControl(dirName);

// change the rights on the object.
dSecurity.AddAccessRule(new FileSystemAccessRule(account, 
    rights, controlType));

// Call my Bug-Fix routine
MSBugFix(dSecurity);

// Set the new access settings.
Directory.SetAccessControl(dirName, dSecurity);


...


private void MSBugFix(DirectorySecurity dSecurity)
{
    // RESET EVERYONE'S ACE So that it will view properly 
    // in the Security tab. (MS BUG FIX!!)
    AuthorizationRuleCollection acl = dSecurity.GetAccessRules(
        true, true,  typeof(System.Security.Principal.NTAccount));

    foreach (FileSystemAccessRule ace in acl)
    {
            dSecurity.AddAccessRule(new FileSystemAccessRule(
                ace.IdentityReference, ace.FileSystemRights, 
                InheritanceFlags.ContainerInherit | 
                InheritanceFlags.ObjectInherit, 
                PropagationFlags.None, ace.AccessControlType));
    }
}

This works, but can be a bit slower if you have many files to do. Gee... I wonder why? Oh.. right. The nasty ALL USERS loop in there. But it does work.... until you install Service Patch 3 on the machine.

When you install Service Pack 3, the nice little checkboxes go away again. Note that your permissions and access to the files remain. You can still get to your files, you just have to go to "Advanced" to see the actual settings on your files.

If anyone has an actual fix for this issue, (not the ugly hack I had to develop) I would love to hear it. Until then, we just won't be installing SP3.