Derek Stone

There is no such thing as a null [msdn=System.DateTime]DateTime[/msdn] value in .NET. The DateTime class is a value type, and as such it can not contain a null value. Your best bet would be to use [msdn=System.DateTime]DateTime[/msdn].MinValue instead.

You shouldn't be creating the session solely on the main page. That defeats the whole purpose. A session should be created when the user requests the first page (regardless of which page it is), and should "travel" with the user as he or she moves from page to page.

Loop through the page's Form collection.

Leave off the pound signs and format the date, as it appears you are doing, as "mm/dd/yyyy". Microsoft SQL Server does parse dates in the same fashion as Microsoft Access.

No. You have to set the cookie using one of the two Forms Authentication methods, not Response.Cookies.Add().

It would be illegal to fake an install of Microsoft Office or a portion of the product. Do not expect any help from this site if that is your intention.

The best you can do is add the following meta tags to your Web page: <meta http-equiv="pragma" content="no-cache" /> <meta http-equiv="no-cache" content="no-cache" /> <meta http-equiv="expires" content="-1" /> <meta http-equiv="cache-control" content="no-cache" />

Customers are going to look at you cross-eyed if the site doesn't use real-time credit card processing, which is very easy to enable with help from companies such as Authorize.Net.

Forms authentication will only recognize a form authentication ticket, not just any cookie.

Image maps are still available through HTML, but .NET does not offer any additional wrappers for them.

You don't have 4 lines. You have one per property assignment. I think that's the big point you're missing. You can't include the Page_Load declaration in your argument. It applies only once to all controls on the page. What if you have logic (If/Then, Do/While, etc.) spattered in inline code tags? Calling that neat would be a complete fallacy. What if your code makes a method call that returns a value? Are you checking the value in inline code? Do you use error handling when it truly needs to be present? Are you properly HTML encoding all entity references and potentially harmful characters (something which Web control properties do for you)? The list goes on, but I'll leave it at that.

A new thread is created with each declaration of a Thread object. The following wil create two threads not two references to the same thread: Dim thread1 As Thread = New Thread(AddressOf Procedure1) Dim thread1 As Thread = New Thread(AddressOf Procedure1) Of course if the HTTP request is completed before the background thread completes the background thread will never finish processing, as it will be killed. In a case such as this you'll need to block the main thread from exiting until the background thread has finished processing. You can do this using asynchronous locks or the Thread.Join() method.

http://localhost/

It doesn't matter if you use Response.Write or the "=" shortcut. The point is they both look absolutely horrible. If you have a whole page of these try finding and correcting all of them. Then do the same thing with the preferred method as I posted above. You need to try it to understand the differences and benefits. It's clear that you won't be convinced otherwise.

The "runat" attribute is NOT processed by browsers. The behavior you are describing is not due to these attributes.

And if that doesn't work create a function to handle it: Public Function TruncateText(ByVal text As String, ByVal maximumLength As Integer) As String If text.Length > maximumLength Then Return text.Substring(0, maximumLength) & "..." Else Return text End If End Function

You're probably looking for a DHTML solution. Read up on the CSS attribute "display" and its values, and JavaScript's abilities to modify a Web page's DOM.

You do not need to assign values to the "Name" or "ApartmentState" properties of any thread object. As a matter of fact using the two properties may be causing the issues you describe. I'd strongly suggest removing assignments to "ApartmentState", since its presence it strictly for COM interoperation.

The problem with Response.Write extends far beyond basic issues such as speed and object persistence. The more important issue is that Response.Write creates spaghetti code-- code that is less readable due to it's spattering across content. Which is more readable and more manageable? <script runat="server"> Private Sub Page_Load(ByVal sender As Object, ByVal e As EventArgs) Dim identifier As Integer = 7 ctlHyperLink.NavigateUrl = "page.aspx?id=" & identifier.ToString() ctlHyperLink.Text = "Foobar" End Sub </script> <asp:HyperLink id="ctlHyperLink" NavigateUrl="" Text="" runat="server" /> <% Dim identifier As Integer = 7 %> <a href="<% Response.Write("page.aspx?id=" & identifier.ToString()) %>"><% Response.Write("Foobar") %></a> The latter is clearly a mess.

You do not need the "runat" attribute in the form element to access the values of the various child input tags. Simply add "runat" and "id" attributes to each input tag and access them as if they were normal Web controls. <input id="ctlFoobar" type="hidden" value="" runat="server" /> ctlFoobar.Value = "foobar"

Any element can be directly accessed via the object model. <link rel="stylesheet" type="text/css" href="" id="stylesheet" runat="server" /> stylesheet.Attributes("href") = "default.css"

It's the other way around: "Name <user@host.tld>".

You will need to purchase more licenses for the extra processors, but not for the the hyperthreading.

Perhaps I wasn't clear but you can use [msdn]System.Net[/msdn] to code any solution.

.NET does not offer any built-in support for FTP. You will have to code a solution yourself, after learning the FTP protocol, or find a pre-built component that supports this already.