John McIlhinney .NUT

Monday, October 21, 2013

Firstly, let me apologise for having taken so long to finish this three-part series. Parts 1 and 2 showed how you CAN manage data among multiple forms but this part 3 will show how you SHOULD do it. That’s rather important I’d say, so let’s get into it.

The first and most important point to note is that forms are objects like any other, so moving data between forms is done just like it is for any other objects. How do you usually pass data into an object? You either set a property or else call a method and pass an argument. How do you usually get data out of an object? You either get a property or else call a method and get the return value. That’s exactly how you pass data into and get data out of a form because forms are objects.

The second point to note is that, generally speaking, a control should only be accessed by the form it is on. While it’s legal to access a control from outside its form, good practice dictates that you should not do so. With the first point in mind, that means that getting data from a control on a different form means getting data from the other form and the other form getting it from the control. Likewise, passing data to a control on another form means passing data to the other form and the other form passing it to the control.

This can be demonstrated fairly easily by displaying a list of records in one form and editing the selected record in another form. To build such an example, start by creating a new Windows Forms Application project. To Form1, add a DataGridView, a Button and a BindingSource. Now add the following code to populate the grid with a few records at startup.

Add a second form to the project and add a TextBox and a Button to that form. What we’re going to do is click the Button in Form1 to open Form2, get the record selected in the DataGridView in Form1 and edit its Name field in the TextBox in Form2. Now remember, Form2 cannot access the DataGridView in Form1 and Form1 cannot access the TextBox in Form2. How to move the data back and forth? The answer is that Form1 will set a property of Form2 to pass the initial data in and get the same property to get the final data out while, internally, that property of Form2 will access the TextBox. Which property? Well, one that you define yourself.

C#

publicstring TextBoxText

{

get

{

returnthis.textBox1.Text;

}

set

{

this.textBox1.Text = value;

}

}

VB

PublicProperty TextBoxText AsString

Get

ReturnMe.TextBox1.Text

EndGet

Set(value AsString)

Me.TextBox1.Text = value

EndSet

EndProperty

Back in Form1, we need to handle the Click event of the Button, open Form2 and pass it the Name from the record selected in the DataGridView.

Run the project now and Form1 will appear displaying the three records. Select one of the records and click the Button. You will see Form2 open with the Name field value from the selected record in the TextBox. Try editing the name and then click the Close button on the title bar of Form2. The dialogue will close and you’ll see that the Name field of the selected record remains unchanged. That’s because the DialogResult returned by ShowDialog was Cancel rather than OK.

Click the Button on Form1 again and this time, after editing the name in the TextBox, click the Button on Form2. This time, you’ll see that Form2 closes and the Name field of the selected record is updated to the value that you entered in the TextBox. Congratulations! You just passed data between two forms the right way.

That’s nice and all but what if, in our example, you wanted to do something back in Form1 without closing Form2? As it stands, ShowDialog returning is Form1’s notification that it should get some data from Form2 and update its own DataGridView. If we don’t call ShowDialog though, it can’t return and we can’t use it as a notification. What to do? Well, how are you usually notified that something has happened in .NET code? You handle an event.

If you want to learn all the details about custom events, I suggest that you check out my blog post here. I’m going to do it quick and dirty here because the point of this post is how to handle the event and use that notification rather than the details of how to generate it in the first place.

In Form2, we need to add an event that will notify anyone listening that the text in the TextBox has changed and, instead of closing the form when the Button is clicked, we need to raise that event.

If you run the project again you will see that you can open the dialogue and edit the selected record multiple times without closing the dialogue. If you close the dialogue and select another record then you can open a new dialogue and edit that as well.

This is a slightly contrived example but hopefully you get the idea. If you want to update a control in a form then only do it in that form. If you need to push and/or pull data between forms then you do so by getting or setting properties and/or calling methods of that form. If you need to notify a form that data is available to get then you do so with an event.

Thursday, October 17, 2013

I’ve been intending to make my first foray into Windows Phone development for a while now, but I had decided to put it off until I actually owned a Windows Phone device. I recently completed the 24 month contract on my previous phone (a Nokia E7 running Symbian Belle, which I was actually pretty happy with) and upgraded to a Nokia Lumia 925.

I’m very happy with the phone and I really like the Windows Phone OS… and I’m now a Windows Phone developer. I’m yet to actually publish my first app but I wanted to share with you an interesting issue I encountered and the solution I came up with. I couldn’t find any other information specific to this issue so I thought that this might be useful.

I had several pages in place to list, display, add and edit several entities so I decided I would look at adding page transitions then rather than going back and retrofitting them to every page at the end. I decided to use the TurnstileTransition on the display, add and edit pages and the TurnstileFeatherTransition on the list pages, both from the Windows Phone Toolkit.

