Richard Waddell

LightSwitch based Multi-Player Gaming Pattern using SignalR–Part I

webmaster@adefwebserver.com — Wed, 30 Oct 2013 00:00:00 GMT

Part I – Bare Bones Mechanics

Part II - Basic Classes and Interface Implementations

Part III – Game to Demonstrate Derived Classes and more Sophisticated Interface Implementations

The End Result

This article really starts when I start talking about motivation below, but I want to make the point up front that what I started out to do is not what I ended up doing. What I wanted to do was write some really cool simulations / games. What I ended up doing was writing what I hope is a really cool framework for designing / creating really cool simulations / games and a pretty mediocre game to demonstrate it. But I make lemonade out of that lemon by pointing out that a more complex game would obscure the details of how to use the framework.

Anyhoo, here’s a screen shot of three users logged into the same page and all seeing the same thing but all able to interact with it individually. The idea behind the framework is you can plug in any kind of behavior you want for the simulation objects and rules engine.

Try It Out

You can try the game online at http://sinalrgame1.lightswitchhelpwebsite.com/HTMLClient/

LightSwitch based Multi-Player Gaming Pattern using SignalR–Part II

webmaster@adefwebserver.com — Wed, 30 Oct 2013 00:00:00 GMT

Part I – Bare Bones Mechanics

Part II – Basic Classes and Interface Implementations

Part III – Game to Demonstrate Derived Classes and more Sophisticated Interface Implementations

The End Result

The end result is not what I set out to do. I wanted to write games, but what I ended up with was so brittle it evolved into a game framework which I hope can be used to create all sorts of games.

Here’s a screen shot of three users logged into the same page and all seeing the same thing but all able to interact with it individually. The intent of the framework is that you easily can plug in your own behavior and rules to control what comes out of that basic functionality.

Try It Out

You can try the game online at http://sinalrgame1.lightswitchhelpwebsite.com/HTMLClient/

LightSwitch based Multi-Player Gaming Pattern using SignalR–Part III

webmaster@adefwebserver.com — Wed, 30 Oct 2013 00:00:00 GMT

Part I – Bare Bones Mechanics

Part II – Basic Classes and Interface Implementations

Part III - Game to Demonstrate Derived Classes and More Sophisticated Interface Implementations

The End Result

The end result is a multi-player game that can be played across the internet by users logged into the same page. Unfortunately it’s not a very interesting game, and the question is still open as to whether I can in fact design an interesting game. What I have done, I hope, is to create a framework that can be used to design all sorts of interesting games. As such, a very simple game actually serves the purpose better as it exposes the details of using the framework to create alternative games and simulations and avoids obscuring them with details about the particular game. Maybe there will be a fourth post with an interesting game, but first we have to come up with a game lobby for this one, so who knows?

The large graphic below shows a game in progress, so you can’t see the buttons used to enter the game, shown immediately below. Game play starts as soon as there are at least two players. You can see below that the game is in progress when Red player enters the game and gets the initial Notification “Click button to enter game”.

The goal is to click on an opponent’s player so that your player moves on top. For this particular game, a point is awarded when you are successful, so, back on the Server, the behavior of the particular ooNaThing subtype, in conjunction with ooBerLink and ooBer, is to perform collision detection and increment its score if warranted. A different ooBerLink and ooNaThing might do something completely different, from handling the left mouse click to the consequences of collisions. There’s also nothing to prevent multiple ooNaThing subtypes, all interacting with each other. That’s the part you can plug in.

Try It Out

You can try the game online at http://sinalrgame1.lightswitchhelpwebsite.com/HTMLClient/

Joins and Left Outer Joins in LINQ–Do you want groups with that?

webmaster@adefwebserver.com — Sat, 02 Mar 2013 20:16:34 GMT

LINQ joins, both inner and outer, are not always what they seem and how you go about it may depend on whether you want grouping.

Even for simple projects, I like to use LightSwitch for what I call Back Room screens because it’s just so darn convenient. You’ll see what I mean later, because these first two tables are so primitive, so uncouth, so crude that I don’t even call them tables – LightSwitch will attach to them but only as read-only. I call them MasterRowPile and ChildRowPile LightSwitch, as you will see, wants little to do with them because they have no primary keys. Brace yourselves, they are hideous to behold.

The purpose of these unrelated tables is to start with the simplest case and illustrate the differences as relationships are added.

To set started I’m going to:

Create a manual relationship between the two tables by setting MasterRowID in ChildRowPile rows to match ID values in MasterRowPile rows.
Show you two ways LINQ provides to join between the two
Show you the T-SQL generated by the LINQ provider
Show the Execution Plans generated by the T-SQL

Since LightSwitch wouldn’t help me out, I had to use SSMS to enter values:

Inner and Outer Joins on Unrelated Tables

The tables shown above have no relationship as far as SQL is concerned, so any relationship is strictly by convention, meaning there is a column or columns on the ‘child’ table that is used to match a column or columns on the ‘master’ table. There are two ways to join these tables, using ‘join’, and using ‘where’

Join using ‘join’

private static void UnKeyedInnerJoinFromQuery()
{
    ShowTitle("UnKeyedInnerJoinFromQuery");
    using (RW_DataDataContext dc = new RW_DataDataContext())
    {
        var query = from master in dc.MasterRowPiles
                    join child in dc.ChildRowPiles
                        on master.ID equals child.MasterRowID
                    select new { MasterID = master.ID, Master = master.MasterRowName, ChildMasterID = child.MasterRowID, Child = child.ChildRowName };
        foreach (var entity in query)
            Console.WriteLine("{0} : {1} : {2} - {3}", entity.MasterID, entity.Master, entity.ChildMasterID, entity.Child);
    }
}

Join using ‘where’ (Equi-Join)

private static void UnKeyedEquiJoinFromQuery()
{
    ShowTitle("UnKeyedEquiJoinFromQuery");
    using (RW_DataDataContext dc = new RW_DataDataContext())
    {
        var query = from master in dc.MasterRowPiles
                    from child in dc.ChildRowPiles
                    where master.ID == child.MasterRowID
                    select new { MasterID = master.ID, Master = master.MasterRowName, ChildMasterID = child.MasterRowID, Child = child.ChildRowName };
        foreach (var entity in query)
            Console.WriteLine("{0} : {1} - {2} : {3}", entity.MasterID, entity.Master, entity.ChildMasterID, entity.Child);
    }
}

The Results

As we expect, we get a row for every master child combination and now rows for masters with no children.

The T-SQL and Execution Plans

It turns out that both approaches generate very similar T-SQL and identical execution plans.

So that takes care of the simple case. Not very interesting, and we’re not even going to look at the Extension Method syntax because it will come up later. We’re going to move on to Left Outer Joins on unrelated tables. This is where we get into whether to group or not to group.

Left Outer Join – Flattened Results

private static void UnKeyedLeftEquiJoinFromQuery()
{
    ShowTitle("UnKeyedLeftEquiJoinFromQuery");
    using (RW_DataDataContext dc = new RW_DataDataContext())
    {
        var query = 
        from master in dc.MasterRowPiles
        from child in dc.ChildRowPiles
            .Where(c => c.MasterRowID == master.ID)
            .DefaultIfEmpty()
            select new 
            { 
                MasterID = master.ID, 
                Master = master.MasterRowName, 
                ChildMasterID = child.MasterRowID != null ? child.MasterRowID : 0, 
                Child = child.ChildRowName 
            };
        foreach (var entity in query)
            Console.WriteLine("{0} : {1} - {2} : {3}", entity.MasterID, entity.Master, entity.ChildMasterID, entity.Child);
    }
}

This works because instead of the where keyword, I used the Where extension method to filter on the column values. This allowed me to apply the DefaultIfEmpty extension method to provide a default / empty child object if none exist on the database. That’s all it takes to convert an inner join to a left outer join.

As expected, we get not only the masters with children, but one row for each master that doesn’t have a child. I had to accommodate the constraint that null can’t be assigned to ChildMasterID, our first complication from dealing with results of Left Outer Joins. We’ll get into that more later.

Left Outer Join – Grouped Results

This is similar to the inner join up until the into keyword. At that point one group is created for every master row and linked to a collection of child rows associated with that group. If there are no child rows the collection is empty, but the group still exists.

