PlausiblyDamp

Could you show what code you have so far? What language are you using VB / C#?

You will probably find the classes under System.Collections for more useful and functional than the VB Collection class anyway. Plus if you are using .Net 2 the System.Collections.Generic namespace is a dream come true.

If you are using .Net 2 then the classes System.Net.FtpWebRequest and System.Net.FtpWebResponse should do the trick. If not search these forums - I'm sure someone posted an FTP wrapper class a while ago.

A XSD simply defines the structure of an XML file - it doesn't contain any actual data itself. http://www.w3schools.com/schema/default.asp has a basic tutorial / overview of what an xsd is - well worth a read. .Net provides a utility called XSD.EXE that can generate a code model based on a XSD file.

Problem with creating your own controls is you end up with a lot of duplication - TextBoxes, RichTextBoxes, ComboBoxes etc. all look like textboxes to the user but don't have a common base (not without going all the way back to Control) you can inherit from - you would need to provide similar functionality in each type of control. This gets worse if you are also using 3rd party controls as you would now have to inherit from these as well and provide your own functionality. An extender is a pretty good way round this once you figure out how they work (this can take some doing ;)) as a single extender can affect multiple control types and isn't restricted to only the controls you can be bothered creating.

You might find creating a class / component that implements the IExtenderProvider interface (Tutorial Here), this could then intercept the events of other controls on the form and toggle the menu items based on the type / contents of the control or clipboard. Extenders can also expose properties that extend another control (e.g. the ToolTip control), this would allow you to also enable / disable this functionality an a control by control basis or even provide other customisations to the IDE.

Edit : ignore me and read mable_eater's post instead. You would need to use the MeasureString function provided by the graphics object to discover the height / width of the string - if it is wider than the available space you would need to draw part of the string and then draw the rest on the next line.

Have you tried repairing your VS install?

The code you posted looks ok - did you try it and see what the output looked like?

http://www.pinvoke.net/default.aspx/shell32/SHChangeNotify.html might be worth a look.

Visual studio - can be found http://msdn2.microsoft.com/en-us/vstudio/aa718332.aspx

In SQL 2000 the maximum size a single row can hold is approx 8k (8060 bytes being the exact value). Although an individual field such as a varchar, char etc. can hold up to 8000 bytes you are still held to the maximum of 8060 for the entire row. i.e. If you have a table CREATE TABLE Test { FirstName varchar(8000), LastName varchar(8000) } The total number of bytes you can use is 8060 - even though it looks like you could reach 16000 (8000 per field).

If you install the service pack you get an alternate way of building / deploying web applications - it is a lot more like the vs 2002 / 2003 way of doing things.

http://www.xtremedotnettalk.com/showthread.php?t=83092 contains examples of how to do this kind of thing in VB while http://www.xtremedotnettalk.com/showthread.php?t=97057 offers tips on how to port vb code to C#.

The sitemap is simply the logical structure of your site Rather than hard code links into every page (or rely on on server side code like response.redirect or server.transfer) to manage the navigation the sitemap defines this structure. You would then use it alongside a sitemap datasource and either a menu or treeview control on your pages. I would recomend you look at the 'Personal Web Site Starter Kit' that ships with VS as it includes a sitemap along with a menu as part of the masterpage that should give you an idea of how they work.

If the method or property is an instance method (i.e. not static - shared in vb) then you need to create a valid instance of the form before you can access it. If Form1 is a variable then it will work - if Form1 is a class you will need to create an instance of Form2 and use that.

If you are using .Net then try the string methods for comparisons etc. rather than the VB style ones. The .Net 2 methods allow you to specify the compare options you need i.e. ihit = strOriginal.IndexOf(strQuery, StringComparison.CurrentCultureIgnoreCase) this will prevent errors where upper and lower case cannot simply be converted and should be more reliable.

You really should only have one place where the connection string is defined - that would be your DAL. The web service would call into the DAL and request data but the DAL itself would be responsible for managing the DB connection and any commands etc. that need to be executed. The web service would never need to access the DB directly. You might want to split the Business Logic from the Data Access by putting each into it's own DLL - this will allow you to potentially replace either the DAL or BLL at a later date without having too great an impact on the other components in the system.

Not really, you could install the DAL / BLL into the Global Assembly Cache (GAC) on the webserver hosting the webservice but it will still be on the webserver. It is technically possible to store the dll on a network share and access it from the web server - however it isn't a simple job and the end result is likely to either compromise security even more (the web server now loads it's dlls from an arbitrary network share which could be less secure that the server itself - this being a potential security issue), possibly fail to work if there is a firewall between the web server and the file server with the DAL / BLL shared out (changing this configuration is again likely to cause further security implications). Even if you overcome these obstacles the code contained in the DLL is still going to be executed on the web server anyway - and as such has exactly the same security implications (or even worse as you will probably need to alter the CAS policy to give this file server FullTrust) as if it was physically stored on the server. It might be easier (or worth trying anyway) to see how set in stone the Admin's policy of nothing but .aspx files on the server is (especially considering the fact a web application or service will contain other files anyway - web.config, web.sitemap, ascx files, asmx files and quite possibly one or more dlls in the bin folder anyway).

If you already have an exisiting database containing all the accounts it might be easier to just use it as it is rather than converting it to the format expected by ASP.Net 2.0 - you would need to create your own providers though. Specifically you would need to create a membership provider and a role provider; http://msdn2.microsoft.com/en-us/asp.net/aa336558.aspx is the offical MS toolkit for this (including the source code to the built in providers). http://www.codeplex.com/Wiki/View.aspx?ProjectName=AltairisWebProviders may be worth a look as it contains a simple example of what you are after plus associated documentation.

Could you post the code for the form's load event or which events you are creating and disposing of the InkOverlay class?

Have a look at http://msdn2.microsoft.com/en-us/library/ms833057.aspx - just after the syntax declarations it warns you make sure you explicitly call .Dispose on any instances of the class to prevent a handle leak. Might be worth doing that and checking to see if the problem goes away.

You would basically need to use the same code to recreate the buttons on each page refresh including postbacks, try moving the GetControls("NULL") call to after the check for IsPostback.

That sounds fine - it's just that if the webservice references the DAL / BLL then the DLL will need to be available to the web service, this normally means it will be in the bin folder of the webservice itself.

The architecture itself sounds fine, the only real issue I could see from your original couple of posts is how the web service talks to the data layer.