PlausiblyDamp

What is the exact warning or error given by VS regarding these attributes? One thing the 2005 IDE does better than earlier versions of VS is validating your HTML correctly against the 'proper' standards - the errors may be down to the validation level set in VS's options or because of the DOCTYPE defined in the aspx page. As onfocus is a client side scripting function it should work as long as the client supports it regardless of the VS error.

One way to tell if a thread is completed is to implement a callback method - tell the thread's method the address of another function to call when it has completed, this will avoid the need to do any polling etc. Also if you do not need (or want) to keep track of the threads yourself you could look at using the ThreadPool class and let .Net handle the thread creation / destruction for you.

You should be able to handle the click event for the button within the control and then get this to raise an event defined by the control. The introduction of partial classes should really affect your ability to add an event handler, also rather than declaring a new delegate you could simply use the System.EventHandler if you do need to pass any information or if you do then .Net 2.0 also defines a generic to simplify the declaration (the name of it escapes me at the moment though ;)).

You could also store the numbers in a SortedList and use that as the datasource, the following code can replace the relevant section of your form. Private Sub btnClear_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnClear.Click lstMedian.Items.Clear() End Sub Private Sub btnExit_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnExit.Click Me.Close() End Sub Dim sl As New SortedList Private Sub btnAdd_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnAdd.Click Dim add As Integer = CInt(InputBox("Enter a value:", "Enter")) sl.Add(add, add) 'needed to get the display refreshed... lstMedian.DataSource = Nothing lstMedian.DataSource = sl.GetValueList() End Sub Private Sub btnDisplay_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnDisplay.Click Dim median, first, last, find As Integer first = 1 last = lstMedian.Items.Count - 1 find = Convert.ToInt32((first + last) / 2) MessageBox.Show(find.ToString) End Sub Also you might want to decalre variables as the correct type rather than Object whenever possible as it allows the compiler to do a lot more error checking for you - I would always recommend adding Option Strict On to the top of every source file. Just another quick question - are you using the listbox as part of the UI or was it only intended as a way to sort the data itself?

http://weblogs.asp.net/scottgu/archive/2005/12/07/432630.aspx might be what you need then.

Private Sub btnAdd_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnAdd.Click Dim add As Integer add = CInt(InputBox("Enter a value:", "Enter")) lstMedian.Items.Add(add) End Sub the above code worked fine when I used it to items to the listbox.

Could you post the code, it really helps people to find problems.

From what little I remember of Java you will also have to make do without enums and delegates as well.

What type of database are you wanting to convert to?

I was wondering if you felt like sharing the code with us - makes it a lot easier to understand the problem. At a guess I'd say you are adding the items in as strings - hence the listbox is sorting them as strings. Try converting them to a numeric data type and then adding them to the listbox.

The code snippet you use in point 2 is more to do with anonymous types than generics, from what I have seen I would tend to stay clear of them in general anyway. Using var with generics doesn't seem to be too bad of an idea and can remove a level of duplication that can result in easy mistakes later //following requires the type to be specified twice, if int needs to be changed to long //for example I need to change it in two locations MyShortName foo = new MyShortName(); //only declare the type once var foo = new MyShortName();

A dll is going to expose classes to other applications, it's these classes that implement the interface(s) not the DLL itself. Not sure how each class that is required to implement a particular interface actually implementing the interface is likely to cause confusion though...

You could always return a byte array containing the contents of the document and leave it up to the client to decide what to do with the result (Save to disk, use internally etc.) Web services are based on standards, if you follow the standards then any language / tool / platform can work with you, you can also work with web services developed in other languages just as easily.

If you output the result of GetPixel to the debug window does it produce sensible values? Also are you sure the Messagebox isn't causing problems by changing the active window to itself.

You could create an interface that inherits the other smaller interfaces and then have the class inside the dll implement that interface - that way it can still be used where ever any of the interfaces are required also.