private static void LeftJoinUnkeyedUsingIntoFromQuery()
{
    ShowTitle("LeftJoinUnkeyedUsingIntoFromQuery");
    using (RW_DataDataContext dc = new RW_DataDataContext())
    {
        var query = 
            from master in dc.MasterRowPiles
            join child in dc.ChildRowPiles
                on master.ID equals child.MasterRowID
            into children
            select new
            {
                Master = master.MasterRowName,
                Children = children
            };
        foreach (var group in query)
        {
            Console.WriteLine(group.Master);
            foreach (var child in group.Children)
                Console.WriteLine("{0} - {1} ", child.MasterRowID, child.ChildRowName);
        }
    }
}

The program output shows the grouping:

T-SQL From the Left Outer Join using the ‘into’ keyword

I’m going to show you the T-SQL, but first I want to show you how I get it from Visual studio, so I’m going to show you each step I’m taking to get the T-SQL that will be generated by the query above:

Place your cursor on a line after the IQueryable you’re interested in and select ‘Run To Cursor’. In the following, I’m going to inspect ‘query’ using the Debugging Visualizer, so I place my cursor on the ‘foreach’ line, right-click, and select ‘Run To Cursor’
When the line is hit, hover your cursor over ‘query’ and a tooltip will appear:
Click on SELECT in the tooltip and the textbox will open up.
Hit ctl-a / ctl-c to copy the contents.

And here’s the T-SQL:

{SELECT [t0].[MasterRowName] AS [Master], [t1].[ChildRowName], [t1].[MasterRowID], (
    SELECT COUNT(*)
    FROM [dbo].[ChildRowPile] AS [t2]
    WHERE [t0].[ID] = [t2].[MasterRowID]
    ) AS [value]
FROM [dbo].[MasterRowPile] AS [t0]
LEFT OUTER JOIN [dbo].[ChildRowPile] AS [t1] ON [t0].[ID] = [t1].[MasterRowID]
}

Now I’m a little confused at this point, because if I execute that T-SQL in SSMS I see flattened rows:

If I look at the output from the LINQ in LINQPad in rich text format I see grouping:

If I view it in LINQPad grid view:

But LINQPad sees the same T-SQL and yields the same results when you run it:

So there’s more going on here than is revealed in the T-SQL. As a matter of fact, Later we’ll look at GroupJoin(), which is the underlying extension method to see if we can figure out what’s going on. For now it’s enough to know the ‘join into’ approach will give you left outer join results, but grouped.

Let’s go back and look at the T-SQL generated by the method that gave us the flattened results:

T-SQL From the Left Outer Join using the Where and DefaultIfEmpty LINQ Extension Methods

It’s doing the same left outer join as the T-SQL we saw above generated by the join into approach. The only differences are the CASE statement that is preventing the NULL assignment, which is an implementation detail. The other difference is that the ‘join into’ T-SQL was saving the count of child rows as can be seen in the value column above. I assume that is to facilitate stepping through the ‘groups’.

SELECT [t0].[ID] AS [MasterID], [t0].[MasterRowName] AS [Master], 
    (CASE 
        WHEN ([t1].[MasterRowID]) IS NOT NULL THEN [t1].[MasterRowID]
        ELSE @p0
     END) AS [ChildMasterID], [t1].[ChildRowName] AS [Child]
FROM [dbo].[MasterRowPile] AS [t0]
LEFT OUTER JOIN [dbo].[ChildRowPile] AS [t1] ON [t1].[MasterRowID] = [t0].[ID]

Note the zero I specified as the null replacement assignment to MasterRowID is parameterized in the resultant T-SQL. After substituting a zero and running the query in SSMS I see what I would expect:

It turns out that the extension method generated when two ‘froms’ are used like this is SelectMany. So it seems that GroupJoin and SelectMany both do left outer joins, but GroupJoin groups the results and SelectMany leaves them flattened. We’ll look more closely later on.

Right now, let’s look at the difference when joining related tables.

Inner and Outer Joins on Related Tables

I have a pair of existing tables, Departments and Employees

Employees.DepartmentID is a foreign key pointing to Departments.ID. Each Department can be said to have a collection of zero or more Employees, as a Department may exist that has no Employees.

LightSwitch likes these tables just fine, so I can use it to show you the values in the tables.

Let’s begin with an inner join that will be the basis of our left outer join.

Inner Join on Related Tables

private static void InnerJoinOnCollectionFromQuery()
{
    // Same Result as EquiJoin
    ShowTitle("InnerJoinOnCollectionFromQuery");
    using (RW_DataDataContext dc = new RW_DataDataContext())
    {
        var query = from dept in dc.Departments
                    from emp in dept.Employees
                    select new { emp.Name, Department = dept.Name };
        foreach (var emp in query)
            Console.WriteLine("{0} - {1}", emp.Name, emp.Department);
    }
}

The difference is in the second ‘from’, which is using dot notation to get to the collection of Employees linked to the current Department. It turns out the T-SQL is exactly the same, but I think this code is more elegant than using a where to filter all Employees. And it definitely makes the left outer join easier.

As we’d expect for an inner join, we only get rows for Departments that have Employees:

And the T-SQL shows we’re actually getting an Equi-Join, which as we’ve already seen, generates exactly the same execution plan as an inner join.

{SELECT [t1].[Name], [t0].[Name] AS [Department]
FROM [dbo].[Departments] AS [t0], [dbo].[Employees] AS [t1]
WHERE [t1].[DepartmentID] = [t0].[ID]
}

Although now it can take advantage of the primary keys and relationship between the tables, just as the inner join would:

Left Outer Join on Related Tables

We only have to modify our inner join query slightly to convert it to a left outer join. In fact, we only have to add one extension method, DefaultIfEmpty. Because our dept.Employees collection is already limited to Employees in the current department, we can just slap the DefaultIfEmpty() method directly onto the collection:

private static void LeftJoinUsingCollectionFromQuery()
{
    ShowTitle("LeftJoinUsingCollectionFromQuery");
    using (RW_DataDataContext dc = new RW_DataDataContext())
    {
        var query = from dept in dc.Departments
                    from emp in dept.Employees.DefaultIfEmpty()
                    select new
                    {
                        Department = dept.Name,
                        Employee = emp.Name
                    };
        foreach (var emp in query)
        {
            Console.WriteLine("{0} - {1}", emp.Department, emp.Employee);
        }
    }
}

And sure enough, rows for every Department, including the ones with no Employees

The T-SQL is just a straightforward left outer join:

SELECT [t0].[Name] AS [Department], [t1].[Name] AS [Employee]
FROM [dbo].[Departments] AS [t0]
LEFT OUTER JOIN [dbo].[Employees] AS [t1] ON [t1].[DepartmentID] = [t0].[ID]

Grouped Left Outer Join On Related Tables Using the ‘join into’ Approach

I’m only showing you this because later we’ll want to compare the Extension Method Syntax, which hereafter I’m just going to call ‘Lambda Syntax’

private static void LeftJoinUsingIntoFromQuery()
{
    ShowTitle("LeftJoinUsingIntoFromQuery");
    using (RW_DataDataContext dc = new RW_DataDataContext())
    {
        var query = from dept in dc.Departments
                    join emp in dc.Employees
                    on
                        dept.ID equals emp.DepartmentID
                        into ed
                    select new
                    {
                        Department = dept.Name,
                        Employees = ed
                    };
        foreach (var group in query)
        {
            Console.WriteLine(group.Department);
            foreach (var emp in group.Employees)
                Console.WriteLine("  " + emp.Name);
        }
    }
}

The results have groups for every master row and collections of employees under each Department that has Employees:

The T-SQL is what we expect, with a column for the count of employees in each group.

SELECT [t0].[Name] AS [Department], [t1].[ID], [t1].[Name], [t1].[Salary], [t1].[DepartmentID], (
    SELECT COUNT(*)
    FROM [dbo].[Employees] AS [t2]
    WHERE [t0].[ID] = [t2].[DepartmentID]
    ) AS [value]
FROM [dbo].[Departments] AS [t0]
LEFT OUTER JOIN [dbo].[Employees] AS [t1] ON [t0].[ID] = [t1].[DepartmentID]
ORDER BY [t0].[ID], [t1].[ID]

And the output from the T-SQL:

Actually I can see now that the grouping is achieved by parsing the flattened output.

