Posts Tagged ‘events’
Silverlight – Wire up your form for programming
As I mentioned a couple of weeks ago, learning Silverlight is a lot more about relearning some basic assumptions than it is about learning a new language. We’ve already looked at the basic layout managers available and how that impacts putting a screen together. Today we want to look at how we can capture events and access the controls from our CSharp code.
< ! Read the rest of this entry »
Republished by Blog Post Promoter
When Session Objects Get Created With No Session Variables
I thought about calling this Session Object Madness, but it really isn’t that crazy once you think through what’s happening.
Here’s the issue. I have a client who does work for another client who is hosting their sites at IBM.
I’m told that IBM will not enable any session servers so none of the sites can include session objects. And that’s where the fun begins.
Manually Adding Event Handlers in VB.NET
Typically when we write our code, the event handlers get wired up for us using the handles clause. So we never have to worry about wiring up our event handlers manually.
But what about the case where we want to dynamically add a control to our Windows Form or our ASP.NET page? For example, add a button. How would you respond to the button click event?
Response.Redirect() executes too soon on the Server.
I’ve seen this question a couple of times in various situations. The first involves Javascript and the second involves server side code. Both are caused by a misunderstanding of what this function does and how web pages work.
Let’s start with the easy one: server side code.
Delegates in .NET
I received the following question:
What is a delegate? What problem does it solve? and When might I use a delegate?
A delegate is essentially a function pointer. We have used function pointers in various scenarios in the past to solve the problem of needing to execute user-defined code inside of another function or to fire events using the observed/observable programming pattern.
The problem we’ve always had with function pointers in the past is that there has never been any type safety. If I had a variable that was supposed to point to a function, I could assign it any function. So if the function the code is expecting returns a string and takes an integer and a string as parameters, I could assign the variable a function that returned nothing (void) and passed nothing. My code would compile, but when I got to that function, the chances are my code would blow up on me.