There seems to be a lot of confusion out there with regards to getting the ENTER key to submit a form. I'm here to tell you that the best solution I have found (and the one I use) is to drop whatever TextBox controls I'm using and the final Submit button into a panel control, and then set the DefaultButton property of the panel to the button to be clicked when ENTER is pressed. For example:

<asp:Panel ID="Panel1" runat="server" DefaultButton="Button_Search" Height="50px"
        Width="329px">

When focus is in a TextBox control inside the Panel and the ENTER key is struck, Button_Search will be "clicked" or invoked by the browser to post back the form data. The result is the feel of google's search engine where you simply type in the text box and hit ENTER to start the search.

A default button can also be supplied for the Form object itself, and this is set as a property on the form object too.

One thing to note is that the default behavior when a form is submitted through an ASP.NET button control is that the __EVENTTARGET or "source" of the form post is set to nothing. For example, by clicking a submit button manually, the Form variables posted look like this:

__LASTFOCUS=&__EVENTTARGET=&__EVENTARGUMENT=

However, by having the ENTER key cause the form post, the "cause" of the form post is manually set to actually be the button:

__LASTFOCUS=&__EVENTTARGET=Button_Search&__EVENTARGUMENT=undefined

This causes ASP.NET to have a fit if you do not have the following option set on the page (which can also be set through the web.config file):

<%@ Page EnableEventValidation="false"

The error you will see will be something like this:

Invalid postback or callback argument.  Event validation is enabled using <pages enableEventValidation="true"/> in configuration or <%@ Page EnableEventValidation="true" %> in a page.  For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them.  If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

Care should be had when setting the EnableEventValidation to false as it is set to True for security reasons.

Source: http://msdn.microsoft.com/msdnmag/issues/07/06/silverlight/default.aspx

 

1.       Introduction.

a.       Currently supports Mac OSX Safari and FireFox, Windows FireFox and IE

b.      Can be interacted with by AJAX code.

2.       Introducing Silverlight

a.       XAML is text-based and exposes it’s DOM to the browser in a scriptable manner (therefore, it is “functional”).

b.      The browser loads the XAML and creates a DOM that can be interacted with via script code, including modifications by script and event handling/processing.  You may also interact with the XAML DOM through methods (such as methods that start playing, stop playing or pause a presentation).

3.       XAML Overview

a.       XAML was first introduced as part of Windows Presentation Foundation; though the XAML used by Silverlight is a web-based subset of the full XAML supported by WPF.

b.      Silverlight XAML markup is based on the <canvas> tag; the “surface” upon which objects will be drawn.

4.       Inside the XAML

a.       There is support for pre-defined shapes, gradients, etc.

5.        Transformations, Media, and Animations

a.       XAML has built in support for transformations on objects (MatrixTransform, RotationTransform, ScaleTransform, etc).

b.      MediaElement tag controls video and audio.

c.       Animations are defined in XAML by how properties change with time.

6.       A simple silverlight application

a.       Currently silverlight.js is required to be located within the /js folder for your web application.

b.      Sys.Silverlight.createObjectEx() implements a new silverlight control.

c.       The silverlight plugin loads into a DIV tag with a unique ID.

d.      Dynamic features can be added to the Silverlight application (such as the source for a particular video) but modifying the script that controls and instantiates the objects through the ASPX page’s rendered output.

7.       Delivering XAML to the Silverlight Front-End

a.       The server can process and build the XAML as needed; the Sys.Silverlight.createObjectEx() method simply takes this markup to load and instantiate the XAML as a silverlight object.           

For those that deal in the world of asynchronous clientside programming, you've definitely encoutered JSON - the JavaScript Object Notation. The standard way of taking JSON formatted data and transforming it back into the javascript objects which it describes has been the eval() method. The problem, though, is that this is effectively invoking the JavaScript parser engine for the browser on potentially untrusted code - the javascript parser will basically execute whatever you give it through this method.