LINQ Extension Method Syntax

To understand the difference between the flattened and grouped results, we need to understand the function of the Extension Methods used in Lambda Syntax. Lambda syntax is always generated and passed to IQueryable as Func<> and Action<> delegates wrapped in Expressions, so even if we write the query in Comprehension syntax, understanding the Extension Method that actually gets called is key.

In the case of the successive from keywords in the Comprehension syntax query, the Extension Method is SelectMany()

private static void LeftJoinUsingCollectionFromLambda()
{
    ShowTitle("LeftJoinUsingCollectionFromLambda");
    using (RW_DataDataContext dc = new RW_DataDataContext())
    {
        var query = 
        dc.Departments
        .SelectMany
        (
            dept => dept.Employees.DefaultIfEmpty(),
            (dept, emp) =>
            new 
            {
                Department = dept.Name,
                Employee = emp.Name
            }
        );
        foreach (var emp in query)
        {
            Console.WriteLine("{0} - {1}", emp.Department, emp.Employee);
        }
    }
}

In the case of the ‘join into’ approach in the Comprehension syntax query, the Extension Method is GroupJoin()

private static void LeftJoinUsingIntoFromLambda()
{
    ShowTitle("LeftJoinUsingIntoFromLambda");
    using (RW_DataDataContext dc = new RW_DataDataContext())
    {
        var query = 
        dc.Departments
            .GroupJoin
            (
                dc.Employees,
                dept => (Int32?)(dept.ID),
                emp => emp.DepartmentID,
                (d, emps) =>
                new
                {
                    Department = d.Name,
                    Employees = emps
                }
            );
        foreach (var group in query)
        {
            Console.WriteLine(group.Department);
            foreach (var emp in group.Employees)
                Console.WriteLine("  " + emp.Name);
        }
    }
}

SelectMany() and GroupJoin() LINQ Extension Methods

Queryable.SelectMany() Documentation

Queryable.SelectMany
“Projects each element of a sequence to an IEnumerable and invokes a result selector function on each element therein. The resulting values from each intermediate sequence are combined into a single, one-dimensional sequence and returned.’
The Enumerable.SelectMany descriiption is a little easier to understand – “Projects each element of a sequence to an IEnumerable and flattens the resulting sequences into one sequence”

Yeah, Yeah, but how does it work. To make the lambda syntax a little easier to follow, In the comprehension query I did something I normally never do, which was to use one letter variable names that would be spread over more than one line of code. Since there’s only c and d, it’s clear what’s being referred to, and it makes them easier to follow in the lambda syntax query. Here it is as generated by LINQPad

So that’s not too bad. Each department ‘goes to’ a collection of department employees. For each member in that collection, department and employee ‘go to’ an anonymous type object with department and employee name.

Queryable.GroupJoin().Documentation

Queryable.GroupJoin
“Correlates the elements of two sequences based on key equality and groups the results.”
The Enumerable.GroupJoin description is the same

Here’s the ‘join into’ Lambda with one character variable names

Not too bad, I think. Here goes. From Departments join to Employees. Join on Department.ID and Employee.DepartmentID. The output consists of the Department Name and the Employees Collection of all the Employees where Employee.DepartmentID matches Department.ID. As we’ve seen this results in T-SQL that puts out a flattened result set with a column for the count of Employees in each group.

Where’s The LightSwitch?

You have me there. Hopefully the need for LINQ in LightSwitch and WCF RIA services and everywhere else will justify posting this here.

I will tell you this. If you attach to a table that has a nullable foreign key, LightSwitch will see that as a zero-or-one to many relationship, as it should. But if you later make that foreign-key column non-nullable your screens will stop working. If you then rebuild the entire solution you’ll get an error

However it is not possible to edit the relationship.

So you’re stuck with it unless you do some deleting, which always promises / threatens to delete all related code, so that’s a hassle.

Conclusion

If you want a flattened result set from your left outer join, use the multiple from approach in your Comprehension Query to generate the SelectMany() Extension Method. Otherwise use ‘join into’ to generate the GroupJoin extension method which will give you grouped results.

More ...

Rescue Legacy Data using LightSwitch, Stored Procedures, and Dynamic SQL, Part 1

webmaster@adefwebserver.com — Sat, 09 Feb 2013 07:51:20 GMT

LightSwitch provides for creating Data Sources in several ways. In the case of an existing database you would typically either specify the database itself or a WCF RIA Service.

But sometimes neither is feasible. I was confronted with a database with no primary keys and incredibly wide tables – so wide that I got error messages about it. And you can’t really do much with a database that has no primary keys. Also modifying the schema was not an option.

This actually turned out to be quite liberating. The reason we wanted to access the database outside of the legacy application it was designed for was to

Provide views of the data that the legacy application did not.
Add additional columns

By extracting the data into another database we could

Eliminate literally hundreds of columns (Yes, I do mean literally)
Create primary keys
Create relationships with referential integrity through foreign keys

Levels of Validation and Filtering on User Membership

webmaster@adefwebserver.com — Sat, 03 Dec 2011 16:22:09 GMT

Many-to-Many Relationships

A typical validation task that involves a many-to-many relationship involves a User who can update a number of Entities and an Entity that can be updated by a number of Users. For instance a School Book Inventory system where the counts for books at a particular school can only be updated by an employee of that school. Each employee can update a number of counts and each count can be updated by a number of employees. The application must prevent unauthorized data base updates and prevent employees from seeing counts from other schools.

We’ll start with validation. Although this article touches on validation on both client and server, to really understand what’s going on I suggest you see this post by Prem Ramanathan and this article he wrote for Code magazine. And if you want to get into what you can do in the Save Pipeline, which is entered when you call this.ApplicationData.SaveChanges(), either through code or when the save button is executed, check out this article by Dan Seefeldt.

The Requirements

As I said, the example is based on maintenance of book inventory for a number of schools within a school district. The inventory records for all books are maintained in a single table and each school is responsible for maintaining the counts for the books at that school. The requirements:

Don’t allow an employee of one school to update the counts from a different school
Don’t allow invalid counts
Don’t allow a particular book to be assigned to a particular school twice
Don’t allow an employee of one school to see the counts from a different school
Validate counts at the screen level

The Tables

We start by creating a Book entity. Turn off ‘Display by Default’ for Id (and for Id on all other entities we create). Turn on ‘Include in Unique Index’ for Title.

Next we have a School entity. Turn on ‘Include in Unique Index’ for Name.

The Relationships

A School has many Books and a Book can be at many Schools, so we need a many-to-many relationship between School and Book. Create a SchoolBook table as shown below. Note the relationships. Each SchoolBook is related to one School and one Book. By including both School and Book in unique index we ensure there is only one SchoolBook record for any particular Book at a particular School.

For display purposes we add a Summary property which is computed:

namespace LightSwitchApplication
{
    public partial class SchoolBook
    {
        partial void Summary_Compute(ref string result)
        {
            result = string.Format("{0} / {1}",
                School != null ? School.Name : "",
                Book != null ? Book.Title : "");
        }
    }
}

The Screens

About the screen names – I’ve been working on a project with a lot of tables that required a lot of validation and it was helpful to create what I call a Debug Screen for each entity to easily test before and after, switch back and forth, etc. Turns out not so useful here but what’s the harm, and tempus is fugiting, so I’m sticking with the names.

We’ll create DebugBooks, DebugSchools, and DebugSchoolBooks List and Detail screens. Be sure to include all Additional Data for all three screens.

The Data

Now hit ctl-F5 to run the application and let’s see what we have.

We add some Books above and some Schools below:

SchoolBook Validation

Now I’ll just point out here that if you add a SchoolBook relationship through the Books screen you’ll be constrained to the selected Book; the Schools screen will constrain you on the selected School. The School Books screen constrains neither, as shown below:

And we confirm we can add more than one book to Riverdale High, but we can’t add the same book twice:

Adding Users

Now we’ll add a SchoolEmployee entity and some School Employees to maintain the Counts:

We have a User property as we are going to match to logged-in User. It’s a business rule that a School Employee can only be employed at one School, so we make User the one and only field to ‘Include in Unique Index’.

Now let’s run the app and add a SchoolEmployee:

When you run under Visual Studio you are always logged in as TestUser, so that’s the User we link to our first School Employee.

Validation On The Server

