PlausiblyDamp

Easiest way would be to inherit from the button class and then internally track the number of clicks and the textbox to be modifying. Something like the following should get you started... class ButtonSample : Button { private int _ClickCount; public TextBox TextBoxThing { get; set; } protected override void OnClick(EventArgs e) { base.OnClick(e); if (TextBoxThing == null) return; if (_ClickCount >= 2) _ClickCount = 0; switch (_ClickCount) { case 0: TextBoxThing.Text = "First text string"; break; case 1: TextBoxThing.Text = "Second text string"; break; case 2: TextBoxThing.Text = "Third text string"; break; } _ClickCount++; } }

Re: Pick two and swap! If the data is in an array you could also use Array.Sort with a bunch of random numbers as the key int[] numbers = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10}; Random r = new Random(); byte[] b = new byte[numbers.Count()]; r.NextBytes(b); Array.Sort(b, numbers); although for large array numbers using a byte as a random key might not be random enough.

If they are in the same project then the easiest way is probably for the sample1 form to expose a method which returns a collection of all the controls on sample1 and call this method from sample2.

Have you tried creating the parameter and then setting it's value before adding it to the parameters collection? Also the parameters collection has a .AddWithValue method that might work. You really want to avoid concatenating strings though as this can cause all sorts of odd security risks and is generally a bad practice.

You could create your own button control by inheriting from the existing button class and then adding any functionality you require. Not entirely sure what you are trying to do from your sample though. Are you just looking to have one button that will update a textbox to one of two states depending on how often it is clicked?

IIRC the OleDb provider doesn't support named parameters, you just add the parameters in the correct order and do not bother to specify a name.

Could you not convert the second window to a user control and add a tab control to window 1 - then either instantiate different versions of the control in each tab or simple change the style associated with the control when the tab is changed.

What data type is Results? If it is already a string then you can drop the .ToString calls on it - other than that it is pretty much the correct way.

Strings will be garbage collected so you don't need to do anything with them, if you are only using strings then there is no need to implement IDisposable in your class at all.

Have you tried assigning the paths to a variable so you can inspect them at runtime in the debugger? It could be a case of the paths not being correct.

This can happen if you have the option to auto wire up events set in the @Page directive and if you are also manually attaching the event handler in code.

Have you tried manually calling Flush on the StreamWriter before disposing of the underlying stream, just to see if that makes a difference?

ADODB is still using the ActiveX Data Objects rather than the ADO.Net providers, this means you will still be using the same classes (Recordsets etc.) that you were using in VB6. This isn't really using the .Net libraries though and many of the data binding features in .Net aren't designed to work with the older COM based methods. The actual ADO.Net providers are found under the System.Data namespace (e.g. Sql is SYstem.Data.SqlClient) Regarding the 2nd question you have a couple of options - you could always use the OleDb providers (System.Data.OleDb) or alternatively you could write your code based around the underlying interfaces (IdbConnection, IdbCommand etc) and generate the correct type at runtime - if this seems a likely option then I can dig up some sample code. Depending on the version of .Net you may also want to investigate the Entity Framework as another option.

You could try getting the handle to notepad with something like Process [] notepads=Process.GetProcessesByName("notepad"); IntPtr notepad = FindWindowEx(notepads[0].MainWindowHandle, IntPtr.Zero, "Edit", null); [code=csharp] and see if that helps.

On the occasions that fail is p a valid handle? It might be a case of trying to get the handle before the window has been created.

If you are lookin at printing everything yourself then you are pretty much stuck with managing the layout entirely - all the sizing, measuring and positioning become your problem. Depending on your needs you might find it easieer to generate a word document from the user input and print that, you could also consider generating a pdf or if you are running .Net 3 or higher then creating an XPS document might be a valid option. If WPF is a possibility then it's richtextbox will take care of pretty much creating a xps document for you.

Are you only checking for duplicates in Col1? If so could you not group by Col1 and do a count of matching rows?

If a function is declared as returning a result, regardless of type (classes, arrays, collections, ints - anything at all) then all paths must return a value unless an unhandled exception occurs.

If you are catching the exception then the error has been dealt with, the calling function will not be aware an exception was thrown and caught so it will expect a return value.

You could declare the constructor as static and it would only be run once, however static constructors get execute before any of your application's code - this can cause startup performance issues if this initialisation is slow / memory hungry.

If you just copy the connection string from a working application into this application does that fix the problem?

If you have the .Net configuraton tools installed you can configure the required permissions through that and export the new security settings as an MSI that could then be deployed via a group policy or similar.

http://www.microsoft.com/downloads/details.aspx?familyid=75FEF59F-1B5E-49BC-A21A-9EF4F34DE6FC&displaylang=en might be worth investigating then. IIRC it does require VS 2008 though - however the time saved in this situation may justify the switch.

Depends how the database is being hosted - if it is part of your network then you might just be able to connect to it as normal. If the database is hosted behind a firewall or similar you will be restricted to just http or https as a connection mechanism in which case you will have no direct access to the db. In this case you might find that the easiest solution it to build a web service that will expose the functionality you need and call this from your windows app.

The thread could raise an event or accept a callback routine it calls when it's work is done.