Fernando Machado Píriz's Blog

Posts about digital transformation, enterprise architecture and related topics

Archive for August 2010

First look to the Microsoft Visual Studio LightSwitch beta

with 7 comments

A new member of the developers’ tools family has been announced earlier this month and the first beta will be available soon for download: Microsoft Visual Studio LightSwitch.

What it is and what it is for?

With LightSwitch we can easily and quickly create business applications from the scratch, including not only the application user interface forms, but also the application database; you can also create applications from existing databases.

In this article I will provide an overview of LightSwitch using the beta version soon to be available. The project I will create is a simple application to record the books I loan to my friends.

A new LightSwitch application starts by creating a new Visual Studio project. A LightSwitch project will contain application’s data and forms definitions. By using these definitions LightSwitch generates a SQL Server database and the source code in C# or Visual Basic.

In this article I will use a C# project template. Here you can see the familiar Visual Studio new project dialog box, with the two templates provided by LightSwitch.

image

Once the project is created we can connect to an existing data source or create a new data definition for the application. In this post I will show how to create data definitions from the scratch.

image

The first thing to do is to define how book entities are. I am interested in each book’s author and title. Then we create an entity Book, with Author and Title fields, both of type String and both required. These entities will be stored in a Books table.

image

Then a definition for loans is created. From each loan I am interested in knowing to whom I loaned the book, when the book was loaned, and when it was returned. Then we create a second entity called Loan, with fields ToFriend, DateLoaned and DateReturned; the first field is of type String and the two other are of type Date; the first two fields are required, but the latest is not. These entities will be stored in the Loans table.

image

Now a new relationship between books and loans is defined.

image

See below how the definition of the entity Loan and its relationship with Book looks:

image

Now we need to define the forms to edit these entities. Many different form templates are available -allowing one record to be edited at a time, multiple records in a grid, etc. I will use a template for a simple record insertion.

image

The form definition created by the wizard can be modified. I have changed only the name to display and the description of the form.

image

Once the form definition is finished, we can test the application. This LightSwitch version allows creating the following application types:

image

When the build is started LightSwitch:

  • Creates the database
  • Generates the source code
  • Compiles the application

A LightSwitch application is typically a three tier application, using certain specific technologies for each tier:

In this article you can find more information about the architecture of a LightSwitch application.

When a LightSwitch application gets executed:

  • A local web server is started
  • The application is deployed on this web server
  • The application is started

That is what we see:

image

Let us complete the fields to add the first book:

image

The application automatically assigns a new identifier to the first book.

image

Out of the box, the application already has some simple validations, like the one corresponding to the fields marked as required.

image

image

image

The second form is to insert loans. This is also a simple new record form. We can see how LightSwitch assigns a Date Picker control to the DateLoaned and DateReturned fields, of type Date. It also assigned a Modal Window Picker control to edit the association between a Loan and a Book.

image

When we run the application we can see how the controls assigned to Date fields looks:

image

The Modal Window Picker control allows searching and selecting a book to be associated with a loan. The control includes not only the search features, but also allows paging results.

image

Although this way to edit loans is not so bad, I would prefer to see the list of books, and from there to easily access each book’s loans, and eventually adding new books in the same place. The template for this kind of editing form is called List and Details Screen. Look how LightSwitch allows indicating if books’ and loans’ details should be included on the form.

image

Once the form is created, we can edit its definition. Like in previous cases, I only slightly change the name to display and add a description.

image

We can see how the new form looks when running the application. The list of books appears on the left. From there we can add, modify, and delete books. For the book selected in the list on the left, we can see the loans in the right. From there we can also add, modify, and delete loans.

image

Be aware that for adding and modifying books and loans, LightSwitch automatically generated a form with the same controls defined in their respective new record forms.

image

image

These forms have also the default behavior for validating the rules defined in the entities.

image

When more than one record is changed in a list, modifications are not sent to the database until the list is saved by using the Save button.

image

How much time takes this application to be created? Not too much, as you can see in this video:

 

You can download the video from here.

Okay, but what kind of applications is LightSwitch for? Perhaps we need to wait for a while to see who really takes advantage of this new technology. Simple applications like the one I created in this post can be created really quickly, but we all know that real world applications are not as easy to build as the ones I have demoed, are they? For non-professional or occasional developers –for whom other technologies like Microsoft Access or Visual FoxPro was created in the past-, LightSwitch can be their new preferred tool. Professional developer will probably not be able to build 100% of the complex business applications they create today by using LightSwitch, but at least they can use LightSwitch as a tool for rapid prototyping.