Now we have an employee and books to count. So where do we start the validation process? I think the best place to start is at the bottom; i.e. don’t allow invalid changes to the database. Validating the entity is the closest we can get to the storage level working within LightSwitch. if we go back to our list of requirements we find that the first one is to prevent an employee of one school from updating the counts for a different school.

We add the code to enforce this rule to the SchoolBooks_Validate event. If your Entity window is wide enough you’ll see a ‘Write Code’ tab. Click on the down arrow icon to the right and select SchoolBooks_Validate, which as you can see, is called when an item is validated on the server:

If the window is not wide enough you can still get to the dropdown as shown below:

And here’s the code:

namespace LightSwitchApplication
{
    public partial class ApplicationDataService
    {
        partial void SchoolBooks_Validate(SchoolBook entity, EntitySetValidationResultsBuilder results)
        {
            var LoggedInSchoolEmployee = (from emp in DataWorkspace.ApplicationData.SchoolEmployees
                                          where emp.User == Application.Current.User.Name
                                          select emp).FirstOrDefault();
            if (LoggedInSchoolEmployee == null)
            {
                results.AddEntityError("Denied");
                return;
            }
            if (entity.School.Id != LoggedInSchoolEmployee.School.Id)
            {
                results.AddEntityError(string.Format("Employee {0} belongs to {1}, book belongs to {2}",
                                                        LoggedInSchoolEmployee.Name,
                                                        LoggedInSchoolEmployee.School.Name,
                                                        entity.School.Name));
            }
        }
    }
}

The error message when the logged-in user is not an employee has almost no information, The message when the user is an employee of a different school goes to the other extreme. You can also write it like this if you don’t need the Employee’s information.

partial void SchoolBooks_Validate(SchoolBook entity, EntitySetValidationResultsBuilder results)
{
    int? LoggedInSchoolEmployeeSchoolId = (from emp in DataWorkspace.ApplicationData.SchoolEmployees
                                    where emp.User == Application.Current.User.Name
                                    select emp).FirstOrDefault().School.Id;
    if (LoggedInSchoolEmployeeSchoolId.HasValue == false)
    {
        results.AddEntityError("Denied");
        return;
    }
    if (entity.School.Id != LoggedInSchoolEmployeeSchoolId)
    {
        results.AddEntityError(string.Format("Employee {0} belongs to {1}, book belongs to {2}",
                                                "Unknown", "Unknown",
                                                entity.School.Name));
        return;
    }
}

Let’s test. To start with I changed the SchoolEmployee User to ‘TestUser2’ to test the case where the logged-in User is not a SchoolEmployee. Here’s what I get after trying to change a count and clicking ‘Save’:

If I change Gabe's User back to ‘TestUser’ and click ‘Save’ again I get this message:

Validation On The Client

So far so good. Now let’s handle our second requirement, which is to prevent invalid counts. We start by preventing negative numbers:

To make it a little more interesting I added the admittedly contrived requirement that the sum of Count New, Count Used Good, and Count Used Poor must equal Count Total. We handle this by adding Validation to the SchoolBook CountTotal property:

Notice that where the SchoolBooks_Validate method is a member of ApplicationDataService, and runs on the server, CountTotal_Validate is a member of the SchoolBook class and runs on the client (but, as it turns out, not just on the client).

namespace LightSwitchApplication
{
    public partial class SchoolBook
    {
        ...
        partial void CountTotal_Validate(EntityValidationResultsBuilder results)
        {
            if (CountUsedGood + CountUsedPoor + CountNew != CountTotal)
                results.AddPropertyError("Individual counts must add up to count total");
        }
    }
}

So instead of seeing a message after clicking Save, one appears immediately when the input changes:

More Validation On The Server, No Extra Charge

Entity property validation also runs on the server, so that’s all the code you have to write. To prove this, I added a button to deliberately add a SchoolBook with invalid count total.

namespace LightSwitchApplication
{
    public partial class DebugBooks
    {
        partial void CreateInvalidSchoolBook_Execute()
        {
            var newSchoolBook = this.DataWorkspace.ApplicationData.SchoolBooks.AddNew();
            newSchoolBook.CountTotal = 50;
            newSchoolBook.CountUsedGood = 60;
            newSchoolBook.School = (from school in this.DataWorkspace.ApplicationData.Schools
                                    select school).FirstOrDefault();
            newSchoolBook.Book = (from book in this.DataWorkspace.ApplicationData.Books
                                  select book).FirstOrDefault();
            this.DataWorkspace.ApplicationData.SaveChanges();
        }
    }
}

And here’s the result, complete with custom error message provided by CountTotal_Validate:

So we were able to satisfy two of our requirements in one piece of code. We prevented invalid counts from making it to the database and we validated the counts at the screen level at the time of entry.

Filtering on Logged-In User

Now we move on to filtering on User, because the last requirement is to prevent an employee from seeing counts from a different school. There are a couple of ways to go about it. The first is to add a query to the SchoolBooks table.

We name the query LoggedInEmployeeSchoolBooks and handle the filtering in the preprocess query by looking up the Logged-In Employee and then passing only SchoolBooks belonging to the same school.

partial void LoggedInEmployeeSchoolBooks_PreprocessQuery(ref IQueryable query)
{
    var LoggedInEmployee = (from entity in DataWorkspace.ApplicationData.SchoolEmployees
                                    where entity.User == Application.Current.User.Name
                                    select entity).FirstOrDefault();
    query = LoggedInEmployee != null ?
        from entity in query
        where entity.School.Id == LoggedInEmployee.School.Id
        select entity : null;
}

And add a screen based on the new query:

If we put Gabe at Tom Landry Middle School:

He only sees books from Tom Landry:

Universal Filtering

Now let’s say you had an application where prevention of unauthorized data access is critical and/or there are a lot of screens to maintain. The pre-process query works fine, but you have to remember to use it as the basis for every screen and every dropdown that presents data that should be filtered on the user. It would be nice if every screen automatically filtered SchoolBook on logged-in Employee. This can be easily done by editing the SchoolBooks_All_PreprocessQuery .

As you would expect, it’s the same query:

partial void SchoolBooks_All_PreprocessQuery(ref IQueryable query)
{
    var LoggedInEmployee = (from entity in DataWorkspace.ApplicationData.SchoolEmployees
                            where entity.User == Application.Current.User.Name
                            select entity).FirstOrDefault();
    query = LoggedInEmployee != null ?
        from entity in query
        where entity.School.Id == LoggedInEmployee.School.Id
        select entity : null;
}

Now when we run the app we see that the unfiltered screen is now filtered.

Opening Holes In The Filter

It’s nice to be able to know all screens will filter on logged-in user without having to take any steps to do so. But you might have to make exceptions. Below I add a DistrictAccess Permission which we can use for that purpose:

partial void SchoolBooks_All_PreprocessQuery(ref IQueryable query)
{
    if (Application.Current.User.HasPermission(Permissions.DistrictAccess))
        return;
    var LoggedInEmployee = (from entity in DataWorkspace.ApplicationData.SchoolEmployees
                            where entity.User == Application.Current.User.Name
                            select entity).FirstOrDefault();
    query = LoggedInEmployee != null ?
        from entity in query
        where entity.School.Id == LoggedInEmployee.School.Id
        select entity : null;
}

Now when logged in as TestUser, who has DistrictAccess Permission, we see all SchoolBooks.

This way we apply the tightest possible security and then add exceptions as opposed to remembering to add security screen by screen, which might be an overstatement, because all you have to do is to remember to base the screen off the proper query, but still. Of course we can still screw it up, but it takes more effort. Or maybe not. Now we have to be careful about the permissions of the screen user if the relationships don’t fit into the tidy little scenario shown here.

Another alternative is to leave in the most restrictive filtering so that all screens that access that DataSource will filter on logged-in user with no exceptions. Then, to make exceptions, create a separate DataSource based on a WCF RIA Service that accesses the same table. You can apply different filtering, or no filtering at all, as required by the screens you will add that access that DataSource. Which puts you back to the position of making sure each screen accesses the correct DataSource No matter what, you have to be careful, but you do have options on how to divide up the responsibility.

Of course DistrictAccess doesn’t allow update of counts where the user is not an employee of the same school:

