PlausiblyDamp

You should be able to create a class library - easiest way if do file -> new projects and see if it is listed as a project type.

in the DataForm3 you could add some thing like Private Shared _IsOpen As Boolean Public Shared ReadOnly Property ISOpen() As Boolean Get Return _IsOpen End Get End Property in the form load event add _IsOpen = True and in the form closed event add _IsOpen = false in the code that creates the form you can now use code similar to if DataForm3.Isopen = false then 'donothing else 'create form here end if

Problem with optional parameters is they're no supported by all .Net languages. What happens is at compile time the default parameters are compiled into the calling application - thus if the defaults change in the DLL all cliens need to be recompiled.

Rather than copy all 70 lines of code you could do something like Private Function DoIt(ByVal strDefault As String, ByVal strString As String , ByVal strSecond As String) As String 'Whatever code for the function goes here End Function Private Function DoIt(ByVal strDefault As String, ByVal strString As String) As String DoIt(strDefault,strString,"") end function Private Function DoIt(ByVal strDefault As String) As String DoIt(strDefault,"","") End Function (nicking dynamic_sysop's naming convention there ;)

Any reason why you want to avoid overloading in this case? Optional arguments can have odd side-effects when mixed with other .Net languages or used in DLLs.

Best thing is have a look at ASP.Net authentication, plenty examples in the MSDN library and on microsoft's website. Forms authentication pretty much does what you describe.

Is the windows 2000 server part of a domain? Also are you running the WebApp using the default ASPNET account or impersonating another user? Whatever account the app runs as will need permissions to access AD. (probably)

in the codebehind declare the variable as protected, rather than private.

In the forms designer if you select a control and look for the properties Anchor and Dock - not the most powerful but can make resizing logic quite easy.

DataAdapter.UpdateCommand.CommandText - should be the SQL command being executed.

In your original post you did mention a sample project involving an Access Database hence the reason I mentioned MSDE not being required for Access development. If you are developing for SQL Server then you will need access to either a MSDE or SQL Server based database - in which case the downloadable version would be a valid option. As to the issue of Visual Studio 2003 Standard Edition (Professional?) supports ADO.Net then the following link from MS indicates that it does. http://msdn.microsoft.com/vstudio/productinfo/features/profeatures.aspx if the samples are opening an Access Database or a SQL database you may need to look at the ConnectionString being used by the samples.

You shouldn't need MSDE to develop applications in MS Access. MSDE is a SQL Server compatible database engine and doesn't (shouldn't?) have any impact on other databases.

Personally I was refering to the part of the message, as far as I'm aware System.Data is a fundamental part of the .Net framework and as such I can't see any reason why not.

Could be a video driver issue, have you kept you drivers up to date? (or just updated them to a new version?)

Could you post the code in question please? Much easier to answer that way

What exactly is the problem you are having?

Not sure if WinZip can be used that way, although you can download a command line version of winzip from http://www.winzip.com - that most definately can be used this way. Also http://www.icsharpcode.net have a free zip library you could use as well, works very nicely in fact.

Generic handlers can be useful if you have one handler for multiple events (Save button, save menu etc) that all require the same end result. They can also be very useful when similar logic is required for multiple events (Text1.Changed, Text2.Changed etc) as then a single handler can cover most of the logic by using the sender object. If one handler is trying to do too much work though it can easily end up as a monsterous Select Case statement trying to call the correct bit of code based on multiple parameters (bit like handling windows Messages in a C application) Also one event can have multiple handlers, so a single button click could cause 2 or more event handlers to fire... If it makes sense to use one handler - do so :) If it makes sense to use more than one - do so :) If it makes code harder to read or maintain - probably don't do so ;)

I don't think there is a way to find out what kind of event fired, is there any particular reason why you would want to handle different event types for multiple controls in a single event handler?

Process.Start should do the trick. look for it in MSDN or search the archives, plenty examples

All ASP.Net applications execute as the user ASPNET, it is created as part of the framework installation. You can give it permisions to the database through SQL Enterprise manager

Although you as a user may have permissions to the database, by default ASP.Net applications will attempt to connect as the account ASPNET. You either need to give this user permissions to the database or look at getting the WebApp to impersonate the calling user.

How are you creating / displaying the form? Also what version of the .Net runtime are you targeting with the VS 2003 form? It could be a problem with the DLL requiring the 1.1 runtime and the project using version 1.0 framework.

What character set is the webpage encoded in? you may want to try replacing the line s = Encoding.ASCII.GetString(b) with one of the following s = Encoding.Unicode.GetString or s = Encoding.UTF8.GetString

It could also be a permission problem, IIRC then the \System Volume Information folder has very restrictive permissions applied.