Erik Porter's Blog

ControlArray

Today, I uploaded my new ControlArray Component on GotDotNet.

Description

The ControlArray is a Component that allows you to logically group Controls on a Form so you can capture all common Events for each Control and also be able to set the same Property on all Controls with one line of code.  It supports all Events and all appropriate Properties of the System.Windows.Forms.Control.  It also has Methods (InvokeMethod and SetProperty) to call Methods and set Properties that don't exist in the ControlArray already without having to use Reflection.

The ControlArray is a good demonstration on design time support in Visual Studio .NET, including right mouse click support to add/remove Controls to/from a ControlArray on the Form designer surface, a custom UITypeEditor and also demonstrations how to use IMenuCommandService, ISelectionService, DesignerVerbs and Shadow Properties.

If you have used Visual Basic 6 and miss ControlArrays (since they don't exist in WindowsForms), then you'll definitely enjoy using this Component as it works very similarly.  Even if you never used VB6, you will probably find a use for it to save you some coding.  It's great for Data Entry Forms or any Form where you need to edit the state of many Controls at runtime.

The ControlArray comes with two version of the source code that works with Visual Studio .NET 2002 & 2003 on .NET 1.0 and .NET 1.1.  It also comes with a sample that will demonstrate how to use it in both VB.NET and C#.  The actual ControlArray Component, however, is written in VB.NET.

If you're interested, download it now!

I'd also like to thank Jacob Grass and Ken Getz for their help!

What's really funny is that on the User Samples page on GDN right now, it says this:

ControlArray
Uploaded by mybutt

There's just something wrong about that!  ;)

MSN Messenger 6

Neowin.net has posted some screen shots

I know I'll be in heaven when this thing comes out.  Custom Emoticons, XML Logging *explodes and dies*

Declaratively Tagged UI

Don posted, building and explaining in much more detail on some of the thoughts that I've been having, that seem to be extremely similar to SVG and LongHorn.  This is all really cool and great new stuff to look forward to if you ask me, however, I want to make these opinions of mine extremely clear as I think they are very, very important points.

Will the underlying architecture and all things related change drastically?

More than likely and for the better!

Will everything change the developer's standpoint?

I hope to god not and I hope (and I'm sure) they (Microsoft) are making it so from the end developer's standpoint there's not much of a different from how we "design forms" today.

Let me explain what I mean.  From what Don talked about, it sounds like designing forms, will end up more like it is in ASP.NET where you have a design view and an html view and you can tweak the UI from the html view to your hearts content.  Today, design forms in WindowsForms is much, much easier as there's no "html view" for your form and i personally consider that to be a great thing and is what makes WindowsForms so much easier to create!

Now, I'm totally down with what Don is talking about.  It's like HTML on Steroids as a flavor of XML...but without the HTML (which is a good thing).  However, being able to actually mess with that stuff yourself opens up so many possiblities for problems (as it does with HTML currently) and IMHO shouldn't even be part of the VS.NET development process.  Why would it need to be?  In this "perfect for UI" flavor of XML, there should be absolutely no need to mess with it by hand.  The designer should do everything for you (and of course allow you to open up the XML representation in a more "hidden" way for emergencies).  Most people mind find that this comment ridiculous, but that's because you're probably used to HTML and would die if you didn't have the ability to edit it yourself.  Just remember, this won't really be anything like HTML.  It won't have all the problems and workaround crap that HTML has, which is always the reason why you have to edit it yourself.

So hands down, I believe that declarative UI is totally cool and absolutely fantastic with all of its possibilities, but I also believe it should be something that isn't IN YOUR FACE.  It should be done by the WindowsForms designers.

Thoughts?  Comments?

Document Your Life

Interesting article on ZDNet about a wearable camera by HP

I've been thinking about this sort of thing ever since I watched Thundercats as a kid.  Anybody else remember that show?  ;)  I grew up on Thundercats, G.I. Joe & Voltron!

There was an episode where these little balls would follow them around all day and night, recording absolutely everything.  Thought it was the greatest idea ever and scary all at once!  I've obviously been a tech geek since birth as I was probably only 8 or 9 when I watched that episode.

It's good to see technology catching up with what used to be fantasy!

Serializing UI Thoughts and Code Experiments

I was reading through some posts on various Microsoft Forums last night and I came across a few different people asking about being able to persist the contents of a TreeView to an Xml file (apparently other packages have this feature, like Java or something like that).  Can't say I've ever had a need for that (although I have persisted tree structured data to databases...that's pretty fun, actually), but it seemed interesting enough that I thought I'd give it a try.

I started creating a custom TreeView Control, but as I went along, I was thinking, why should I come up with some custom hardcoded way to persist the Nodes Collection to Xml?  Why not just use Reflection to grab all the Properties and what not using recursion?  Sounds good, so I start coding.  However, I don't need to persist every single property.  How could I decide which ones need to be persisted and which ones don't?  Then I remember all the work I've been doing with the WindowsForms Designer stuff lately and was thinking, "man, why not use the TypeDescriptor?  It already knows which Properties should be persisted, etc".  So great, I throw that into the mix!  Then I start wondering though.  Why don't I make this a little more universal and actually persist entire controls?  So I get it working with persisting every property that needs to be persisted in the entire TreeView.  Here's the following code I came up with (it's pretty crude and needs cleaned up, so be nice  ;)):

Private Sub RefreshXml()
     With _XmlDoc
          .RemoveAll()
          .AppendChild(.CreateElement("TreeView"))
          For Each PD As PropertyDescriptor In TypeDescriptor.GetProperties(Me)
               If PD.SerializationVisibility <> DesignerSerializationVisibility.Hidden AndAlso PD.ShouldSerializeValue(Me) AndAlso PD.Name <> "XmlDoc" Then
                    SerializeChildObjects(_XmlDoc, .FirstChild, Me, PD)
               End If
          Next
     End With
End Sub

Private Sub SerializeChildObjects(ByVal XmlDoc As XmlDocument, ByRef Node As XmlNode, ByVal Component As Object, ByVal PD As PropertyDescriptor)
     Dim ChildProperties As PropertyDescriptorCollection = PD.GetChildProperties

     If PD.PropertyType Is GetType(String) OrElse PD.PropertyType Is GetType(Color) OrElse ChildProperties.Count = 0 Then
          Dim Value As Object = PD.GetValue(Component)

          If PD.PropertyType Is GetType(String) AndAlso DirectCast(Value, String) = "" Then
               Exit Sub
          End If

          If PD.PropertyType Is GetType(Color) AndAlso DirectCast(Value, Color).IsEmpty Then
               Exit Sub
          End If

          Node.AppendChild(XmlDoc.CreateElement(PD.Name)).AppendChild(XmlDoc.CreateTextNode(Value.ToString))
     Else
          Dim NewNode As XmlNode = Node.AppendChild(XmlDoc.CreateElement(PD.Name))

          If Not Component Is Nothing Then
               NewNode.Attributes.Append(XmlDoc.CreateAttribute("Type")).Value = PD.PropertyType.Name
          End If

          If IsCollection(PD.PropertyType) Then
               If DirectCast(PD.GetValue(Component), ICollection).Count > 0 Then
                    Dim NewNewNode As XmlNode = NewNode.AppendChild(XmlDoc.CreateElement(PD.PropertyType.Name))

                    For Each Item As Object In DirectCast(PD.GetValue(Component), ICollection)
                         Dim NewNewNewNode As XmlNode = NewNewNode.AppendChild(XmlDoc.CreateElement(Item.GetType().Name))

                         For Each NewPD As PropertyDescriptor In TypeDescriptor.GetProperties(Item)
                              If NewPD.SerializationVisibility <> DesignerSerializationVisibility.Hidden AndAlso (NewPD.ShouldSerializeValue(Item) OrElse IsCollection(NewPD.PropertyType)) Then
                                   SerializeChildObjects(XmlDoc, NewNewNewNode, Item, NewPD)
                              End If
                         Next
                    Next
               End If
          End If

          For Each NewPD As PropertyDescriptor In ChildProperties
               If Not NewPD.IsReadOnly Then
                    SerializeChildObjects(XmlDoc, NewNode, PD.GetValue(Component), NewPD)
               End If
          Next

          If NewNode.ChildNodes.Count = 0 Then
               Node.RemoveChild(NewNode)
          End If
     End If
End Sub

Private Function IsCollection(ByVal Item As Type) As Boolean
     Return Not Item.GetInterface("IList") Is Nothing AndAlso Not Item.GetInterface("ICollection") Is Nothing
End Function

After that (unfortunately too late), it hit me.  WebServices already do this sort of thing for object serialization.  I'm sure most of this could be replaces by some already existing stuff.  In comes Matt Powell to the rescue!

But then of course, my mind starts going crazy with possibilities.  Why not do this for entire forms?  For entire Projects (and Solutions).  Why not make a plug-in.  Then the practical me comes in and says, "but what's all this for?  how can you make it practical?"  Not much has come to mind yet on that.  However, a few thoughts and ideas have.

Maybe this sort of thing could be used for some sort of super detailed documentation or code examples.  Just apply some XSL and get a nice page of code, etc.

Then I started thinking about some of the things I've been hearing about LongHorn.  Some possibilities of declaring your WindowsForms UI with tags, more like ASP.NET and wondering if what I was messing around with is related.  Could I clean up my code into a "UISerializer" or something like that?

Then, yet again, my brain kicks in and says "slow down...what would anybody use this for?"  At that point, I decided it was time for bed (6:00 AM  :P)

So now I'm curious.  Is there anything of use in what I've been messing around with?  If you have any additional ideas or thoughts on this subject, I'd love to hear about them, or maybe even see a related blog entry.  If you happen to find some use out the posted code, let me know too!  :)

/me needs a whiteboard badly!

Drawing and Dragging in WindowsForms

Jacob Grass, a fellow MVP recently posted a neato little snippet of code for dragging only the outline of a form!

Check it out!

Look ma, I'm famous...Flash.NET

If you check out this book on the UK Amazon site, you'll see my name on it!  Woohoo!  If you find this same book on the US Amazon site, you won't see my name on it!  :(

Originally I had written a case study (not even a whole chapter) for the book that was about 60 pages long.  It basically walked you through setting up an admin section for your site that could administer all the users, by passing user objects to and from flash to and from a .NET WebService.  I thought it was pretty decent, but after the second round of editing they said it had been canned along with a couple other chapters, because the book was too huge and they were already over budget (this is Friends of Ed, mind you, a sister company to the now dead, Wrox  ;)).  So I got paid and was never allowed to send out my chapter anywhere...what a bummer!

Anywho, I've talked with a bunch of people about the book and it seems to be a pretty good one.  Flash Remoting, which is what a large chunk of the book is about, is a nice little service that sits on your web server and handles web service requests for you (since flash can't handle them natively) and transforms any results from the webservice into native actionscript objects.  It's really neato and if you're into Flash and WebServices, it's a great way to use them together, so you can have yet another UI on top of your WebServices.  DonXML would probably kill me for saying this, but one of the reasons it's so great is because you never have to touch any XML!  ;)

Again, as I mentioned before, I am a moderator for the Flash Remoting section of one of the bigger online flash communities out there, We're Here.  So drop on by if you have any questions about it!

We're Here Forums

After a many month hiatus, We're Here Forums is back (as of this morning).  We're Here is one of the first forums I ever visited and is full of many interesting and intelligent people.

I was (and still am) a moderator for the XML section of the forum and was newly appointed as a moderator for the Flash Remoting section.  If you have any questions regarding how to consume .NET WebServices and other Flash Remoting questions, feel free to post them in the Remoting section and I (and others) will do our best to answer them.

I've created a few applications using Flash Remoting and I must say it's actually pretty powerful.  If you're using .NET WebServices and Flash, you can actually pass objects back and forth between Flash and your WebService without ever touching any XML.

LongHorn Yumminess and .NET Questions

Ok, David pointed out a very good article on LongHorn and everytime I see more of what it can do I'm just that much more amazed and totally pumped for it!

One question that's always on my mind though is how is .NET all mixed up in this?  Are LongHorn programmers using managed code for some of this really cool stuff or are they still using all unmanaged code?  And also, what will LongHorn bring to the .NET table for you and me as developers?

LongHorn delay...Whidbey delay?