Category: Uncategorized

Boo and WPF

~ chriseyre2000 ~ Leave a comment
Here is an example of Boo and WPF.
I am not claiming that it is origonal since it was cribbed from someone elses site.
However this version is not broken and does have a build script.

The following is wpdemo.boo:

namespace Boo.WinFx
import System
import System.Windows
import System.Windows.Controls
import System.Windows.Navigation

[STAThread]
def Main():
    # create a window host
    win = NavigationWindow()   
    # create a textblock
    para = TextBlock(Text:”Hello World!!!”, FontSize:36)
    para.VerticalAlignment = VerticalAlignment.Center
    para.HorizontalAlignment =HorizontalAlignment.Center   
    # create a button
    button = Button(Content:”Click Me”, Height:30, Width:100)
    # display the textblock when the button is clicked
    button.Click += { win.Navigate(para) }
    # display the button first
    win.Navigate(button)
    # create an application host
    app = Application()
    # show the window
    win.Show()
    # fire the application
    app.Run()

The following is default.build:

<?xml version=”1.0″ ?>

<project name=”wpfdemo” default=”build”>
<property name=”boo.dir” value=”C:/boo/bin” />
    <target name=”build” depends=”wpfdemo” />
    <target name=”wpfdemo”>
        <loadtasks assembly=”${boo.dir}/Boo.NAnt.Tasks.dll” />
                 <booc output=”wpfdemo.exe” target=”winexe”>
            <references>
                <include name=”C:/Program Files/Reference Assemblies/Microsoft/Framework/v3.0/*.dll” />
            </references>
            <sources>
                <include name=”wpfdemo.boo” />
            </sources>
        </booc>
    </target>
</project>

Boo and WF

~ chriseyre2000 ~ Leave a comment
This is based upon an example that has been floating around the blogs.
I have removed the Python accent from it (hint you don’t need to use self in a Boo class):

The following is wf.boo

import System.Workflow.Activities
import System.Workflow.Runtime
import System
class MyWorkflow(SequentialWorkflowActivity):
_codeActivity as CodeActivity
def constructor():
super()
_codeActivity = CodeActivity()
_codeActivity.ExecuteCode += SayHello
_codeActivity.Name = “Hello”
Activities.Add(_codeActivity)
def SayHello(sender, args):
print “Hello”

def Started(sender as object, args as EventArgs):
print “Startedn”
def Completed(sender as object, args as EventArgs):
print “Completed”

tf = MyWorkflow()
rt = WorkflowRuntime()
rt.WorkflowStarted += Started
rt.WorkflowCompleted += Completed
type = tf.GetType()
instance = rt.CreateWorkflow(type)
instance.Start()
Console.ReadKey()

The following is default.build:

<?xml version=”1.0″ ?>

<project name=”wpfdemo” default=”build”>
<property name=”boo.dir” value=”C:/boo/bin” />
<target name=”build” depends=”wpfdemo” />
    <target name=”wpfdemo”>
        <loadtasks assembly=”${boo.dir}/Boo.NAnt.Tasks.dll” />
            <booc output=”wf.exe” target=”exe”>
                <sources>
                    <include name=”wf.boo” />
                </sources>
            </booc>
    </target>
</project>

Why I like Boo

~ chriseyre2000 ~ Leave a comment
Boo is a very simple programming language.

I am not sure that I would use it in a production application for fear of the maintenance problems (where do you get Boo programmers from?).

Things that I particularly like are:

Booish – being able to interactively play with practacally any .NET class without the need for a heavyweight IDE to be open.

The fact that you can post the source code to a blog like this without messing up the formatting!

I am planning a series of topics on Boo and the .NET 3 Pillars:

  • WF – windows workflow
  • WPF – windows presentation foundation
  • WCF – windows communication framework

At first I will be using Boo plus Nant but may need to stray into MSBuild.

Domain Specific Languages and XML

~ chriseyre2000 ~ Leave a comment
There has been a lot of thinking about the use of Domain Specific Languages to solve a particular problem.
This is even a major feature of Visual Studio 2005 and above.

Typically these are things like Ruby on Rails which is essentially a DSL for creating dynamic websites quickly.

However there is a much simpler solution.
State your problem in XML and use xslt to generate the solution.
If done carefully you can eliminate a lot of easy to write, but easy to get wrong code.

This is really what Kathleen Dollard has been talking about in her Code Generation in .net book.

Here is an example that almost all applications have to deal with:

How much work is it to add another maintenance screen to the system?
or even
How much work is it to add one field to one maintenance screen?

If you get the principle working for one screen you can add another by adding a few lines to an xml document and regenerating the script.

Boo Generic Support

~ chriseyre2000 ~ Leave a comment
The following blog listed generic support details for boo: link

states that generic type definitions in Boo are handled thus:

 MyType of MyGenericParam

or for multiple generic parameters

MyType[of X,Y,Z]

I find Boo to be a great exerimentation language, ideal for turning a class into a commandline tool.

wmi in boo

~ chriseyre2000 ~ Leave a comment
# The following is a very simple example of using wmi from boo
import System
import System.Collections
import System.Data
import Boo.Lang
import System.Management
import System.Windows.Forms

class WmiApp:
    _tb as TextBox
    _dgv as DataGridView
    [STAThread]
    def Run():
        f = Form(Text: “Hello, boo!”)
        _tb = TextBox(Text: “SELECT * FROM Win32_Service”, Dock: DockStyle.Top)
        _dgv = DataGridView(Dock: DockStyle.Fill)
        b = Button(Text: “Click Me!”, Dock: DockStyle.Top)
        b.Click += ButtonClick
        f.Controls.Add(_dgv)
        f.Controls.Add(b)
        f.Controls.Add(_tb)

        Application.Run(f)
    def ButtonClick(args, sender):
        WMIQuery(_tb.Text)
    def WMIQuery(query as string):
        qry = SelectQuery(query)
        ds = DataSet()
        table = ds.Tables.Add(“WMI”)
        mos = ManagementObjectSearcher(qry)
        loaded = false
        moc as ManagementObjectCollection
        moc = mos.Get()
        for prop as PropertyData in (array(moc)[0] as ManagementObject).Properties:
            table.Columns.Add(prop.Name)
        moa = array(moc)
        mo as ManagementObject
        for i in range(0, moc.Count):
            mo = moa[i]
            row = table.NewRow()
            for prop as PropertyData in mo.Properties:
                row[prop.Name] = prop.Value
            table.Rows.Add(row)

        _dgv.DataSource = table

WmiApp().Run()

VB 6 is trying too hard to be helpful

~ chriseyre2000 ~ Leave a comment
I have had the dubious pleasure recently of maintaining a VB6 Application.
The fun part is how helpful it tries to be in the background.
VB6 goes out of it’s way to hide any technical details from the user.

For example the app uses access as it’s reporting suite.  To call access it uses the COM API’s.
Our set up is odd in that we need an application that supports both Acesss 2000 and Access 2003.
For various reasons my dev machine has been upgraded to 2003.  I changed the reference to point to the new typelibrary and checked the code into our version control software.  I can now no longer point to the access 2000 olb and rebuild the exe – the two are just not compatible.  SO I get a colleage who still has Access 2000 to pull the code from version control.  As soon as he opens the app in VB6 it has automatically fixed up the OLB back to the Access 2003 version.  How the hell are we meant to control which version is released?  I guess my friend is now buildmaster!

I oftern wondered why the VB project file had to be writeable every time we pulled it from version control.  Apparently it updates the paths to any com objects to record those on the machine.  Someone needs to explain to people that is why we had COM in the first place…