For an application that I'm working on I use SpotifyLocalAPI, and I want to use the events that the API has. But, as someone who is into C# for a couple of months now, I'm not sure where to start. There is another project based on this API that uses the events, but it's in WPF, and that makes it a different deal if I understand my googeling correctly. This means that for a WinForms I have to do things a bit differently, but I can't seem to figure out how.
The documentation of the API states that You can set a SynchronizingObject, then the events will be called on the specific context. When I look at how the WPF project did this, it has a function (found here) to do some magic, and poof, it works.
If I understand this answer correctly the SynchronizingObject is a property of the ISynchronizeInvoke interface, which "provides synchronous and asynchronous communication between objects about the occurrence of an event.".
Okay, so far so good. I think I understand the basic working of the interface, but how am I supposed to work with it? How do I convince the application that it should react to the event? How should I define the _spotify.SynchronizingObject? (Which is the main problem for me right now)
You can set the SynchronizationObject to be any UI element that implements IShynchronizeInvoke (Form, UserControl etc). Check out the example Winforms app here. Note that this is optional, and in that example app, they have chosen to use Invoke() explicitly in the event handlers. The important thing to remember is that if you want to update the UI, then the code to do so must be run on the UI thread. Some more details on this here.
Related
I'm currently trying to create an application with Prism and I have some problems with communication between modules.
I have a StatusModule which basically shows Statusmessages, but can also show the user that some work is in progress (indeterminate), show different icons, show / hide the control and so on.
For that normally i'd use a status object that has all these properties and use it as a parameter, but because in prism strong coupling is advised I don't know how I should do it.
Creating 4-5 Events for every property is probably bad practice, .. i also thought of creating an interface in my "Interaction" Module where the event's and resources are.
What would you guys recommend?
Many events for status might indeed not be the best solution; however if there's one or two that are used a lot (like showing a status message in a statusbar), I would expose them as events anyway for convenience.
For the rest, you can expose the StatusModule, or rather an interface IStatusModule that is implemented by StatusModule, via MEF or Unity depending on what you use. This way any component that wants to show status imports the IStatusModule and uses it.
I've got a project I've got to crank out (thanks to an employee quitting on the job before the deadline).
He'd been working in WPF. The interface looked cool, but it never was able to collect data from the company's old data access DLLs. (Rewriting the DLLs is a great idea, but not feasible in the short time left by the deadline) Collecting data was the whole point!
The project was thrown at me, but I'm no WPF developer. I've been told to make it work with WinForms, which is what I know. I had a WinForm interface cranked out in a few hours, and it looks every bit as good as the WPF version ...and I know what it is doing. WPF involves voo-doo I haven't learned yet.
There are things used in the WPF project that I need to get a grasp of what they do, and I do not have time to completely redesign it all.
The Business Logic Layer returns an ObservableCollection to the WPF interface.
The WPF interface takes the ObservableCollection and stores it in a CollectionViewSource using its Source parameter.
OK, I'm immediately thinking DataGridView control and using the DataSource parameter from it.
Am I on track?
What was the point of the IEditableCollectionView? Is it necessary? And if not, should I just remove all references to it?
ObservableCollection, CollectionViewSource etc. are important in the WPF's MVVM (MVC...+) scheme. You could drop them but you could certainly reuse them in a WinForms project. It might actually be better to do so to retain the clean separation between UI and data.
You could also hang on to them and use them as "more standard" collections which would simply result in a little bit of unnecessary overhead. And since meeting your deadline is of utmost importance, this might be the way to go.
The observable collection is used so that other controls can participate when the collection is added to, removed, or refreshed. This helps keep the entire UI in sync. As far as the IEditableCollectionView, it raises the INotifyPropertyChanged event so that the controls on the WPF form automatically update when a property in the collection is updated.
If you are doing this in WinForms, you just need to raise events when your collection has changed.
I have written a piece of software that supports plugin architecture. On the main GUI is a TextBox that I use to update the user with the status of the processes.
When I load a plugin, is it bad practice to pass a reference for that Textbox through to the plugin so that it can update it from within. Is this too highly coupled? Would it better practise with events?
Thanks.
I would suggest that you create an interface for communications between the plugin and its host. That would have an UpdateStatus method, and the implementation would update the textbox.
If you really only have one thing to do (updating the status) then you could use a simple delegate... but it seems likely that you may need more operations over time.
In C#, using winforms, what is the best way to make forms talk to each other? Sending data, messages, strings, whatever, from on to the other?
Delegates?
Ideas?
We'ved used something called the Event Pattern successfully in several Winform applications. Here's a good link that will help you get started.
You can create events in one form and then register for those events in the other form. You can also simply access properties from one form to the other. For example maybe in the constructor of the second form, you would pass a variable for the first form.
It sounds like what you're looking for are events though. When some event happens any delegate that is registered will be called.
There is a tutorial on MSDN for events here.
all depends on what you want to communicate.
Let's say it is configuration data; You could create a static property on main form called Settings, which would expose your object. Than all forms would see that same Settings instance, and all would see any changes.
for extra credit you could implement INotifyPropertyChanged, and have it trigger an event. that way all forms looking at Settings would be notified if anything changed.
As a beginner to TDD I am trying to write a test that assumes a property has had its value changed on a PropertyGrid (C#, WinForms, .NET 3.5).
Changing a property on an object in a property grid does not fire the event (fair enough, as it's a UI raised event, so I can see why changing the owned object may be invisible to it).
I also had the same issue with getting an AfterSelect on a TreeView to fire when changing the SelectedNode property.
I could have a function that my unit test can call that simulates the code a UI event would fire, but that would be cluttering up my code, and unless I make it public, I would have to write all my tests in the same project, or even class, of the objects I am testing (again, I see this as clutter). This seems ugly to me, and would suffer from maintainability problems.
Is there a convention to do this sort of UI based unit-testing
To unit test your code you will need to mock up an object of the UI interface element. There are many tools you can use to do this, and I can't recommend one over another. There's a good comparison between MoQ and Rhino Mocks here at Phil Haack's blog that I've found useful and might be useful to you.
Anothing thing to consider if you're using TDD is creating an interface to your views will assist in the TDD process. There is a design model for this (probably more than one, but this is one I use) called Model View Presenter (now split into Passive View and Supervisor Controller). Following one of these will make your code behind far more testable in the future.
Also, bear in mind that testing the UI itself cannot be done through unit testing. A test automation tool as already suggested in another answer will be appropriate for this, but not for unit testing your code.
Microsoft has UI Automation built into the .Net Framework. You may be able to use this to simulate a user utilising your software in the normal way.
There is an MSDN article "Using UI Automation for Automated Testing which is a good starting point.
One option I would recommend for its simplicty is to have your UI just call a helper class or method on the firing of the event and unit test that. Make sure it (your event handler in the UI) has as little logic as possible and then from there I'm sure you'll know what to do.
It can be pretty difficult to reach 100% coverage in your unit tests. By difficult I mean of course inefficient. Even once you get good at something like that it will, in my opinion, probably add more complexity to your code base than your unit test would merit. If you're not sure how to get your logic segmented into a separate class or method, that's another question I would love to help with.
I'll be interested to see what other techniques people have to work with this kind of issue.