asp.net hates < script />

I just discovered an unfortunate bug(?) in asp.net.

With:

< source="scriptfile.js">

My page always generates an Event Validation exception on postback.
Simply changing it to:

< source="scriptfile.js"> <>

eliminates the exception without having to disable Event Validation

Just discovered wcsf...

Relative to xsd.exe, WCSF is vastly superior.

It generates reasonable names

It uses generics.

It has a user interface.

One problem...

constructs using choice like this

  < xs:element name="Amount">
    < xs:complexType>
      < xs:choice>
        < xs:element ref="MassAmount"/>
        < xs:element ref="VolumeAmount"/>
      </xs:choice>
    </xs:complexType>
  </xs:element>

generate crappy C# code like this:

       [System.Xml.Serialization.XmlElementAttribute("MassAmount", typeof(MassAmount))]
       [System.Xml.Serialization.XmlElementAttribute("VolumeAmount", typeof(VolumeAmount))]
       public object Item
       {
           get
           {
               return this.item;
           }
           set
           {
               if ((this.item != value))
               {
                   this.item = value;
               }
           }
       }

Why couldn't that just allow setting one or the other enum?

GetActiveIter

There is no GetActiveIter method in the TreeView class.

I view this as inconsistent.  Both ComboBoxes and TreeViews can handle muliple selections, they should have similar interfaces.

Workaround:

You must use  .Selection.GetSelected(Out iter) instead.

Gtk# annoyances

I've kept some notes as I learned Gtk# . In the next few postings I'll comment on what features have annoyed me and how I dealt with them.

Use of "out" parameters for varous methods.

Eg: The GetActiveIter of the ComboBox classes use an Out paramter instead of just returning the iter.

I'm annoyed by this because I don't want to have to instantiate a variable when I just need  the current iter for a moment.

I've heard the argument that by returning a bool indicating success or failure you can save some checking effort, but I think returning null on failure would be just as good.

Workaround:

Obviously, you just declare a variable to store the active iter.