MyClass now has all the functions/procedures and variables of a normal thread class. I would like to do the same thing in C# but I can't inherit from system.threading.thread because it's sealed. I suspect there might be another approach to this but I can't find much on google. I guess I am not searching for the right things here. I guess I'm trying to do this the Delphi way when I should be doing them the C# way!!!
In C# threads are handled differently. You create an instance of System.Threading.Thread and pass ThreadStart delegate to the constructor. ThreadStart delegate represents a method that thread will run.
//Run code here
Thread myTread = new Thread(new ThreadStart(RunMe));
Does anyone know how to select a node in a TreeView, inside the application?
Just like a mouse click event on the node.
I have tryed the different combination of
theTreeView.SelectedNode = theTreeView.Nodes;
It does work (I use it for a few things) but you won't notice unless 1) your TreeView has the focus, or 2) if another control has the focus you must set TreeView.HideSelection to false (default is true), otherwise it is selected but you just won't see that it is.
The easiest way - albeit not a very well-designed way - is to cast the Form.MdiParent property to your MDI parent's Form-derivative class, then access the Form.Menu property and - through the provided properties - disable the MenuItem you want.
A good design would use a modular design pattern in such a way that services are provided to the MDI child forms allowing them easily access the menu, or use the MenuItem.Merge method to merge menus defined on the MSI children with the menu for the parent form. See Form.MergedMenu property for more information.
Using the latter methods allows client forms to provide menus to the parent that they want to use. This is VERY common for most MDI applications. Just open Microsoft Word. Look at the menus available. Now close just the document (leaving the application window open). Your options are greatly decreased (although this process uses the concepts of Active Document containers and servers, but the idea is the same).
I think WinForm applications mostly uses for companies which want their own softwares, not for shareware applications inside internet or other places cause .NET framework still is not part of operating system and should be download seprately. I myself wrote all of win applications for my customers in C# this year(or last year ) and one of them was international oil company of Aaustria in Iran and its a really big company.
We have one I architected (though more time to design it would've been nice, but you may know these rush-to-market start-ups can't fathom that!) a while back (started designing on 1.0 RC1) at http://www.proplanner.com[^] (the site looked much better after I wrote the initial bits until marketing got ahold of it!).
It uses just about everything: RCWs (for now - they are being replaced with .NET equivalents as they become available since we don't have time to write such libraries), .NET Remoting, Web Services, Windows Forms, ASP.NET, and massive amounts of ADO.NET.
The biggest complaint thusfar is the 20+ MB runtime download as well as the req' of admin access to install the .NET Framework (you wouldn't believe how long it took me to explain to my CEO that there is just no way around this requirement!). Otherwise, the application uses a no-touch deployment across the Internet (we have a LAN version that talks directly to SQL Server, too, built on the same code with different proxies) so the assemblies are cached in the Temporary Assembly Cache and we control versioning easily in the assembly repository online.
I do know for a fact that a lot of companies are writing in-house applications using .NET for RAD (rapid application development) because their IT can easily deploy the .NET Framework to machines and it cuts development costs and doesn't always require true geeks to do (don't get me started on that!).
I think that as "Longhorn" comes to fruition, we'll start seeing more. .NET is definitely being well-received for many things so I think it's wide-spread use is inevitable. It's been released for a couple years and is still going strong, so that's always a good sign. I think the only reason Java spread much more quickly (and I remember the Java-boom well) is because of Java applets and the fact that we never had anything like that (rich clients) before.