You have to lock against the same object (for example, the Type of the current object will always be the same) otherwise the lock doesn't make a difference. Take a look at the System.Threading namespace, specifically the Monitor class (which the lock keyword compiles down to like the following):
If the object called syncRoot is different for every call, the monitor will lock against different objects and will not block pending requests to enter the synchronized section.
There are two things you should take into consideration when choosing an object to lock. If you want a method (especially a static method) to be synchronized, lock against a static object (such as the Type, which is recommended, but you can use a static object reference as well). If you want methods to be synchronized only for a given instance, lock against an object member of the instance of your class.
This might take a few words to explain, so please bear with me if you will:
I'm chopping the data of a .WAV file into segments each of length 256 samples. After this segmentation is done, let's say I have N segments. My N by M multidimensional array is called WaveSegments[N,M].
Now, I want to display each of these segments in a UserControl I've made, and want to cycle through the segments by means of an up/down control.
So, for example, clicking once on the up control would change the number from 1 to 2, and the display would change from the samples of WaveSegment to WaveSegment.
It seems that using collections would ease coding tremendously, but I seem to be running into any number of syntactical problems.
Could somebody please demonstrate to me how I could do this?
Actually, using any kind of IEnumerable or IListSource would be great. You can data-bind the collection to the up/down control and use the CurrencyManager.Position property to adjust the position. For more information about data-binding properties and data sources, see Control.BindingContext and CurrencyManager. This would save you from the mess of handling all this yourself. When used correctly, other controls bound to the data source are updated when the position of the current element in the data source is changed.
At any rate, what are the "syntactical" problems? For ease, extend CollectionBase and override the methods (or implement new methods with strongly-typed params that call the CollectionBase's methods) and most of the rest of the work is already done (which uses an ArrayList to back the elements).
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#.