If you wanted DistrictAccess to allow counts to be updated just exit immediately as we did in the pre-process query by adding this as the first statement in SchoolBooks_Validate();

if (Application.User.HasPermission(Permissions.DistrictAccess))
    return;

Testing can get a bit tedious as you add more permissions because you can only ever log in as TestUser unless you publish the application and run it outside of Visual Studio.

Of course in a real-world app there would probably be only one employee table containing both school and district employees and there would be some sort of audit on the counts against employee, but that’s outside the illustrational scope of this example.

So that’s a glimpse into validation and filtering at different levels mostly based on the logged-in user belonging to the same group as the data.

I encourage you again to see this post by Prem Ramanathan and this article he wrote for Code magazine. And to find out more about the Save Pipeline check out this article by Dan Seefeldt.

The LightSwitch project is available here.

More ...

LightSwitch–Modal Add and Edit Windows

webmaster@adefwebserver.com — Tue, 14 Jun 2011 18:17:17 GMT

The default Add and Edit screens generated by LightSwitch often don’t allow the control you need to meet the business requirements. Consider the scenario where an entity must have a password column. Ideally we’d want the ‘Add’ screen to look something like this:

The default Add and Edit screens are inadequate for two reasons.

No masked password text box
A second password text box is required for matching, requiring a property that doesn’t map to the entity.

Fortunately, it’s easy to supply your own custom Add and Edit screens, and often a single screen can serve as both. Unfortunately there’s no way to display the screen modally, so when the user clicks the 'Add’ button they are taken to a new tabbed screen. On completion control returns to the original screen, but it’s not the ideal user experience.

Fortunately it’s possible to supply a modal window, unfortunately it takes a little more work than just creating a screen, but not as much as you might think. Thanks to Michael Washington for the Modal Window stuff.

I’m going to take you through the steps required to create the modal window you see above for adding an entity and one for editing. I wouldn’t be surprised if you could use one window for both, but let’s keep it simple for now.

Create The Subscriber Entity and Screen

First, create a Subscriber entity with UserName and Password properties:

Create an Editable Grid Screen:

Add A Modal Window Group

A Rows Layout Group is created by default; change it to a Modal Window:

Drag the UserName and Password properties under the Modal Window:

Change the name to AddSubscriber and uncheck the ‘Is Visible’ checkbox.

Add a ReEntered Password Property and Bind to the ReEntered Password TextBox

Click on ‘Add Data Item…’ and add a ReEnteredNewPassword string property that is not required:

Drag the ReEnteredNewPassword property to the Modal Window:

We need a Subscriber for the add screen to use, so add a NewSubscriber property:

Override the Add Button Execute Code

Before we get into binding or custom controls, let’s hook up the Add Button:

partial void gridAddAndEditNew_Execute()
{
    this.OpenModalWindow("AddSubscriber");
}

Resulting in:

We’re on the right track. As you probably already suspect, the User Name and Password boxes are grayed-out because the NewSubscriber property is null; we have a property, but no one is home. So we’ll new up the property and initialize the ReEnteredNewPassword property at the same time:

partial void gridAddAndEditNew_Execute()
{
    NewSubscriber = new Subscriber();
    ReEnteredNewPassword = String.Empty;
    this.OpenModalWindow(ADD_SUBSCRIBER_WINDOW);
    this.FindControl(ADD_SUBSCRIBER_WINDOW).ControlAvailable += 
        new EventHandler(NewSubscriber_WindowAvailable);
}

Actually, we’re a little ahead of ourselves, but this allows me to point out the value of constants when dealing with Modal Window group names. You’ll be using each one more than twice, as a matter of fact, so it makes sense to create a constant, especially with all this new-fangled binding. Why in my day if it compiled you knew it was good to go.

With just that much code we have a workable Add Subscriber window. As you can dimly see below, the values entered in the New Subscriber window show up in the Subscriber list – our NewSubscriber becomes part of the DataWorkspace Subscriber collection and so is bound to the list just like all the other Subscribers; now it can be saved or deleted just as though we had added it directly to the list.

Formatting

Before moving on, let’s clean up the UI a little bit. This is one of the things that’s so cool about LightSwitch. All you have to do to align the columns is add a Rows Layout group. The trickiest part is clicking the right place with the right button.

Right-click on the little down arrow between ‘Modal Window’ and ‘Add Subscriber’ then click on Add Group:

Resulting in:

Now drag the three controls to the Rows Layout Group and change ReEnteredNewPassword Display Name to ReEnter:

Who’s got a mouse and doesn’t need StackPanels or Grids? This nerd!!!!

Converting to Custom Controls

Ok, on to the PasswordBox Custom Controls. Left-click on the down-arrow between the label icon and ‘Password’ and select Custom Control:

Change the Password Custom Control Custom Control (?) property:

Select System.Windows.Controls.PasswordBox:

Do the same for ReEnteredNewPassword.

If you run this now, you’ll find that the Password boxes are masked, but the binding no longer works; text entered in the Password boxes does not show up in the new row in the list of Subscribers.

Binding the PasswordBox Controls

In the code below I’ve set the binding for all four password boxes, two for Add and two for Edit. Thanks to Tim Leung for the whole masked password and binding thing.

private const string EDIT_SUBSCRIBER_WINDOW = "EditSubscriber";
private const string ADD_SUBSCRIBER_WINDOW = "AddSubscriber";
private const string EDIT_PASSWORD_CONTROL = "EditScreenPassword";
private const string EDIT_PASSWORD_REENTER_CONTROL = "EditScreenReEnterPassword";
private const string NEW_PASSWORD_CONTROL = "AddScreenPassword";
private const string NEW_PASSWORD_REENTER_CONTROL = "AddScreenReEnterPassword";
private const string PASSWORD_MATCH_ERROR_TEMPLATE = "Reentered Password does not match Password in {0}";
partial void EditableSubscribersGrid_Created()
{
    // Bind the four Password properties to the PassWordBox Screen CustomControls
    // Edit Password Box
    IContentItemProxy proxyEditPassword = 
        this.FindControl(EDIT_PASSWORD_CONTROL);
    // WE are binding to the PasswordProperty dependency property of the PassWordBox, 
    proxyEditPassword.SetBinding
        (System.Windows.Controls.PasswordBox.PasswordProperty, 
        "Value", System.Windows.Data.BindingMode.TwoWay);
    // Edit ReEnter Password Box
    IContentItemProxy proxyReEnteredEditPassword = 
        this.FindControl( EDIT_PASSWORD_REENTER_CONTROL);
    proxyReEnteredEditPassword.SetBinding
        (System.Windows.Controls.PasswordBox.PasswordProperty, 
        "Value", System.Windows.Data.BindingMode.TwoWay);
    // New Passowrd Box
    IContentItemProxy proxyNewPassword = 
        this.FindControl(NEW_PASSWORD_CONTROL);
    proxyNewPassword.SetBinding
        (System.Windows.Controls.PasswordBox.PasswordProperty, 
        "Value", System.Windows.Data.BindingMode.TwoWay);
    // New ReEnter Password Box
    IContentItemProxy proxyReEnteredNewPassword = 
        this.FindControl(NEW_PASSWORD_REENTER_CONTROL);
    proxyReEnteredNewPassword.SetBinding
        (System.Windows.Controls.PasswordBox.PasswordProperty, 
        "Value", System.Windows.Data.BindingMode.TwoWay);
}

Formatting At Run Time

If you run the application now you’ll find that you can successfully add new Subscribers. But the UI needs a little work. Let’s do that at run time so we can experiment without having to re-build the application. To enable this capability, run the application in debug mode by hitting F5. After you click the Add button you’ll see:

The issue is that the Password boxes are unsightly. We can get into design mode by clicking on the ‘Design Screen’ icon on the upper-right corner of the page:

You’ll see something like this.

With some re-sizing and scrolling we can focus on the Sizing properties. Let’s set Horizontal Alignment to Stretch for both Password and ReEnter:

Click on Save and then the Add Button:

Maybe you’d like to size the textboxes to more closely match the likely input. Click on Design Screen, change the Horizontal Alignment back to Left, and set MinWidth to whatever you prefer, I chose 150:

Why, you ask, are the User Name and Password captions bold and ReEnter is not? I have not a clue. The captions are set through the Custom Control Display Name, but I don’t see any setting to affect the font weight. Doesn’t mean it can’t be changed, but I don’t know how to do it.