Several of my list pages contained just a single LongListSelector. They worked fine simply by setting the TurnstileFeatherEffect.FeatheringIndex attached property for the page elements as you would expect. One of the pages contained several LongListSelectors inside a Pivot though, and that page didn’t quite work as it should. Let’s build a test app so that you can see what I mean.

Start by creating a new Windows Phone Pivot App project. We’re going to use NuGet to add the Windows Phone Toolkit package so if, like me, you have configured VS not to immediately save Windows projects, you’ll have to immediately save your project. For some reason NuGet won’t add packages to projects in a temporary location.

Once the project is saved, select Manage NuGet Packages from the Project menu. In the dialogue, select the ‘nuget.org’ item in the Online section and then search for windows phone toolkit. Install the package and you now have page transitions at you disposal.

We next need to enable transitions for all pages in the app. To do that, open the code file behind App.xaml, i.e. App.xaml.cs or App.xaml.vb. In the InitializePhoneApplication method, find the line that reads like this:

C#

RootFrame = newPhoneApplicationFrame();

VB

RootFrame = NewPhoneApplicationFrame()

and change it to this:

C#

RootFrame = newTransitionFrame();

VB

RootFrame = NewTransitionFrame()

If we’re going to have page transitions then we need to have at least two pages to navigate between. Our project gave us MainPage.xaml for free but we need to add a second page. From the Project menu, select Add New Item and then add a new Windows Phone Portrait Page.

Now that we have a second page to navigate to, let’s add the Turnstile transition to it. First, we’ll need to import the ‘toolkit’ namespace, so add the following attribute to the main <phone: PhoneApplicationPage> element:

Notice the use of the TurnstileTransition. That’s now going to provide a nice effect whenever we navigate to or from that page.

We need to do something similar, although not exactly the same, in MainPage.xaml. The ‘toolkit’ namespace is imported the same way and the transitions follow the same pattern but, this time, we use the TurnstileFeatherTransition.

XAML

<toolkit:TransitionService.NavigationInTransition>

<toolkit:NavigationInTransition>

<toolkit:NavigationInTransition.Backward>

<toolkit:TurnstileFeatherTransition Mode="BackwardIn"/>

</toolkit:NavigationInTransition.Backward>

<toolkit:NavigationInTransition.Forward>

<toolkit:TurnstileFeatherTransition Mode="ForwardIn"/>

</toolkit:NavigationInTransition.Forward>

</toolkit:NavigationInTransition>

</toolkit:TransitionService.NavigationInTransition>

<toolkit:TransitionService.NavigationOutTransition>

<toolkit:NavigationOutTransition>

<toolkit:NavigationOutTransition.Backward>

<toolkit:TurnstileFeatherTransition Mode="BackwardOut"/>

</toolkit:NavigationOutTransition.Backward>

<toolkit:NavigationOutTransition.Forward>

<toolkit:TurnstileFeatherTransition Mode="ForwardOut"/>

</toolkit:NavigationOutTransition.Forward>

</toolkit:NavigationOutTransition>

</toolkit:TransitionService.NavigationOutTransition>

When using TurnstileFeatherTransition, we have to specify the order in which elements are animated. To do that, we add the TurnstileFeatherEffect.FeatheringIndex attached property to each of the main elements. Our MainPage.xaml contains a Pivot with two PivotItems that each contain a LongListSelector. We need to specify that the Pivot is animated first, followed by the LongListSelectors.

Obviously only the contents of one PivotItem will be displayed at a time, so only one LongListSelector will ever be animated. My first thought was just to set the indexes in sequence, i.e. 0 for the Pivot, 1 for the first LongListSelector, 2 for the second LongListSelector and so on.

If you now run the project and select an item from the first list, you’ll see the intended page transition in all its glory. The items on the page flip out one after the other in a smooth series and then the next page flips in. Hit the Back button and the second page flips back and the first page appears again, one item at a time. All seems wonderful.

Now, select the second list on the pivot page and try the same thing. Something is not quite right. You’ll notice that the page title and list headers flip out first, as they should, but then there’s a little bit of a delay before the list items start to flip out. They still feather as they should but that little delay detracts from the overall UX. What to do?

Given that the first list animates correctly and the second doesn’t, I wondered whether setting the index of both lists to 1 would do the trick. That didn’t help, nor did any other combination of static values. It occurred to me that maybe changing the indexes as the selected PivotItem changes might fix the issue. As only one list can be visible, and therefore animated, at a time, I figured that it would make sense that only the selected list have a valid index. An element that doesn’t get animated has an index of –1, so I decided to not set the values in XAML but rather do it dynamically in code instead.

With that code, every time the selection in the Pivot changes, the indexes of all the lists get reset. If a PivotItem is selected then the LongListSelector it contains will have its index set to 1, otherwise the list index will be set to –1. Run the project now and you’ll see that the animation is as intended for both lists. My original project has four PivotItems and they all animate correctly so I’m assuming that it will work for an arbitrary number.

If anyone has a better solution then I’d love to hear about it but this seems to do the job well and without too much effort.