In certain places in the application definition we can write C# code to add functions not provided by LightSwitch -for business rules for example. But then we need to know the object model of the code generated by LightSwitch, to be able to consume from our own handwritten code the types automatically generated by LightSwitch.

Some of the templates seem to be extensible –this beta version includes templates lists with just an element, but probably it is because it is a beta. Furthermore, it seems that LightSwitch will be able to create applications for Windows Azure also. Since all the code and the database are generated from definitions, the same application could be migrated from the desktop to the cloud just by changing a setting in the project properties page.

With an object model easy to be consumed in extension points and a strong ecosystem augmenting LightSwitch capabilities, it looks like we will be able to use it to develop applications more complex than the one created here. It is too soon yet, time will tell.

Advertisements

Written by fernandomachadopiriz

August 20, 2010 at 12:50 am

Give me a handle and I will move the Earth

with one comment

image

This post’s title paraphrases a saying attributed to Archimedes, who is said to have remarked of lever “Give me a place to stand on, and I will move the Earth”.

For people like me who started developing Windows applications a long time ago, handles were the entry door to almost any resource through Win32 API. Do you want to close or minimize a window? You need that window handle. Do you want to write some text into a window client area? You need the font handle, the device context handle, and the window handle. And so on.

Fortunately, in actual .NET Framework times, almost no one cares about using handles, nor cares about knowing what they are. The .NET Framework hides the complexity of handling Windows resources through the Win32 API, and with that, it also hides the handles.

However, once in a while, there appear some problems for which the only solution is to get a handle. Here is an example.

One of the features of the Giving a Presentation demo application is the ability to hide desktop icons during a presentation, showing them back again when the presentation ends. While developing thsi feature, I unsuccessfully searched for a way to do that. As far as I could found, there is no public API function to do it; and most hacks available on the web -for example this one– use handles and Win32 API function calls, but does not work correctly: they disable the entire desktop, not only its icons; as a consequence, the desktop’s pop up menu disappears.

Speaking about desktop’s popup menu, what I needed was a feature like the one in the Show desktop icons command.

image

Then it was when the old knowledge about handles and the like became useful again. I knew that this command ended sooner or later being transformed into a WM_COMMAND sent to the desktop. What I needed to emulate this behavior was to know the arguments of the WM_COMMAND message and –as you can imagine- the desktop handle. Once I get this information, I could send the same WM_COMMAND to the desktop. The desktop would not distinguish between a message sent by the menu command or by my program, so it should handle it in the same way.

For both two things I used an old tool still included in Visual Studio installation: Spy++. This tool allow finding a particular window, and among other things, look at the messages it receives. The following picture show the Spy++ windows list node corresponding to the desktop. Please note that desktop is a window of the SHELLDLL_DefView class; we will see later how this information is used.

clip_image003

The following image shows the messages received by this window when command Show desktop icons is executed. Please not the command ID 29698 of the WM_COMMAND message; we will also see later how to use this information.

clip_image004

The function to hide or show desktop icons finally gets something like this:

/// <summary>
/// Toggles desktop icons visibility by sending a low level command to desktop window in the same way as the popup menu "Show desktop  
/// icons" does. Use <code>AreDesktopIconsVisible</code> to get current desktop icons visibility status.  
/// </summary>  
private static void ToggleDesktopIconsVisibility()  
{  
    IntPtr defaultViewHandle = FindShellWindow();
    UIntPtr resultArgument; 
    IntPtr returnValue = NativeMethods.SendMessageTimeout(  
        defaultViewHandle,  
        NativeMethods.WM_COMMAND,  
        new IntPtr(29698),  
        IntPtr.Zero,  
        NativeMethods.SendMessageTimeoutFlags.SMTO_ABORTIFHUNG,  
        1000,   
       out resultArgument);
} 

The NativeMethods class contains all the functions and constants imported from Win32 API; code is not shown here due to simplicity, but you can download it from CodePlex. The function SendMessageTimeout is used to send the WM_COMMAND with ID 29698 to the window whose handle was obtained with the FindShellWindow function.

On the other side, the FindShellWindow function finds and returns the desktop handle, strictlyspeaking, the handle to the window containing desktop icons, whose class is SHELLDLL_DefView. Finding this window was not easy. Due to unknown reasons, in certain systems the window is in some place in the windows’ hierarchy, but in other systems is in another place – both system being Window 7 RTM 32 bits. Because of this, the Giving a Presentation feature to hide and show desktop icons, did not work in every situations. I should thanks to my MVP coleague Elías Mereb for his help to test different candidate solutions until finding the good one.

