In chapter 8, the book guides you through creating a window which allows you to drag a movie into the window, it displays the path, and when you click “ok” to make the window which displayed the path disappear, the video starts playing.

To do this, we set in the C# a URI variable, named it uri, and did a few other things. The application ran as intended – the video played.

But besides making it easy for the readers of the book, I could see quite quickly where naming a URI the name “uri” would get confusing when trying to debug something.

What if you’re jamming (which is what I call it when I’m on a roll and making things work the way I’m wanting w/o any hitch) and you’re just needing to modify something, and woopsy – modified the wrong one because you have the same dang thing written one after the next? Or what if you’re trying to find where you’d inadvertently modified the URI, and because you’re seeing the name “uri”, you don’t initially realize that its the name, not the variable.

*shakes head* Seems like something that might be considered as “preparing one’s self to shoot self in the foot.” Like taking your shoes and socks off so as to give yourself a clear shot.

Perhaps there’s more of a reason for naming a URI uri, or perhaps its just not an issue as its such common practice. This would be the first time that I’m working with C# that’s being put into place by me as opposed to locating someone else’s example code or modifying something that I’d used in the past or seen used in a previous project that worked.

Chapter 8 of Victor Guadioso’s book on Blend 2 talks about Events and Event Handlers.

For those who are beginning to feel as though the stuff here in this blog is way over your head, I’ll just give a basic example of what these are.

Most don’t ever think about what has to go into a program when they’re using it. They get frustrated when a certain feature isn’t exactly what they were looking for, but the thought put towards the existing functionality and the specific elements are often overlooked.

Something most everyone is familiar with: Logging into something. You typically have 2 fields, a field for your username and a field for your password, and then a button for logging in. There are often other elements, but we’ll ignore those as they’ll make this go into the realm of “convoluted”.

So you enter your username, then you enter your password, and you click on the button.

Events and Event Handlers are the things which look for your action and interaction with that button. They “listen” for your click along with a few other things, and when you do click, they are able to execute whatever it is that the button is coded to execute.

Get it?

Most people I know don’t think about the UI when the UI is built well. They just use it. Ever come to a DVD player? Likely you have. How do you use it? Well, you hit the button which tells it to eject. How does it know to eject when you hit that button? Why someone told it to do that. How does it know to play or pause when you hit the button? Well – someone told it to do those functions. Now how did the communication get from the button to the… thing that tells it to do those things?

Anyway – One of the first things that Victor goes over is DragEnter.

As in, when you have something that you’ve clicked upon and you drag it over – as your mouse enters the area of the application, it detects that you’re dragging something into the region of the application.

My application would build, but it wouldn’t do anything when I dragged an item into it – in fact, it shows me the little icon on my mouse pointer which signified that what I was doing as an illegal action. I checked and double checked my c# but couldn’t find the issue.

I couldn’t find it, so I took a break. When I came back, the issue stuck out like a sore thumb. I neglected to add into my XAML the property AllowDrop=”True”. Ran the application and vwalla. It functioned the way it was designed.

Trying to figure out what the heck it is that is causing the issue.

I’m at the tail end of chapter 7 and it isn’t seeing the reference to InsideButton and so therefore won’t run.

I’ve downloaded the example which is provided as support for the book and have compared and besides a few uncircumstancial changes, such as a difference in width and height or the source of an image, I’m not finding where it was that I’ve overlooked my xaml or C#.

I swear it has to be something just staring me RIGHT in the face.

Update: I discovered what my problem was – and this actually was an interesting find. There were 2 instances of my custom created item within the asset library. There was a custom control and a custom button. I’d used the custom button – and that is why I ran into the problem. It wasn’t actually referencing the custom control which had the x:Name set to InsideButton – so obviously, it wasn’t going to see the information necessary as there was no reference to the User Control asset!

As much as I thought I had a decent level of familiarity and proficiency with blend, I have to put my hands down and admit it now – I knew nothin’.

We started out by creating a shape in this chapter, turned it into a resource for the program to reuse, turned our back on the button and played around with  modifying the default system settings of List Boxes, and then returned with the information gained from our experience of changing the default system settings and took it further by adding our button style to a more root application resource dictionary and finally, after tinkering with the settings both by hand and by the visual designer, we turned that into a control which give us the ability to just simply click and drag out the newly created asset as an item on the toolbar.

This is freakin’ cool.  I don’t know what I was thinking when I kept allowing issues come in the way of going through this book.  Ahh… foresight.

The only thing that continues to bug me is that we’re creating buttons.  They’re supposed to DO stuff when you run your mouse over them and click!  I am assuming that he’ll get there, but its driving me nuts having what I’d call an “Image with function” as opposed to what this is supposed to be – a button – with all the characteristics of a button.  I am sometimes a patient person, but sometimes I choose to not be.

bahhh

Funny stuff.  I’m part way through chapter 7 – however far I am, I honestly don’t know.  Who’s counting anyway?

Excerpt from wherever the heck I am in chapter 7:

“… Earlier in this section, you learned that it is best practice to put all of your Styles in a ResourceDictionary, and you even learned how to do that.  So, why did I have you create your Button control Style inside of your Window1.xaml if it is not best practice to do so? …”

Most coming upon this would think that he was going to mention why it might be a strong point where best practice doesn’t always mean “always practice”.  But nope, his next line is:

“… Did I make a mistake?  Actually, yes I did…”

Most of the times mistakes allow someone to observe things from a perspective that they otherwise wouldn’t have seen something had they done it correctly.  Instead of covering that up or fixing it, he decided to use it and write that he’s using it for us to learn how to fix something of this nature.

I can see how this might commonly occur too – especially when using an interface like Blend – it would be a matter of accidentally not clicking the correct radial.  Quite likely, when doing things quickly.

Regardless of that – I found it amusing to read.

Edit: to save on having yet another frackin’ post here spamming twitter and facebook, I thought I’d add to this post since its so closely related to the above content.

Just after the comment, Victor delves into fixing the issue where someone has placed the style mistakenly within the xaml document instead of in the ResourceDictionary.

A point which is not mentioned which I find incredibly useful (though sometimes buggy – blame it on the application being a beta) is the use of split view.  Especialy when working with huge chunks of XAML and I’m not wanting to go into Visual Studio.  It has a really nice feature in blend’s split view.

So for those who are following, give this a try.  Doesn’t matter what you’re working on – if youhaven’t anything, just create a new project and add something – anything – to the workspace.

Now click on the tab labeled “Split” which you can find on the upper right of the screen.  Now click on an item within the Objects and Timeline menu.  Notice how the XAML for that item is highlighted within the XAML pane of your split view.

I find this to be quite useful.

My copy of this book is an electronic version, and though there are an aweful lot of advantages to having the electronic book (e.g. having it on a thumb drive to go through it whether I’m at work or at home) there are certain disadvantages as well.  The biggest of which is sometimes, a person needs to move their focus from the glare of the computer.  Often when I’m working with something complicated after hours of working, I’ll find my brain doesn’t want to absorb unless I print it out and have it in my hands…

For that – paper is happy.

My husband surprised me by doing 2-sided printing; he printed the entire book and bound it.

Crazy awesome.