Derek Stone

I have my AOM CD sitting on my bureau. I really wish I had time to play it like I did AoK:TC. Oh well... days gone by. Regardless, there are ways of doing what you're asking. The simplest method is to upload the file to the secondary (high bandwidth) server from a form located in an auxiliary window. This form would only handle attachments, and would post to either a CGI, Perl, PHP, etc. script on the high bandwidth server. The file would then be associated with the post in a database field-- most likely the table that holds the posts. I've used this method before, and done correctly it can work seamlessly. A secondary method requires a drive to be mapped to a network share. The upload would then be saved to that share (located on the high bandwidth server). This is a rather simple solution if the servers are in your control (colocated, dedicated, in-house). This would not reduce the upstream load on the server, however it would transfer the downstream load to the high bandwidth server. A tertiary method requires a socket-based connection between the servers, and while this is now easy to do in languages such as ASP.NET, in Perl or PHP it probably isn't going to be as easy. Ultimately this has the same benefits and cons as the previous method, although there is a small reliability hit due to the socket-based transfer. It all depends on what you have available in front of you though. Server security is usually the biggest road-block in implementing a system such as this, since network shares, socket access and script execution aren't always enabled.

The fix: Dim pdDocument As PrintDocument = New PrintDocument() [b]pdDocument.PrintController = New StandardPrintController()[/b] pdDocument.Print()

This is a known issue. Consult the Microsoft support site.

'### Assuming: Option Strict On, Imports System.Data.SqlClient ### Dim oCommand As SqlCommand = New SqlCommand("SELECT * FROM

You shouldn't need any, I repeat any, Try/Catch blocks with that code. People rely on error handling far too much, when in fact simple logic checks will alleviate most problems.

Use the following examples as a basis: '### Assuming: Option Strict On, Imports System ### Dim dtCommencement As New DateTime(2003, 1, 1) Dim dtExpiry As New DateTime(2003, 12, 31) Dim tsTimespan As TimeSpan = dtExpiry.Subtract(dtCommencement) Dim iWeeks As Integer = Convert.ToInt32(Math.Floor(tsTimespan.TotalDays / 7)) If you do nothing else at least remove the calls to CDbl, DateDiff and DateAdd. Also, the Try/Catch block you have going is far too large.

Yes, it is both possible and ridiculously easy to do with ASP.NET. [mshelp=ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfSystemNet.htm]System.Net[/mshelp] [mshelp=ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfSystemNetSockets.htm]System.Net.Sockets[/mshelp]

There is no proper way to accurately check the internet connection status of a computer. I've kept my eyes open for a solution for years now, and I haven't seen one that works as it should-- reliably. And, if you think about it, the nature of networks, this really isn't suprising. With that said, there are a few Win32 API functions that you may want to take a look at: [api]InternetGetConnectedState[/api] [api]InternetGetConnectedStateEx[/api] [api]IsNetworkAlive[/api]

Visual Studio .NET and Visual Studio .NET 2003 are two different products. They can be installed at the same time. End story. The reason for this is Visual Studio .NET will only compile applications to version 1.0 of the framework, while Visual Studio .NET 2003 will only compile applications to version 1.1 of the framework. There is no way of changing this (in reason). However, you can change a compiled application's configuration file to tell it to run off a different version of the framework. There is no guarantee that the application will run, however.

You take a 64-bit integer value, convert it to a string, set a 32-bit equal to it (the string value) and then proceed to perform subtraction on a string value... You might, just might, want to rethink that very poorly written code.

The chat button now being displayed at the top of the Lite style isn't rendering correctly. Portions of the button that should be transparent are not. I have confirmed this in both Internet Explorer 6 and Mozilla 1.3.

System.Diagnostics.Process.Start()

For all intents and purposes "XML webservice" and "webservice" are one in the same. "XML" simply denotes that the webservice uses XML, which all .NET webservices and the majority of other non-proprietary webservices use as well.

DHTML in theory is a great tool, however in practice very few people actually get anywhere with it. I'd suggest investing in a server-side language such as ASP.NET or PHP instead.

By now we all realize that the Irish ale is getting to Merrion right about now, so if you'd like to see a similar concept without the crazy Irish rambling head on over to the terrarium. ;) Did I mention I'm part Irish? :)

Wow. I did something "kindly" for once. What a change... You can use the [mshelp] tag like such: [mshelp]ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfSystemExceptionClassTopic.htm[mshelp] [mshelp=ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfSystemExceptionClassTopic.htm]Exception class[/mshelp] ... which would generate the following: [mshelp]ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfSystemExceptionClassTopic.htm[/mshelp] [mshelp=ms-help://MS.VSCC/MS.MSDNVS/cpref/html/frlrfSystemExceptionClassTopic.htm]Exception class[/mshelp] The tags take a http://ms-help:// URI as input, which is easily retrieved from a local installation of the .NET Framework SDK or MSDN. As for what you're asking for? That would be rather tricky to accomplish, since mapping one word to its associated MSDN topic would be very tricky. With that said we could generate a working redirect script over time that could be added to. I can start one on EliteVB if you wish. Either that or we could work on a more user-friendly version of MSDN, hosted and updated by us. This of course would require community support, since we're all busy people.

For more accurate resolution you'll want to use the Ticks property of the DateTime class instead.

It's my understanding, if I remember correctly, that GetItemProperties should return the actual properties to be bound to. Say for instance you had a DataView-- you wouldn't want to bind to its properties, but instead bind to the properties of the DataTable it contains. With a simple collection though I don't understand why you would need to implement this. IList would be the more appropriate choice.

http://www.xtremedotnettalk.com/showthread.php?s=&threadid=49315

It is in no way proper to close a browser window unless it was opened by a web page as an auxiliary window. Either open an auxiliary window and close that, or deal with the all-too-appropriate security that's built into browsers. The fact that the user has your web page loaded doesn't give that page any right to control the browser it's being displayed in.

When a HttpSessionState object is cookie-less it stores the session ID in a query string that is passed from page to page as the user browses. If the HttpSessionState uses cookies the session ID is stored in a cookie that is sent to the server with each request. Those are the only differences. As for advantages of using sessions over cookies there are a few. The session object in ASP.NET is easier to use than the cookie collections, and it provides storage for any data type, not just string values. Data is also more secure since it isn't sitting unencrypted in a cookie on the user's hard drive. Sessions can be hijacked however, sometimes easily.

http://www.intel.com/intelpress/usb/examples/index.htm Intel provides examples for Visual Basic 6 which, depending on your level of experience with .NET, would be fairly easy to translate in a days work.

Set the field property Format to "0000000" (without the quotes).

The best way to store a password is not to store it at all. Store its hash value which can be used to compare user input with. See the attached file below for a Visual Basic .NET example of hashing a string value. hash.zip

If that is in fact the reason why you want to prevent the user from viewing the page's source I strongly suggest you remove the value attribute of the password textbox instead. There is no reason for that attribute to be present in the first place, and it shocks me as to why current browsers even support it.