How are you populating the listbox?

The while loop increases the code to 8 code lines compared to the original 5 (ignoring whitespace etc.), adds an extra variable and increases the complexity of the escape expression and requires you to perform a manual increase on both loop counters rather than have the for loop do this implicitly. Personally I find the use of goto in this situation provides a smaller code base with less likelyhood of simple errors (transposing i and j for example), and less likely to result in differing styles of code - note how the !requirmentMet appears as the 1st operand in one if statement and as the second in the other if statement in your sample. Admittedly bickering over a couple of lines extra on such a small amount of code is petty (I never claimed I wasn't petty though ;)), however the alternating style of checking is either going to result in increased time to be consistent when writing the code or possible confusion when reading the code when the amount grows beyond what will comfortably fit on a single screen of information. As a rule I would avoid the use of goto but that doesn't mean they do not have a valid use on occasion, and as long as the comments etc. explain and document the logic then I don't see a problem. I most definately agree that code that relys heavily on goto will lead to difficult to maintain code especially if the flow is jumping up and down the routine. Jumping into a looping construct. Jumping into the middle of a flow control block. Jumping out of the current subroutine (for languages that support this) however in this case one (or even a few gotos) that all jumped to a well named label immediately after the loop block isn't that hard to follow. As I said before I would tend to be wary of any rules like this given as absolutes i.e. 'Never use goto' or 'Only have a single exit point from a function' as there are times when these rules do not benefit the code in any real way and breaking the rule will give cleaner more readable code.

Out of interest a better alternative (IMNSHO) to the Crownwood library can be found at http://www.divil.co.uk.

iWidth = Math.Abs(e.X - pSelStart.X); should do the trick

The type of output is decided by the dropdown on the toolbar - Debug and Release being the default. The bin directory is the final output of the build process, the obj directory is a tempory location that the files are generated in during the build process.

At the end of the day the decision to use any language feature is a trade off between learning how to use the feature properly and as a result knowing when to use it and deciding to stick with what you know. Knowing when to stick with an existing feature rather than use a new one is a very important skill in an industry where 'new = good' (or 'new == good') seems to be the overriding mentality - as long as there is a justifiable reason for not adopting the newer features. In a language like C# or VB there is already a certain amount of redundancy in the language, i.e. why have a switch (select ... case in VB) statement if a simple 'if ... else if .. else' could do the same thing? Why have 'for each loops' or 'for next loops' if a while loop can do the same thing? When these things are used correctly the overall maintainability and readablility of the code is improved, used badly, badly or just plain oddly then readabilty suffers also. I can definately see where you are comming from but I tend to see these new features as things that can make my life easier if used correctly. As long as the tools keep pace with these additions then a lot of the confusion should be removed by compile time checking, intellisense, improvements to FxCop etc. In your own code, be it as an individual or as a team, adopting sensible naming schemes and practices will go a long way to mitigating the confusion, as will simply avoiding things you either do not need (lambda expressions being the one feature that springs to mind)

Under .Net you are always running as an exe regardless of how the application was launched. However you can always check System.Diagnostics.Debugger.IsAttached to see if a managed debugger is attached to the process. Another thing to be aware of is the difference between Debug and Release builds of software and how that can affect run-time behaviour.

Goto is probably your best option in this case. Be careful of blanket statements like 'goto is bad' without qualifying why or when - if goto was that bad a construct it wouldn't be needed in C#. With decent OO design goto will normally result in harder to read / maintain code, if however it's use can be justified i.e. it produces the cleanest code to suit the task at hand then use it.

Any chance you could post the code you have so far? If you have implemented the DB code as c# but within your aspx page then it isn't that difficult to move it to a code behind model.

It seems to be related to the problem mentioned at http://support.microsoft.com/Default.aspx?id=826757, oddly enough I don't remember the problem occuring in 1.0 of the framework. On some PCs I've had it work fine, others fail...