No need - see the documentation for the CollectionBase class in the .NET Framework SDK (just type "CollectionBase" (without quotes) in the Index) and you'll see an example. Be sure to read the documentation - if not skim it over to see what's available in the base class library - especially when starting out.
For the simple drag-n-drop method which generates the RCWs (COM interop assemblies) is to custom your toolbox. Open your toolbox (contains the design objects like a Label or a Button), right-click and select "Customize Toolbox" or "Add/Remove Items" (depending on version of VS.NET). Find the "Adobe Acrobat Control for ActiveX" and "Microsoft Office Spreadsheet Version", where Version is 9.0 or higher (introduces the Office Web Components, or OWC).
If you want to host an actual Excel Spreadsheet like Excel does, you'll either have to dig deep in Active Document Containers and implement several redefined COM interfaces in a class to contain the Active Document (which describes Word docs, Excel sheets, and many other formats), or wait for .NET 2.0 which introduces the ActiveDocumentContainer which already does this, but you'll still have to worry about hosting the toolbar (at least for now in the alpha stages). This can be difficult as well. The OWC edition of Excel already has the toolbar built-in and contains custom design commands.
For the Acrobat control, you can specify a src for the PDF document, either at design-time or at runtime.
You can further hide the application window by setting psi.WindowStyle = ProcessWindowStyle.Hidden.
You can also reference the Microsoft.Office.Excel primary interop assembly (you can generate them yourself, but it's better to use the official ones from http://msdn.microsoft.com/library/en-us/dnoxpta/html/odc_oxppias.asp[^]) and print the spreadsheet. This uses an out-of-process automation server (Excel.Application) to load and print the document:
Microsoft developed an activex container. It's free, but there is no support for it. With the activex you can host any Office document inside a WinForm. Just install it and add it to the VS.NET toolbox.
There are no "functions" in .NET - only methods (procedures on an entity such as a class or struct).
The button can easily be blue by setting Button.BackColor (inheritted from Control) to Color.Blue. In order to execute a method on another object elsewhere, you'll have to pass an instance of that object to the property page. You could also expose an instance of this object as a static property of another class, but this is not recommended. Mixing statics and instances is like mixing cats and dogs (maybe not as violent, but they just don't belong together).
For instance, lets say that this property page is bound to certain objects in a class that encapsulates the logic for generating your DataSet. Pass that entire object to the constructor for the property page (or a property or something). Bind the properties and when the button is clicked, you already have an instance of the aforementioned class so just call the instance method. Just try to encapsulate your logic into distinct units and passing references to them when possible.
Err...Heath...I think he was talking about the PropertyGrid control. When you have certain classes selected, there's this little section added to the bottom of it with links. His particular example was the DataAdapter class. If you drag one onto your form, and then click on it in the components tray, and view its properties, then you'll see links at the bottom like "Configure Data Adapter" or "Generate DataSet".
In that case, derive from the appropriate ComponentDesigner and override the Verbs property to return a collection of DesignerVerb objects (see documentation in .NET Framework SDK for more information about these classes - it's really pretty straight-forward).
Finally, attribute your component with the DesignerAttribute attribute, passing the Type of your designer from above to the constructor of the attribute.
If you execute the statement to fill the tree in a separate thread, the current cursor will be set to the default immediately since the method you called executes in another thread. If you call Application.DoEvents in your code before wanting the default cursor to be reset, if will be set to Cursors.Default, so don't call Application.DoEvents, either.
Finally, make sure you have something like the following: it's all too often that wait cursors are left showing when a process has finished in err:
Cursor current = Cursor.Current;
Cursor.Current = Cursors.WaitCursor;
// Do stuff.
Cursor.Current = current;
Optionally, you can forget about storing the current cursor (for instance, if you know your method is in the only thread of execution running, such as the main UI thread) and just use Cursors.Default.
But you don't have to set this on every control. Cursor.Current set the wait cursor and stops processing mouse events for the entire application. Only Control.Cursor sets the desired cursor for just that control.
I'm not filling the treeview, I'm using the treeview selection to fetch data from a database, and show a lot of photo thumbnails in another control using GDI+.
I tried something fun. At the top of the function I sat the treeview cursor to an hourglass, and never sat it back to normal, I also removed the calls to Cursor.Current.
When I move my mouse over the treeview i get an hourglass as expected (the function have executed when the app loaded), but when I change the selection, I get the arrow cursor when processing and the hourglass when finished working.
This really don't make any sense to me, and I really think it sucks that when I set cursor.current, the system just sets it back to default when the thread is going idle (like waiting for a database or the filesystem). At least it looks that way to me.
Mmmm, sometime I whish I had done this app in C++ and Win32 instead, at least I did not have those stupid problems there
It took somewhat more time to make GUI stuff, but not all those stupid problems...
The application can't be idle if the UI thread is currently executing code, such as "waiting" for database results or reading a file. An idle state of an application indicates that the STA on which the application was started is not currently processing. So, something else is reseting your cursor. The only other way to process queued notification messages on the UI thread is to call Application.DoEvents as I mentioned above.
If you want the cursor to be the WaitCursor for the whole app, make sure you use Cursor.Current and not the Cursor property of the control. Since the control also contains a Cursor property, use System.Windows.Forms.Cursor to specify the class just to be sure.
As far as this vs. Win32, all this wraps the functions defined in the Win32 APIs. Much - it not most - of the Framework does encapsulate the Win32 APIs.
Heath Stewart wrote: The application can't be idle if the UI thread is currently executing code, such as "waiting" for database results or reading a file.
A thread get idle when waiting for a database ot reading a file. It have always been that way, trust me
And... I don't call Application.DoEvents() anywhere what so ever in my application, but the cursur still automatically changes to an arrow.
Heath Stewart wrote: If you want the cursor to be the WaitCursor for the whole app, make sure you use Cursor.Current and not the Cursor property of the control.
Yes, I do know that, I just dont think you know why I wrote as I did
It was just for testing, you know, and I found it funny that when the application was processing stuff, it changed the hurglass cursor to an arrow.
Thanks for your attempt to help but I guess you dont know whats happening, no more than I do...
It's probably just another quirck of the .NET framework.
Heath Stewart wrote: As far as this vs. Win32, all this wraps the functions defined in the Win32 APIs. Much - it not most - of the Framework does encapsulate the Win32 APIs.
Yes, but have you ever used the Win32 API with C++?
So much more control.
Our application makes an extraordinary amount of database calls, even through remoting and never goes idle, hence we never have a problem with the wait cursor resetting. These calls are typically made in the STA thread. The only time I have had problems with the wait cursor resetting is when I make asynchronous calls.
Anders Molin wrote: Yes, but have you ever used the Win32 API with C++?
Since Windows 3.1. Still do, although most development is in a couple .NET languages, mostly C#.
Make sure you have generated a key and put it in the projects directory using
sn.exe -k KeyFile.snk
Keep this file safe and do not share it.
Also, when using the literal specifier "@", do not escape your backslashes like you are in the first example. The location of the file is relative to the build path. VS.NET builds everything relative to bin\(Debug|Release) by default, so your first and third examples are correct (assuming the key pair file is generated correctly). The third will not work unless building your project from the project directory (possible using the csc.exe command-line compiler).
Just as a side note, it doesn't matter where you put assembly attributes, so long as they're part of a source file being compiled into your assembly.