Validate the Password

Ok, now let’s add some validation, which consists of requiring that the values entered into the Password and ReEnter textboxes match. We already have our ReEnteredNewPassword property and it’s bound to the ReEnter Custom Control so we can go directly to validation

And here’s the code:

partial void ReEnteredNewPassword_Validate(ScreenValidationResultsBuilder results)
{
    if (this.NewSubscriber != null && 
        this.NewSubscriber.Password != null && 
        ReEnteredNewPassword != this.NewSubscriber.Password)
        results.AddPropertyError
            (String.Format(PASSWORD_MATCH_ERROR_TEMPLATE, "New Subscriber"));
}

Pretty straightforward. Now if the entered password values don’t match:

The validation issue will appear as soon as you tab away from Password and remain until you enter a matching value in Re-Enter, which is a bit naggy, but kind of unavoidable given the nature of binding.

Add and Cancel Buttons

This is serviceable, but a bit clumsy in that you can only cancel an add by deleting it from the Subscriber list after you exit the Add Subscriber window. We need Add and Cancel buttons. Right-click where indicated below and select Add Button:

Name it SubmitAdd:

Change the Display Name to ‘Add’. Right-click where indicated below and select ‘Edit Execute Code’:

It turns out all we have to do is close the window. As you saw above, the new Subscriber becomes part of the collection on creation, and remains so unless deleted.

partial void SubmitAdd_Execute()
{
    CloseAddSubscriberWindow();
}
private void CloseAddSubscriberWindow()
{
    this.CloseModalWindow(ADD_SUBSCRIBER_WINDOW);
    this.FindControl(ADD_SUBSCRIBER_WINDOW).IsVisible = false;
}

Notice that although OpenModalWindow sets the control IsVisible property to true, CloseModalWindow does not set it to false. If you don’t set it yourself you see this at the bottom of the page:

Add the Cancel button and the following CanExecute code:

partial void CancelAdd_Execute()
{
    CancelAddSubscriberChanges();
    CloseAddSubscriberWindow();
}
private void CancelAddSubscriberChanges()
{
    foreach (Subscriber subscriber in this.DataWorkspace.ApplicationData.Details.
                                GetChanges().AddedEntities.OfType())
        subscriber.Details.DiscardChanges();
}

Subscribing to the Modal Window Close Event

That covers the buttons, but what if the user clicks on the little ‘x’ in the upper-right corner. That should be the same as cancel, but as we’ve seen it’s not. We intercept that event by subscribing to the Modal Window close event. That requires a little setup. You saw a preview back when I showed you the Add button event handler:

partial void gridAddAndEditNew_Execute()
{
    NewSubscriber = new Subscriber();
    ReEnteredNewPassword = String.Empty;
    this.OpenModalWindow(ADD_SUBSCRIBER_WINDOW);
    this.FindControl(ADD_SUBSCRIBER_WINDOW).ControlAvailable += 
        new EventHandler(NewSubscriber_WindowAvailable);
}

So I’ll transition now to the event handler for the Edit button so we can cover the Edit Modal Window and the close event handling at the same time. The only difference in initialization is that we now have an existing Subscriber to work with.

As to the close event, we don’t have access to the underlying control until the ControlAvailable event, so that’s where we subscribe to the closed event. The nullable ChildWindow.DialogResult property will be null if the window was closed with the ‘x’, so the changes are canceled.

partial void gridEditSelected_Execute()
{
    // The Edit Button has been selected
    ReEnteredEditPassword = this.Subscribers.SelectedItem.Password;
    this.OpenModalWindow(EDIT_SUBSCRIBER_WINDOW);
    // We need to add a Closed event handler to the underlying control which we have access to when we catch the ControlAvailable event
    this.FindControl(EDIT_SUBSCRIBER_WINDOW).ControlAvailable += new EventHandler(EditSubscriber_WindowAvailable);
}
void EditSubscriber_WindowAvailable(object sender, ControlAvailableEventArgs e)
{
    this.FindControl(EDIT_SUBSCRIBER_WINDOW).ControlAvailable -= new EventHandler(EditSubscriber_WindowAvailable);
    ((ChildWindow)e.Control).Closed += new EventHandler(EditSubscriber_Closed);
}
void EditSubscriber_Closed(object sender, EventArgs e)
{
    ((ChildWindow)sender).Closed -= new EventHandler(EditSubscriber_Closed);
    if (!((ChildWindow)sender).DialogResult.HasValue)
        CancelEditSubscriberChanges();
    CloseEditSubscriberWindow();
}

The validation could use some fine-tuning in that in the ‘Add Subscriber’ window you can ignore the mismatched password warning and click the Add button, which should be disabled. Then you’re stuck with a validation error you can only clear by clicking ‘Refresh’. Same problem if you click the ‘x’ or Cancel button with a mismatched password error showing.

The Add button is pretty easy to handle.

partial void SubmitAdd_CanExecute(ref bool result)
{
    result = this.NewSubscriber != null &&
        this.NewSubscriber.Password != null &&
        ReEnteredNewPassword == this.NewSubscriber.Password;
}

Technorati Tags: LightSwitch,Modal Windows,Custom Controls,PasswordBox

The ‘x’ and Cancel Button situations where the passwords are mismatched can be handled by setting NewSubscriber to null. This causes the validation code to ignore the mismatch:

private void CancelAddSubscriberChanges()
{
    foreach (Subscriber subscriber in this.DataWorkspace.ApplicationData.Details.
                                GetChanges().AddedEntities.OfType())
        subscriber.Details.DiscardChanges();
    NewSubscriber = null;
}

And Robert is your Father’s brother!!!

The LightSwitch project is available at http://lightswitchhelpwebsite.comhttp://lightswitchhelpwebsite.com/Downloads.aspx

More ...

Drag and Drop and Events in LightSwitch Custom Controls

webmaster@adefwebserver.com — Sat, 21 May 2011 16:29:00 GMT

LightSwitch removes so much tedium from programming that I’m hoping it can be integrated into any Silverlight application. Obviously that requires Custom Controls, so the focus becomes finding the best patterns for interaction between LightSwitch and Custom Controls.

My first goal was to incorporate drag and drop. I spent a lot of time trying to come up with scenarios that were not trivial but also wouldn’t take a long time to set up. But I kept running into a fuzzy area when I tried to think about the nature of the relationship between LightSwitch and the Custom Control. I was actually happy when I realized this because it meant I could start at the most basic level and work up. In other words, no hard thinking for awhile.

So, compulsive (or is it obsessive) that I am, even though Custom Controls are not totally new to me, I began by creating a New Data Screen linked to no table. To the screen I added a string property named BasicMessage and dragged it onto the screen layout, resulting in a TextBox bound to the BasicMessage property. To supply the Custom Control I added a SilverLight Class Library project named CustomControls to the solution and to that project added a UserControl fumble-fingeredly named DragaArena consisting of a Beige 150 x 150 pixel Canvas.

To add DragaArena to the screen, I added a Custom Control under the BasicMessage TextBox. I changed the TextBox Display name to LightSwitch and the Custom Control Display Name to SilverLight.

To bind the Custom Control to DragaArena, click on Choices on the Custom Control properties panel. Note the name of the CustomControl is ‘DragArena’. This is important because CreateNew codebehind will be searching for this control in order to subscribe to the BallDropped event. I should have made it more distinguishable from the name of the SilverLight UserControl it encapsulates, ‘DragaArena’, but forewarned is forearmed.

(1) Click on Add Reference (2) Select CustomControls and click OK (3) Select DragaArena and click OK

Now we add a Label and a TextBox to DragaArena and bind them to BasicMessage. There’s also a ball we’re going to use for dragging and dropping:

<UserControl x:Class="CustomControls.DragaArena"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400" xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk">
    
    <Canvas x:Name="LayoutRoot" Background="#FFFFE6CD" Height="150" Width="150" >
		<sdk:Label Height="28" HorizontalAlignment="Left" x:Name="label1" Width="120" 
			Content="{Binding Screen.BasicMessage}" Canvas.Left="10" Canvas.Top="10" />
		<TextBox Height="23" HorizontalAlignment="Left" x:Name="textBox1" Text="{Binding Screen.BasicMessage, Mode=TwoWay}" 
			Width="120" Canvas.Left="10" Canvas.Top="30" />
		<Ellipse x:Name="ball" Fill="#FFF15F0A" Height="38" Stroke="Black" Width="41" MouseLeftButtonDown="ball_MouseLeftButtonDown" Canvas.Left="34" Canvas.Top="79"/>
	Canvas>
