PlausiblyDamp

1 - All .net applications require the .net runtime to be installed, IIRC windows 2003 comes with 1.1 as does SP2 for XP. Vista ships with version 3. If the users are installing updates via windows update then they will probably have the framework installed. 2 - For networking the framework provides the System.Net and System.Net.Sockets namespaces - each with a lot of classes to handle various network related functionality. There are various examples on these forums or on MSDN itself about how to use the classes, or if you have specific questions just ask ;) 3 - Converting VB6 to .Net is a bit of a pain and the conversion wizard that ships with visual studio is next to useless; unfortunately it is pretty much learning a new language and framework :( http://www.xtremedotnettalk.com/showthread.php?t=48270 is worth a glance as it does highlight some of the more obvious changes. 4 - A .net application should exit when the last thread (of running form) is closed, although Application.Exit works it has 'issues' regarding clean-up code etc. not being run and is something I would personally avoid using.

You might try using the STR function in SQl to format the integer - not tried this personally but it might help. Failing that it might be easier in the long run to handle the formatting in the UI rather then the DB anyway as databases aren't really the most suitable tool for this kind of thing.

What happens if you set the option to 'Use Default Server'?

If there is any real doubt then I would opt for the more obvious text link rather than a graphical image, if possible try and get some potential users to have a go with one or other of the two designs and see if either causes problems.

Personally I found the service pack made VS more stable and slightly more responsive, however given the size (400+ MB) there must be a fair few fixes that are worthwhile applying. Be aware the service pack is so large it can fail to install, http://support.microsoft.com/kb/925336 gives the details and the pre-patch patch you need to apply.

How are your creating the items at runtime? Just tried it here and it seemed to highlight the entire row in both cases.

It might help if you showed what code you have so far - displaying 1/4 (U+00BC) works fine in a messagebox and to the console here (are you using a font that does support this character?) without any problems. As far as writing out to any type of text file (xml or otherwise) then make sure you are using an encoding that is Unicode. Also for xml files ensure the declaration agrees with the encoding type used as differences between them can cause problems.

I would use the KeyPress event rather than the KeyUp / Down as you get the actual character with the press event.

I've just tended to check with Char.IsLetterOrDigit

Could you not just deploy the site to IIS and debug it that way? Do you have the correct permissions to IIS to actually allow debugging?

Would http://msdn2.microsoft.com/en-us/library/system.drawing.rectangle.union.aspx not do the job?

There should be no difference between catching Crtl+F or a Ctrl+J; both worked on this pc in fact. Is there some other application running that has already installed a hook for the Ctrl+J combination?

Is your web application hosted under IIS? If so then that just needs to be the base url to the application (in your case http://localhost/CMS is probably correct). For this to work though your web site will have to be copied to a folder that is hosted under IIS as a virtual directory though.

Just to clarify - are you trying to use a COM based windows control in a web application?

Just tried it here and it worked fine - what is the contents of the variable Input when you are getting the error? If the string doesn't contain a space it will probably fail...

You could loop over the items in the first array and do an Array.Index of against the other array until a match isn't found.

By binary to you mean non-text or some (any?) specific binary file type? Is there a reason why you don't want to use the extension to determine the file type? The one fundamental problem you will encounter is that ultimately files are just bytes on disk and as far as the file system and the file IO routines are concerned there is no difference. You could scan the files looking for bytes with a value larger than 127 and hope it isn't a text file using an ANSI code page that does have characters in the 128 - 255 range or a Unicode file... You could search the file and try to match known headers (http://www.wotsit.org/ is worth a look if this seems a good route to take) however there are probably thousands of file formats with potentially more being added every day. It might be easier if you gave a bit of detail about what you are trying to do.

The debugger may be running at runtime but so is the runtime ;) if you were to write code like MyClass m = new MyClass(); IMyInterface obj = m; IDisposable d = m; then the memory for a new instance of MyClass would be allocated from the heap and the three variable m, obj and d would all point to exactly the same place (effectively they would contain the same memory location as their 'value'); the runtime however is fully aware of the associated type information belonging to the object in memory - including base classes and interfaces supported (this is how runtime casts and conversions are validated at runtime after all). So although the IMyInterface via the variable obj doesn't implement the IDisposable interface the underlying object (m) itself does and this is what is being checked at runtime when any runtime cast is performed (IDisposable or otherwise). When looking at casting and type safety the compiler and the runtime have different sets of information to work with; the compiler can only go off the statically hard-coded information such as the declared types and hard-coded casts - if we declare a variable as being IMyInterface that is all the compiler can ever know about it. The runtime however has access to the actual instance of the object and can interrogate the full set of metadata which includes the full list of types derived from and interfaces implemented. At compile time obj =(IMyInterface) new Form(); is perfectly valid - the compiler is taking our word that a Form implements IMyInterface at runtime however it results in an InvalidCast exception based on the runtime type information of a Form. As to the idea of a temporary variable being introduced by the compiler - they do that sort of thing all the time, and in this case it is nothing more than another 'pointer' to the real underlying object anyway.

You might need to give the NT AUTHORITY\NETWORK SERVICE group write permissions to the C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files folder, if the error keeps occurring it might be a configuration issue on your network (perhaps your admins are managing the permissions via a GPO and not taking asp.net applications into account.)

Ultimately the actual object in memory is of type MyClass and IDisposable and IMyInterface (and Object if we are being strict on things) regardless of the type we have assigned to the variable obj - the compiler simply enforces that the type we choose to treat it as is supported by the object itself. Hence we could have decalred obj as Object, IDisposable, IMyInterface or MyClass without problems but any other type would have failed. The .Net runtime always knows the actual object / interfaces supported at runtime regardless of the variable declaration (if you put a break point on the line IMyInterface obj = new MyClass(); notice that the various debug windows show obj as being of type MyClass rather than of IMyInterface. Declaring a variable (or parameter) of type IMyInterface simply indicates how we currently wish to interact with this object, the compiler and IDE help through use of intellisense and validating data types and method names etc. but this doesn't change the type of object we are dealing with - just how we are currently perceiving it. When we use the syntax using (obj as IDisposable) the end result is the same as if we had done something like object o = obj; IDispose id = o as IDisposable using (id) If obj (or o as it points to the same place) point to an in memory object that supports IDisposable then id will point to a valid object with a valid IDisposable implementation. Using your example with obj2 which doesn't implement IDisposable then the code object o = obj2; IDispose id = o as IDisposable using (id) would result in id being null; effectively the equivalent of using (null) { //.... } which, although pointless, is still perfectly legitimate code that compiles and runs without problems. Notice none of the obj as IDisposable or similar lines are actually changing what obj points to so it is never being assigned a null value - if you tried that with code similar to IMyInterface obj = new MyClass(); obj = obj as IDisposable; using (obj) the compiler will prevent compilation due to the clash of data types.

The compile should enforce the fact that the object implements IDisposable, this isn't a runtime check. The line code obj as IDisposable however will attempt to cast obj to IDisposable at runtime and return either a valid instance of the interface or null if obj doesn't implement IDisposable. As far as the compiler is concerned though it acts as if the cast will always work and behaves correctly regardless - the compiler generated equivalent to the using statement is pretty much try { //use obj here } finally { if (obj != null) obj.Dispose(); } so even when the cast results in null the issue is dealt with anyway.

http://msdn2.microsoft.com/en-us/library/system.environment.specialfolder.aspx

Use Environment.GetFolderPath( Environment.SpecialFolder.ApplicationData) and it will work regardless of OS or configuration differences.

TextBox1.SelectedText = "My Text"

Is there a requirement to use the paste functionality at all? If so copying stuff to the clipboard removes the existing contents - this is how it is designed to work. Could you not just assign the value directly to the text property?