A relatively nice article (http://msdn2.microsoft.com/en-us/library/bb299886.aspx), it describes a script library located off of www.json.org (http://www.json.org/json.js) that provides a much more secure way of parsing JSON formatted data "parseJSON()". It's cousin "toJSONString()" is used to create the JSON strings.

...personally I haven't used this methodology, but it appears promising (at least until there is a much more standardized way of doing it).  

I've heard this question several times in the past few months and the answer is - an astounding - not even close. In fact, I would say that ASP.NET AJAX is going to enjoy a long and fruitfull life as a development tool for ASP.NET developers over the next three to five years at least, probably even more (though it may morph into something else during that time). However, this question - as to whether all the new client-side visual tools like Silverlight - is the end of ASP.NET AJAX is a fairly decent one given that, still, not a whole lot of people fully understand the depth of ASP.NET AJAX. Let's take a brief look.

First, ASP.NET AJAX is not only about AJAX; it's a full, complete, end-to-end framework for developers who wish to (or are forced to) dive into advanced client-side scripting. Quite literally thousands of controls are floating around in the world today that require the use of JavasScript - and millions upon millions of websites are leveraging it for reasons of client-side richness and control. What ASP.NET AJAX gives to the JavaScript (ECMA Script) developer is as close to an object-oriented, .NET'ish programming platform as you can get - so the need to write platform agnostic logic is either completely removed or mostly removed. For the millions of developers in the world right now who use JavaScript in their controls and web applications, development tools like Silverlight will not help.

Second, Silverlight is - like Flash - more of a user-interface platform all in itself. Like Flash, it will require the download of necessary bits to the client machine, and once there, will require a compliant browser to operate within. You will be able to create compelling interfaces, no doubt, but it's focus is always going to be angled towards the designer; the guys who think in the world of "flash'yness" (pardon the expression). A highly effecient, intuitive intranet or CRM solution, on the other hand, will probably not be written, ever, in a development framework like Flash or Silverlight - the same goes for an eCommerce webstore or a highly dynamic news site. These more business-oriented solutions will benefit greatly from the nature and flexibility of markup within the browser; and therefore find great benefit in the asynchronous attributes offered through ASP.NET AJAX. It would certainly be interesting if all the web pages out there looked like a high-end Silverlight presentation, but realistically, that wouldn't be practical at all to developer or maintain.

Third, ASP.NET AJAX is undergoing great advancements through the community - which shows a high focus on it as an important aspect of ASP.NET development. The open source community is contributing a great amount to the control toolkit, and this shows no sign of stopping or even slowing down.

And finally, and most importantly, Silverlight, Flash or what-have-you is not (nor probably ever will be) a natural environment to build products and solutions in for the ASP.NET, data-driven website developer. We have been raised under the notion of markup and are trained with that in mind, our websites are built around it, and the end-user expects it; the idea of removing or lessening the effects of this trend would be insane.

So, in summary, I see Silverlight being good for things like this:

• Kiosks,
  
• Company main or "splash" pages,
• Games,
  
• Presentations

...the kinds of sites where a designer would be involved mostly. And I see ASP.NET AJAX coming into play with:

• Intranets,
  
• Customer Portals,
  
• eCommerce sites
• Highly database backed or data-driven sites (like www.live.com)

...the kinds of things where a developer would be involved mostly.

Basically, there is no way ASP.NET AJAX is dead or nearing death. End of story.

Real buggy coding night. I'm in the process of putting together a site for myself when I ran into this problem:

http://forums.microsoft.com/msdn/showpost.aspx?postid=98346&siteid=1

Basically "Failed to generate user instance" and "An attempt to attach...failed".

For "An attempt to attach....failed" I was able to get around this by simply rebooting my development machine. Apparently there is some local cache of files stored on the hard drive that SQL Server Express uses and this was getting out of wack - somehow rebooting the system did the trick for me. It went away, but I was not able to identify exactly what caused the problem; to me this is a bad thing - I really like knowing WHAT happens when something goes wrong.

The "Failed to generate user instance" came from me being remoted into work from home (that'll teach me to work from home). Oh well, I guess I get my site done tomorrow.

Hrmph. :-(

We've all been pounded with "beware of SQL Injection Attacks" - yet I found a rather nice blog post here: http://blogs.msdn.com/dglover/archive/2005/06/01/423727.aspx that hands out a nice filter method for SQL Server. You might as well have a look and see if you can introduce it into your stored procedures....

Source: http://msdn.microsoft.com/msdnmag/issues/07/06/WickedCode/.

The main thing to take away from this article is that the UpdatePanel is a great control, but it definitely has its limitations when it comes to efficiency. Why? The article I linked to above does a fairly decent job of explaining why from a high level. The main, core, point to take away is that the UpdatePanel is good for purposes of simplicity; it will take whatever child controls are contained within it and make sure they participate in a partial post-back when one of them - or a control associated with the UpdatePanel - triggers a post-back event.

However, because the UpdatePanel must do so much for you it must believe that every control within it - or associated with it - could, potentially, need to be updated. These controls are mostly valid ASP.NET controls and, therefore, have ViewState that also must be maintained. In short, the UpdatePanel, in an attempt to be complete, will basically perform a pseudo full-postback to the server (even though the response message is optimized for use by the UpdatePanel). I guess, for a lack of a better analogy, think of the UpdatePanel as a mini page all to itself; I guess that somewhat holds up....

....so, bleh. If we're trying to be effecient, what do we do?

There are a couple options (one of which wasn't mentioned in the article but I would like to mention).

1. Utilize PageMethods. PageMethods are static methods of your ASP.NET page class that are treated as web service'able methods. You can reach those methods through your script and the PageMethods proxy class: yet another proxy class auto-generated by the ScriptManager and its bretheren.
   
2. Use a standard web service. If your ScriptManager has web services registered with it, it will auto-generate proxy classes for use when calling those methods from javascript. What this enables you to do is basically script against those methods.
   
3. And, the one that was left out - use the asynchronous scripting methods of ASP.NET AJAX:  http://ajax.asp.net/docs/ClientReference/Sys.Net/WebRequestClass/default.aspx

...being somewhat of a gearhead, I like the WebRequest class because it gives me absolute control over things; but it's definitely overkill for 99% of all uses (it's what Microsoft used to build the UpdatePanel and the asynchronous page-framework of ASP.NET AJAX). Basically MS "dogfooded" the WebRequest class for all async behavior in ASP.NET AJAX.

This last TechEd I went to a session on getting work as an independent consultant and ever since then I have been really focused on optimizing not only my own searching but that of other consultants. A couple more things I would like to mention:

1. If you have no problem getting certified for a security clearence, the government is hiring right now. People at the session really pushed the fact that the government is really looking into independent consulting at the moment (for one reason or another), and that it might be a good opportunity for independent developers.
2. Charity is, suprisingly, a good option. Even though you may not make a lot of money (or any) helping out a charity, charities have benefactors - people that donate money - and your good deeds go noticed. Benefactors do have money; doing a good job for something a rich person cares about might have its benefits.
3. Staffing agencies are there to help. Staffing agencies like this one: http://www.teksystems.com/Services/Staffing-Services/Default.aspx are there to link up parties. These people, obviously, take their cut, but it's a great way to get started. Remember - beggars can't be choosers.

...just a few more things to think about.