UserControl>

Note the binding is to Screen.BasicMessage. At runtime the Content property of label1 and the Text property of textBox1 are bound to the BasicMessage property of the Screen object, which is the parent of DragaArena, in this case CreateNew.

So now you can see the effect of the binding by entering some text:

The drag and drop code is pretty straightforward considering I lifted 95% of it from Michael Washington. I feel unclean writing in the code-behind of a UserControl, but this is experimental code, and we’re all reasonable (hah – programmers) adults (hah – programmers) here so I’m sure the stigma won’t make me an outcast. Well, reasonably sure.

namespace CustomControls
{
    public partial class DragaArena : UserControl
    {
        private static Point _StartingDragPoint;
        public DragaArena()
        {
            InitializeComponent();
        }
        public event EventHandler BallDropped;
        protected virtual void OnBallDropped(EventArgs e)
        {
            if (BallDropped != null)
                BallDropped(this, EventArgs.Empty);
        }
        private void ball_MouseLeftButtonDown(object sender, System.Windows.Input.MouseButtonEventArgs e)
        {
            FrameworkElement elem = sender as FrameworkElement;
            _StartingDragPoint = e.GetPosition(elem);
            elem.MouseMove += new MouseEventHandler(elem_MouseMove);
            elem.MouseLeftButtonUp += new MouseButtonEventHandler(elem_MouseLeftButtonUp);
            UpdateElementPosition(elem, e.GetPosition(this.LayoutRoot));
        }
        void elem_MouseLeftButtonUp(object sender, MouseButtonEventArgs e)
        {
            FrameworkElement elem = sender as FrameworkElement;
            elem.ReleaseMouseCapture();
            elem.MouseLeftButtonUp -= new MouseButtonEventHandler(elem_MouseLeftButtonUp);
            elem.MouseMove -= new MouseEventHandler(elem_MouseMove);
            OnBallDropped(EventArgs.Empty);
        }
        void elem_MouseMove(object sender, MouseEventArgs e)
        {
            FrameworkElement elem = sender as FrameworkElement;
            Canvas canvas = elem.Parent as Canvas;
            UpdateElementPosition(elem, e.GetPosition(canvas));
        }
        private void UpdateElementPosition(FrameworkElement elem, Point newPoint)
        {
            Canvas.SetLeft(elem, newPoint.X - _StartingDragPoint.X);
            Canvas.SetTop(elem, newPoint.Y - _StartingDragPoint.Y);
        }
    }
}

You’ll need to add a reference to the CustomControls assembly. First select File View:

Add Reference:

Select CustomControls:

Happily frustrating my expectations, subscribing to the event is easy peasy, considering I lifted it from Karol Zador-Przylecki. See the code at the very end of the article for the specific example. Here’s the code I wrote based on it. This is the point where we’re searching for the LightSwitch CustomControl, ‘DragArena’ from which we’re going to create a proxy from which we can access the encapsulated SilverLight User Control, ‘DragaArena’, in OnDragArenaControlAvailable:

using CustomControls;
namespace LightSwitchApplication
{
    public partial class CreateNew
    {
        IContentItemProxy _arenaProxy = null;
        partial void CreateNew_Created()
        {
            _arenaProxy = this.FindControl("DragArena");
            _arenaProxy.ControlAvailable += OnDragArenaControlAvailable;
            _arenaProxy.ControlUnavailable += OnDragArenaControlUnvailable;
        }
        void OnDragArenaControlAvailable(object sender, ControlAvailableEventArgs e)
        {
            DragaArena arena = e.Control as DragaArena;
            arena.BallDropped += arena_BallDropped;
        }
        void OnDragArenaControlUnvailable(object sender, ControlUnavailableEventArgs e)
        {
            DragaArena arena = e.Control as DragaArena;
            arena.BallDropped -= arena_BallDropped;
        }
        void arena_BallDropped(object sender, EventArgs e)
        {
            BasicMessage = "Ball Dropped";
        }
        partial void CreateNew_Closing(ref bool cancel)
        {
            _arenaProxy.ControlAvailable -= OnDragArenaControlAvailable;
            _arenaProxy.ControlUnavailable -= OnDragArenaControlUnvailable;
        }
    }
}

After dropping the ball:

So if you can handle everything through subscribing to events on the Custom Control you don’t need to give the Custom Control any knowledge of its parent other than the late binding in XAML.

Stay tuned for an example where the dragged objects represent data from Screen and I totally rip off more code from Michael Washington.

More ...

LightSwitch: Creating a Relationship on current User through SecurityData.UserRegistrations Table

webmaster@adefwebserver.com — Fri, 06 May 2011 01:40:00 GMT

Often we don’t care who the logged-in User is because we can control what they can do through Roles and Permissions. But if the User is a member of some group, it would be handy to place the Users table in a many-to-one relationship with that group. In this example the groups are SalesTeams made up of SalesPersons. All Sales made by a particular team are accessible only by members of that team.

To make that happen a new User is created, if necessary, when a SalesPerson is created. Since a SalesPerson is in a many-to-one relationship with SalesTeam, so is the User. This article shows you how to create the UserRegistration and then two ways to identify the SalesPerson associated with the logged-in User and thereby the relationship with SalesTeam and Sales.

Start by adding a SalesTeam entity:

A SalesTeam is composed of SalesPersons:

We’re going to associate each SalesPerson with a User. Let’s make sure we’re agreed on what I mean by ‘User’. Under Solution Explorer / Properties / Access Control select ‘User Forms authentication’ and check ‘Granted for debug’ next to SecurityAdministration.

Press F5 to run the application, expand the Administration menu, and click on ‘Users’.

As you can see, there are no Users defined. In the lower-right corner we see that we are logged in as the special user TestUser by virtue of running under Visual Studio. If this were a deployed application it would prompt for user and password on startup. Instead we are automatically logged-in for convenience during development. The upshot is that in a deployed application the current User, which can be determined through Application.Current.User.Name, will always be one of the Users you see on the Administration/Users page shown above. Under Visual Studio it will always be TestUser, which isn’t necessarily one of the Users you see above.

First of all, we need a property to bind User to SalesPerson. As I said, User.Name is actually UserRegistration.UserName, so we’ll add a UserName property to SalesPerson. We can use the Name property for the person’s actual name.

Before we can add SalesPersons we need SalesTeams. Add a SalesTeam Editable Grid Screen:

Add some SalesTeams:

Save them and create a SalesPerson Editable Grid Screen where we find we can select the Sales Team when we create a Sales Person:

The point of SalesPersons.UserName is to map to UserRegistration.UserName so at run time we can tell which SalesPerson we are dealing with by matching Application.User.Name to SalesPerson.UserName. This in effect gives us the ability to create relationships between User and other tables; In this case a many-to-one relationship to SalesTeam. You could also create one-to-many relationships, such as a scenario where a SalesPerson got an individualized commission on each Sale made by the team requiring a one-to-many relationship between SalesPerson and Commissions.

When we create a new SalesPerson…

…if necessary we also create a new UserRegistration. We don’t want to deal with passwords, so we set it to some default value the user should change the first time they log on:

namespace LightSwitchApplication

{

    public partial class ApplicationDataService

    {

        partial void SalesPersons_Inserting(SalesPerson entity)

        {

            var reg = (from regs in this.DataWorkspace.SecurityData.UserRegistrations

                       where regs.UserName == entity.UserName

                       select regs).FirstOrDefault();

            if (reg == null)

            {

                var newUser = this.DataWorkspace.SecurityData.UserRegistrations.AddNew();

                newUser.UserName = entity.UserName;

                newUser.FullName = entity.Name;

                newUser.Password = "changeme/123";

                this.DataWorkspace.SecurityData.SaveChanges();

            }


        }

    }

}

If we now go to Administration/Users we find the new User there.

When launched from Visual Studio, the logged-on user is always TestUser, so we’ll create add a SalesPerson to Red Team with that UserName.

