Derek Stone

Convert the string to a byte array using the System.Text.Encoding.GetBytes method.

Give the cookie an expiration date and time.

Dim sBase64 As [msdn=System.String]String[/msdn] = [msdn=System.Convert]Convert[/msdn].ToBase64String(sendBytes4) ... should work just fine, assuming that sendBytes4 is not a null value.

Make sure to close the stream afterwards.

[msdn=System.Diagnostics.Process]Process Class[/msdn] [msdn]System.Diagnostics.Process[/msdn] [edit]The above do not work, as you have stated. I'll look for the problem as soon as possible. Thanks for letting me know.[/edit] [edit]The problem is now fixed. Thanks again.[/edit]

I'd use that code example. It's straight from Microsoft, which usually is a good thing. Others can be found on Google: http://www.google.com/search?hl=en&ie=UTF-8&oe=UTF-8&q=serial+OR+comm+port+vb.net

There are plenty of .NET classes available online for accessing the serial port. I'd avoid COM problems and dump the MSComm32 control altogether. COM Exception 80040112 is a licensing problem, just to confirm that statement.

I'm guessing you included parenthesis after the namespace and class. This is not handled as of yet. For the time being enter parenthesis after the [msdn] tag. [edit]The utility doesn't support methods yet anyway. Only namespaces and classes.[/edit]

Try the ReadXmlSchema method. It takes a file name or a stream as its only parameter. The schema should be XSD of course. The DataSet will then apply the schema and enforce the constraints and relations as they are defined.

The query builder is a piece of garbage. I don't know how else to put it to you. Try generating your SELECT statements by hand.

VBulletin opens internal links in new windows, which there is no reason for it to be doing. This is unacceptable, and you won't find too many people to argue against that. Of course vBulletin also opens external links in new windows, which is slightly justified, if not still a huge annoyance. I wouldn't bring it up if only external links opened in new browsers, but personally I find the lack of the control that a user should have... well, just that-- lacking.

It really is improper to open a new window everytime a link is clicked. The user always has the option to open the link in a new window (by pressing shift or by right-clicking on the link). This is one part of vBulletin that I don't care for.

Alright. I have an ASP.NET page running on our server which translates a fully-qualified class name or a namespace into its associated reference document on MSDN. This utility is limited, since it will not except a class that isn't fully qualified. For example, the utility will accept "System.Environment" but not "Environment". I don't see this as much of a problem, although I will work on a solution to allow for short class names. If an administrator could create a vB Tag for this utility it would be great. The utility is located at the following URI: http://www.elitevb.com/tools/msdn7itr/ It can be used like so: http://www.elitevb.com/tools/msdn7itr/?item=System.IO http://www.elitevb.com/tools/msdn7itr/?item=System.Environment As Merrion suggested, I think [msdn] would be an appropriate name for the tag.

How do you expect to catch an object's event without even having a reference to the object? The point is you cannot, as the two gentlemen above have pointed out through their examples.

I like your database example, Nerseus. Explains my point rather well. I can't agree with this logic, however. (see below for argument) I can't agree with this either. Take the AutoRecover feature in Microsoft Word. This is an excellent example of an application working correctly to prevent large amounts of data loss after an unrecoverable error has occured. For example, the exception thrown by Word caused the document buffer to be overwritten. If the exception was "handled" (I use this term loosely) the user would continue working, adding to the overwritten buffer. The buffer would contain invalid data however, and once the user saves the document he/she has lost quite a bit unknowingly. Had the application crashed, AutoRecover would have kicked in the next time Word was reopened, allowing the user to continue where they had left off (or close to it). It boils down to either taking a huge risk, putting a whole document on the line, or a small annoyance, restarting the application. Obviously the latter is a much better option.

No, but you'll want to call the Close method of your OleDbConnection.

This is ugly in my opinion, as it boxes and unboxes objects, but it does provide the one-line functionality that C#'s short-circuited if provides. Private Function RemoveNull(ByRef o As Object) As String Return Microsoft.VisualBasic.Switch(o Is Nothing, String.Empty, Not o Is Nothing, o).ToString End Function

It all depends. You can use the DISTINCT keyword to ignore duplicates, a SELECT statement to check for duplicates or a DELETE statement to get rid of them. We need more information on what exactly you need to do.

Change the Astring declaration to make it static: public class Globals { public static string Astring = "Joe"; } Then access it from your forms like so: label5.Text = Globals.Astring;

You'll need to submit the value to the server via a form field or a query string value.

The System.Environment.SystemDirectory property is as close as your going to get, I believe.

Generally speaking if your code is erroneous you should fix it, not hand over its problems to a Try/Catch block. Some errors can arise due to reasons out of our hands, and accessing MS SQL Server is one of them. That doesn't mean that all errors in that block should be handled however. In your case only exceptions of type SqlException should be handled, since all other errors are most likely the result of poorly written code.

You can return the root namespace with the following: project.Properties("RootNamespace").Value I don't believe individual project items (within the DTE scripting system) have namespace properties however.

"Quick Reply" was added in as a hack to the software. Therefore any inconsistencies are hardly the fault of Jelsoft, the creators of vBulletin.

I'd also change "Exception" to "SqlException".