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.
I've been under the general impression that the commercial .NET applications are primarily oriented toward specific business types or tasks. This sort of software is marketted in a way that the clients are likely to not even know that .NET is being used, and are even less likely to care before purchase of the product. (If it works, we want it.)
Anyway, our company as been using .NET at client sites for well over a year now (maybe 2).
"You said a whole sentence with no words in it, and I understood you!" -- my wife as she cries about slowly becoming a geek.
I have a question, so if you have some ideas, please tell me.
I'm developing file download tool using WebClient class.
But I have a trouble. After downloaded file, I checked it.
The file's timestamp changed to be downloaded time.
I'd like to get how to download file not to change timestamp.
I'm looking for some solution, but I can't.
The following is file download routine.
wc = new WebClient();
myCache = new CredentialCache();
myCache.Add(new Uri(sFrom_Download),"Basic", new NetworkCredential(sUser, sPassword));
wc.Credentials = myCache;
Do you mean the timestamp of the original file on your filesystem, or do you want to use the timestamp of the file that was on the server?
In the former case, if the file exists (see File.Exists) get the last modification date by using a FileInfo that points to it and store the FileInfo.LastWriteTime. After you finish writing the file, set the FileInfo.LastWriteTime to the DateTime you stored previously.
In the latter case, don't use the WebClient; use the HttpWebRequest and HttpWebResponse which are very easy to use and very robust. They are built on the asynchronous pluggable protocol system of .NET and if you look at the documentation for either of those you will find many useful examples.
So, after you make your request and call HttpWebRequest.GetResponse (and cast it to a HttpWebResponse), you can get the HttpWebResponse.LastModified date. AFter you write the file using a buffer, again create a FileInfo instance pointing to that download file and set the FileInfo.LastModified date.
Does anyone how to solve this problem. When I load my XML file with System.XML.XMLDocument. I get this error message
An unhandled exception of type 'System.Configuration.ConfigurationException' occurred in system.dll<br />
Additional information: Error loading XML file c:\winnt\microsoft.net\framework\v1.0.3705\Config\machine.config Request for the permission of type System.Security.Permissions.StrongNameIdentityPermission, mscorlib, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 failed.
The exception is thrown by the CLR when you don't have the specified permission. In this case, the requested permissions is a StrongNameIdentityPermissions. Reading the machine.config is a protected operation (it contains machine-sensitive information) so you're assembly has to be signed (and honestly, it should anyway).
To sign your assembly, generate a key pair (public and private keys) using "sn.exe -k KeyFile.snk" and put it somewhere safe. You should actually try to use this for all your code, but do not distribute it to anyone but - if applicable - your development team (unless you use late-signing and have a build master). Make sure you have an assembly-level AssemblyVersionAttribute and either an AssemblyKeyFileAttribute or AssemblyKeyNameAttribute. If you created your project with VS.NET, you will find these in your AssemblyInfo.cs file (but the can be placed anywhere so long as they're prefixed with [assembly: ...]). This creates a strong-named assembly.
Read the documentation about the AssemblyKey* attributes toward the bottom of the file. It's also recommended in multi-project solutions that you do not use a automatically-generated version number because things can easily get out of hand.