Now we need something to test. The point of belonging to a SalesTeam is that you have access to whatever the SalesTeam has access to. So we’ll create a Sale entity with a many-to-one relationship to SalesTeam.

Create an Editable Grid Screen for Sales and add some:

Now you can see I’ve added Sales for both teams. For obvious reasons, team members would not be allowed access to this screen. So we’ll add another Editable Grid Screen and filter it by the SalesTeam of the logged-in User. There’s a couple of ways we could do this. We could go ahead and create the screen and then modify the query, but I’m going to go ahead and create the query and then generate a screen based on the query.

Right-Click the Sales Data Source and select Add Query.

And there are a couple of ways to write the query to restrict Sales to only those belonging to the same SalesTeam as the logged-on SalesPerson / User.

A ‘pre-process’ query that runs before the query we’re modifying
A Global Variable that we can add as a filter.

The Pre-Process Query

To add the pre-process query,

In the query we find the SalesPerson associated with the logged on User. This gives us the SalesTeam and thereby a means to select only Sales linked to the same SalesTeam as the SalesPerson / User.:

partial void UserSalesTeamSales_PreprocessQuery(ref IQueryable query)

{

    SalesPerson person = (from persons in this.DataWorkspace.ApplicationData.SalesPersons

                            where persons.UserName == Application.Current.User.Name

                            select persons).FirstOrDefault();

    int salesTeamId = person == null ? -1 : person.SalesTeam.Id;

    query = from theSales in query

            where theSales.SalesTeam.Id == salesTeamId

            select theSales;


}

Now we create the screen:

The first thing I see is that when logged-in as TestUser I can only see Red Team Sales:

If I go to the Editable Sales Persons Grid I find that TestUser should be restricted to Red Team sales. So far so good:

If I change the Sales Team to Blue Team, click Save, go back to Editable User Sales Team Sales Grid and click Refresh:

I find that TestUser now is restricted to Blue Team Sales.

The Global Variable Query Parameter

The scary thing about creating a Global Variable is that you have to modify an lsml file, which can disable the designer and lead to strange error messages if mishandled, so we have to proceed with care. First, switch to file view:

We’re going to edit Common/ ApplicationDefinition.lsml. You may want to back up the file first.

You may get a Catastrophic failure when you try to edit this file. I discovered that if I first opened this one under data, then closed it I was able to edit the one under Common. If you look at properties you’ll find they both map to the same file, the one under data.

Insert the following GlobalValueContainerDefinition element after the initial ModelFragment element tag as shown below:

<ModelFragment xmlns="http://schemas.microsoft.com/LightSwitch/2010/xaml/model"
               xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <GlobalValueContainerDefinition Name="GlobalSalesTeamInfo">
    <GlobalValueDefinition Name="UserSalesTeamId" ReturnType=":Int32">
      <GlobalValueDefinition.Attributes>
        <DisplayName Value="User SalesTeam ID" />
        <Description Value ="Gets the logged on User's SalesTeam ID." />
      GlobalValueDefinition.Attributes>
    GlobalValueDefinition>
  GlobalValueContainerDefinition>

Now you have to provide the code behind the variable. Create a new class in the Common folder named GlobalSalesTeamInfo. When created there will be a bunch of using statements at the top that show errors. Replace everything with this:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using Microsoft.LightSwitch;


namespace LightSwitchApplication

{

    public class GlobalSalesTeamInfo

    {

        public static int UserSalesTeamId()

        {

            SalesPerson person = (from persons in Application.Current.CreateDataWorkspace().ApplicationData.SalesPersons

                                  where persons.UserName == Application.Current.User.Name

                                  select persons).FirstOrDefault();

            return person != null ? person.SalesTeam.Id : -1;

        }

    }

}

Now we need to switch to logical view so we can modify the query to use this new variable. But when we do the designer will throw a hissy and tell you that you must reload. Once upon a time you could right-click in Solution Explorer and reload from there. Now, if you’re lucky, BindingToUsersTable Designer will be in a tab at the top. Click on that tab and you’ll get a page with a Reload button. If you can’t get to that tab the only other way I know is to reload the solution. In other words, you need for the screen designer to be open in a tab when you edit the .lsml file. That way, when you need to reload, the tab will be there to select. In my experience once you change the .lsml file the Solution Explorer is hosed as far as the logical view, so you can’t get to the designer. Actually I didn’t think of the View menu. Anyway, don’t panic when you start getting all the incomprehensible messages. At best you have to exit and restart. At worst you have to exit, restore the .lsml file, and restart.

Back in logical view, open the UserSalesTeamSales query:

We can now filter on User Sales Team ID. (LightSwitch insists on breaking the name up into words).

Get rid of the pre-process query:

//partial void UserSalesTeamSales_PreprocessQuery(ref IQueryable query)

//{

// SalesPerson person = (from persons in this.DataWorkspace.ApplicationData.SalesPersons

// where persons.UserName == Application.Current.User.Name

// select persons).FirstOrDefault();

// int salesTeamId = person == null ? -1 : person.SalesTeam.Id;

// query = from theSales in query

// where theSales.SalesTeam.Id == salesTeamId

// select theSales;


//}

And sure enough I get the same results when I switch TestUser’s team membership.

The advantage of the Global Variable approach is that it’s simpler to add the filter to each query that needs it, as you can see above, than it is to write a custom pre-process query for every query that needs to filter on SalesTeam membership as you can see in the now commented-out code immediately above.

Testing Other Users

To really test, we need to deploy the application so we can log in as different Users. When you do, you’ll find that all your Users and data have disappeared, so we’ll have to create new SalesTeams, SalesPersons, and Sales.

We’ll log in as a Blue Team Member:

And we only see Blue Team Sales:

Now we log in as a Red Team Member:

And we’re restricted to Red Team Sales:

So there you have it. In a less restricted application you’d want to make the Entity associated with User a little more generic, such as Person, so they could participate in a variety of scenarios but always be identifiable as an individual User. Which means a more succinct example would be a Global Variable that identifies the User/Person. Here I use the example of SalesPerson. I’ve added the UserSalesPersonID GlobalValueDefinition to ApplicationDefinition.lsml.

<ModelFragment xmlns="http://schemas.microsoft.com/LightSwitch/2010/xaml/model"
               xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
  <GlobalValueContainerDefinition Name="GlobalSalesTeamInfo">
    <GlobalValueDefinition Name="UserSalesTeamId" ReturnType=":Int32">
      <GlobalValueDefinition.Attributes>
        <DisplayName Value="User SalesTeam ID" />
        <Description Value ="Gets the logged on User's SalesTeam ID." />
      GlobalValueDefinition.Attributes>
    GlobalValueDefinition>
    <GlobalValueDefinition Name="UserSalesPersonId" ReturnType=":Int32">
      <GlobalValueDefinition.Attributes>
        <DisplayName Value="User SalesPerson ID" />
        <Description Value ="Gets the logged on User's SalesPerson ID." />
      GlobalValueDefinition.Attributes>
    GlobalValueDefinition>
  GlobalValueContainerDefinition>

Visual Studio was particularly cranky about these changes. I had to reload the solution twice, once because I made a mistake and it wouldn’t recognize that I had fixed it. The second time I don’t know why. The change was what you see above and I could reload in the designer, but Logical View would not come up. After I reloaded the solution, there it was. So don’t assume you’ve made a mistake when Logical View won’t come up, even if you hit the designer reload button.

Here’s the code behind UserSalesPersonId. I’ve kept UserSalesTeamId because it’s still what I really need, but you can see that you could spin off Global Variables for every relationship that the logged-on user is involved from the one core method LoggedOnPerson() .

namespace LightSwitchApplication
{
    public class GlobalSalesTeamInfo
    {
        public static int UserSalesPersonId()
        {
            SalesPerson person = LoggedOnPerson();
            return person != null ? person.Id : -1;
        }
        public static int UserSalesTeamId()
        {
            SalesPerson person = LoggedOnPerson();
            return person != null ? person.SalesTeam.Id : -1;
        }
        private static SalesPerson LoggedOnPerson()
        {
            return (from persons in Application.Current.CreateDataWorkspace().ApplicationData.SalesPersons
                              where persons.UserName == Application.Current.User.Name
                              select persons).FirstOrDefault();
        }
    }
}

The LightSwitch project is available at http://lightswitchhelpwebsite.com/Downloads.aspx

More ...