Derek Stone

You should use the ExecuteReader method instead. Keep calling its Read method (which truncates data beyond 4K) until all the data is read. You can retrieve the data using GetString(0).

You can't jump to anchors from the server side. The page either has to be requested from the browser with the specified anchor to jump to, or a JavaScript function needs to be used instead.

Regardless of what you want to use an ActiveX control for there aren't any "good suggestions" as to how to go about it. ASP.NET has very little to do with ActiveX anymore, and you'll have to use the same old techniques as with vanilla HTML.

Controls that are declared with their runat attribute set to "server" should not be access with the Request.Forms collection. They should be accessed using their control name. Dim s As String = hid1.Value You should also remove the name attributes that you have defined.

.NET value types (integers, bytes, booleans, etc.) cannot be null. SQL Server parameters and the .NET object that wraps them, SqlParameter, can be however, since they are wrappers to the underlying types. You'll need to set the parameters IsNullable property to true prior to passing in a null value. Dim p As SqlParameter = New SqlParameter() p.SqlDbType = SqlDbType.Int p.IsNullable = True p.Value = Nothing command.Parameters.Add(p)

Carriage returns and line feeds have no significance in HTML. You'll need to convert them to break tags. <br />

I started developing the software in quarter one of this year and it's progressed slowly but surely since then with the help of Garrett and Simon. The software is not a conversion of vBulletin by any stretch of the means. The only similar attribute is the interface, and even that is bound to change. Of course many of the features will be the same, as is the case with all bulletin board systems. The effort is to provide these (and other) communities with software that feels somewhat like vBulletin, to ease the transition between the two, yet offer a faster, more secure and more scalable solution that runs on the .NET platform (this includes Mono, although that is not the focus). The most current release (WCP20030921170000) is now running at the following location: http://www.elitevb.com/forums/. Keep in mind the software is still in its pre-alpha stage, so don't expect too much feature-wise as of yet. Comments, suggestions and tactfully phrased insults are always welcome. :) If you are interested in tracking the project's development or interested in helping out you can join the project workspace; a link is provided at the address above.

Visual Studio .NET 2003 can only compile .NET 1.1 applications. You can instruct the assembly produced by Visual Studio to load to either framework, however this has little to do with the behavior of Visual Studio and it is not recommended practice.

If you honestly think obscuring ID numbers can be considered security then I really hope you re-evaluate your security policy sometime soon. I say this with the best intentions: you're going to get bit in the rear if you don't. You should be using query strings AND checking upon each and every page request that the user has the correct level of authorization to access the resource. Doing it any other way is risking usability and security. Tough answer, I know, but you might just thank me someday. :)

Well, I hope to have something for the two communities by the beginning of the new year, at the latest. Hopefully at that point all issues, both personal and technical in nature, will be resolved and we can usher in a new era for these forums, as happened before a few years back. Granted I can't speak for Bob or these two communities at an official level, so we'll just have to wait and see what transpires. :)

The simple way would be to just use query strings. Applications like this are exactly what they were designed for. For whatever reason you have stated that you don't want to use them, however I don't foresee myself passing along advice to do things the incorrect way. If you want to use Context.Items and Server.Transfer then so be, do just that. Context.Items.Add("variable", "value") Server.Transfer("page.aspx", True)

If the need is great enough you may want to switch to Norton AntiVirus, which allows individual scripts to be authorized.

As Nerseus has said, this has nothing to do with .NET and everything to do with your Windows settings.

If you're asking for resources that's fine, but we won't be coding it for you. Ask specific questions on specific topics and you'll find much more assistance, both here and on any other forum online.

You'll need to use [msdn=System.Web.UI.Page]Page.RegisterClientScriptBlock()[/msdn] or [msdn=System.Web.UI.Page]Page.RegisterStartupScript()[/msdn].

It all depends on how the second page is requested from the first. If the first page is being posted to the second then there is no need for Context.Items, and a hidden form field can be used quite nicely. However if the first page can only use Server.Transfer to request the second page (if so you need to ask yourself why this is, since it is the bigger issue) then a form would never be made available to the client to post, and the data would never be transfered. You need to thoroughly explain how things work within this portion of your application before we can help you out any further.

I'll whip up an example within the next day or two. If I forget remind me via PM.

It would make sense then to add a PlaceHolder to the location in the page flow where the dynamic controls should be placed.

You'll need to define mutiple overloads of RtlMoveMemory in many cases. Most of your other API related questions are answered in VB.NET: Platform Invoke.

There's nothing to close. The DataSet is a client-side-only object with no connection open to a database. With that said, you may wish to call the Dispose() method, which will aid the garbage collector in freeing unused resources.

Why don't you just store the value directly into the hidden form field in the first place? I don't see why Context.Items even needs to come into play.

Use the Page.Controls.Add()/AddRange() methods instead. You do not need to use FindControl().

SSL has nothing to do with ASP.NET. It's configured from within the Web server's options, and acts independently of all higher layer protocols. You'll need to acquire a certificate from a root provider and then consult your Web server's manual for instructions on how to install it. In IIS, this is quite simple.

SendKeys relies on the window to be focused and active, an assumption that simply shouldn't be made by any programmer wanting to develop a solid application. Calling SendKeys may fail, while SendMessage is ensured to succeed.

You need to ensure the correct permissions are set on each client machine, not just the computer the application was developed on.