/// <summary>
/// Called by EnumWindows. Sets <code>shellWindowHandle</code> if a window with class "SHELLDLL_DefView" is found during enumeration.
/// </summary>
/// <param name="handle">The handle of the window being enumerated.</param>
/// <param name="param">The argument passed to <code>EnumWindowsProc</code>; not used in this application.</param>
/// <returns>Allways returns 1.</returns>
private static int EnumWindowsProc(IntPtr handle, int param)
{
    try
    {
        IntPtr foundHandle = NativeMethods.FindWindowEx(handle, IntPtr.Zero, "SHELLDLL_DefView", null);
        if (!foundHandle.Equals(IntPtr.Zero))
        {
            shellWindowHandle = foundHandle;
            return 0;
        }
    }
    catch
    {
        // Intentionally left blank
    }

    return 1;
}

/// <summary>
/// Finds the window containing desktop icons.
/// </summary>
/// <returns>The handle of the window.</returns>
private static IntPtr FindShellWindow()
{
    IntPtr progmanHandle;
    IntPtr defaultViewHandle = IntPtr.Zero;
    IntPtr workerWHandle;
    int errorCode = NativeMethods.ERROR_SUCCESS;

    // Try the easy way first. "SHELLDLL_DefView" is a child window of "Progman".
    progmanHandle = NativeMethods.FindWindowEx(IntPtr.Zero, IntPtr.Zero, "Progman", null);

    if (!progmanHandle.Equals(IntPtr.Zero))
    {
        defaultViewHandle = NativeMethods.FindWindowEx(progmanHandle, IntPtr.Zero, "SHELLDLL_DefView", null);
        errorCode = Marshal.GetLastWin32Error();
    }

    if (!defaultViewHandle.Equals(IntPtr.Zero))
    {
        return defaultViewHandle;
    }
    else if (errorCode != NativeMethods.ERROR_SUCCESS)
    {
        Marshal.ThrowExceptionForHR(errorCode);
    }

    // Try the not so easy way then. In some systems "SHELLDLL_DefView" is a child of "WorkerW".
    errorCode = NativeMethods.ERROR_SUCCESS;
    workerWHandle = NativeMethods.FindWindowEx(IntPtr.Zero, IntPtr.Zero, "WorkerW", null);
    Debug.WriteLine("FindShellWindow.workerWHandle: {0}", workerWHandle);

    if (!workerWHandle.Equals(IntPtr.Zero))
    {
        defaultViewHandle = NativeMethods.FindWindowEx(workerWHandle, IntPtr.Zero, "SHELLDLL_DefView", null);
        errorCode = Marshal.GetLastWin32Error();
    }

    if (!defaultViewHandle.Equals(IntPtr.Zero))
    {
        return defaultViewHandle;
    }
    else if (errorCode != NativeMethods.ERROR_SUCCESS)
    {
        Marshal.ThrowExceptionForHR(errorCode);
    }

    shellWindowHandle = IntPtr.Zero;

    // Try the hard way. In some systems "SHELLDLL_DefView" is a child or a child of "Progman".
    if (NativeMethods.EnumWindows(EnumWindowsProc, progmanHandle) == 0)
    {
        errorCode = Marshal.GetLastWin32Error();
        if (errorCode != NativeMethods.ERROR_SUCCESS)
        {
            Marshal.ThrowExceptionForHR(errorCode);
        }
    }

    // Try the even more harder way. Just in case "SHELLDLL_DefView" is in another desktop.
    if (shellWindowHandle.Equals(IntPtr.Zero))
    {
        if (NativeMethods.EnumDesktopWindows(IntPtr.Zero, EnumWindowsProc, progmanHandle))
        {
            errorCode = Marshal.GetLastWin32Error();
            if (errorCode != NativeMethods.ERROR_SUCCESS)
            {
                Marshal.ThrowExceptionForHR(errorCode);
            }
        }
    }

    return shellWindowHandle;
}

In certain situations, even in the .NET Framework era, it is still useful to get a handle: give me one, and I will move the Earth. Or at least, I will hide and show desktop icons. See you later.

Written by fernandomachadopiriz

August 9, 2010 at 2:46 pm

Posted in C# 4.0

Tagged with