I'm currently trying to figure out how to automate UI testing for my WPF application and I have troubles getting it to work.
The XAML of MyControl (which extends UserControl) contains the following CheckBox:
<CheckBox Name="IsFooCheckBox"
IsChecked="{Binding Path=IsFoo, Mode=TwoWay, UpdateSourceTrigger=PropertyChanged}" />
The binding points to a custom data context that implements INotifyPropertyChanged and that contains the following property:
private bool _isFoo;
public bool IsFoo
{
get { return _isFoo; }
set
{
_isFoo = value;
OnPropertyChanged("IsFoo");
}
}
The binding is working in production (in the debugger is can see that _isFoo is updated whenever I toggle the checkbox).
I'd like to have a test now that toggles the checkbox and checks that the data context is updated (or to check logic that is implemented in the code-behind). The WPF UI Automation framework seems to be exactly what I am looking for, so I wrote the following NUnit test:
var myContext = ...
var sut = new MyControl
{
DataContext = myContext
};
var peer = new CheckBoxAutomationPeer(sut.IsFooCheckBox);
var pattern = peer.GetPattern(PatternInterface.Toggle) as IToggleProvider;
pattern.Toggle();
Assert.That(sut.IsProvidingProfileCheckBox.IsChecked.Value); // works
Assert.That(myContext.IsFoo); // fails
While the first Assert passes, the second one fails. I do not understand why this happens... it seems that the binding in the XAML file is ignored or that the update is not triggered. Does anybody have a suggestion how to fix my test? Is this even possible?
Issue originates here
public bool IsFoo
{
get { return _IsFoo; }
set
{
_isFoo = value;
OnPropertyChanged("IsFoo");
}
}
Once you have invoked
pattern.Toggle();
you implicitly invoke setter of IsFoo which raises PropertyChanged event and in turn forces to refresh UI elements which have binding associated with IsFoo - to cut a long story short, getter is invoked and instead of _isFoo it returns _IsFoo. You mistook variable.
Try to avoid calling OnPropertyChanged method with explicit property name. Instead of this use CallerMemberName attribute which retrieves property name.
public void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
if (PropertyChanged != null)
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
public event PropertyChangedEventHandler PropertyChanged;
Then you only need below invocation.
OnPropertyChanged();
I had similar problem. I was populating textbox with following code:
ValuePattern valuePattern = promptBox.GetCurrentPattern(ValuePattern.Pattern) as ValuePattern;
valuePattern.SetValue(value);
And depending on the value in text box, another button state was supposed to change from Disabled to Enabled.
I've noticed that after automation code above executed, clicking on the window by hand triggered binding to evaluate.
So I just added
System.Windows.Forms.SendKeys.SendWait("{TAB}");
after SetValue and it started to work just fine.
It took me some time to figure this out, but in the end, it is kind of obvious and described in many places all over the internet. I guess everything is easy as soon as you know what to look for...
The problem of coded UI tests is that the bindings are not resolved automatically. The resolving has to be initiated by calling Window.ShowWindow.
I extended my test and added the following snippet:
Window window = new Window
{
Content = sut // the control to test
};
window.Show();
Adding this call instantaneously fixed the strange test behavior that I described in my post.
The direct follow-up problem is that this call requires an active UI thread. Because of this, it might be tricky to get the test to run on a build server in a continuous integration environment. However, this depends on the environment (esp. the build server) and is a different question.
Related
I'm pretty new to WPF, and now I stumbled on something for which I could not find the answer anywhere on the internet. I have the following problem:
Within the same solution, I have 2 projects. One is an application that represents a production process, called MaintenancePlanner. The other is a GUI called MaintenancePlannerGUI.
What I want to achieve is the following: upon pressing a button, the simulation of my production process starts (which takes place in MaintenancePlanner). Then, in the MaintenancePlannerGUI, I have for example a progressbar. The value of the progressbar should change according to the value of the property of an object within the MaintenancePlanner simulation.
Therefore, I need to bind this somehow. However, I don't understand how to do this. I make use of the MVVM structure. So my structure looks like follows:
MaintenancePlanner
AssemblyFab.cs
AssemblyLine.cs
ShellModel.cs (something like Program.cs, but specifically to be used for MaintenancePlannerGUI only)
MaintenancePlannerGUI
Views
ShellViewModel.cs
ViewModels
ShellView.xaml
Now, AssemblyLine for example contains a property Speed. Note that multiple instances of AssemblyLine are attached to AssemblyFab, in the form of a List<AssemblyLine> AssemblyLines.
In ShellView.xaml I have a progressbar:
<ProgressBar Width="10" Height="45" Margin="0,5,10,0" Orientation="Vertical" Minimum="0" Maximum="50" Value="{Binding ???}"/>
In ShellViewModel.cs I create an instance of the MaintenancePlanner simulation AssemblyFabSim by creating an instance of ShellModel.cs from MaintenancePlanner where the whole AssemblyFab and its constituents are created, like this:
AssemblyFabSim = new ShellModel();
Now, I tried something very crude like:
Value="{Binding AssemblyFabSim.AssemblyFab.AssemblyLines[0].Speed}
But that obviously didn't work. Another idea that came to my mind is to make use of the NotifyPropertyChanged Methods.
So in that case, I could create a property in ShellViewModel.cs named for example test and bind that to my progressbar. Then I could update test by getting a notification if the property changed in the ShellModel.cs. But then I also need to monitor the changes in AssemblyFab and AssemblyLine from within ShellModel.cs, so to propagate the change from AssemblyLine to AssemblyFab to ShellModel to ShellViewModel to the View. And I am a little bit confused about this approach.
private void ShellModel_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
if (e.PropertyName == "Speed")
{
test = AssemblyFabSim.AssemblyFab.AssemblyLines[0].MouldCleanInterval;
}
}
I was wondering whether this is indeed the way to go, and if so, how to do this exactly? Or are there perhaps other simpler ways? Thanks in advance!
Edit 1
My ShellViewModel.cs now contains the following, as ShellViewModel inherits the INotifyPropertyChanged class like this ShellViewModel : INotifyPropertyChanged
public ShellModel AssemblyFabSim { get; set; }
AssemblyFabSim.PropertyChanged += ShellModel_PropertyChanged;
private void ShellModel_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
if (e.PropertyName == "TestSpeed")
{
test = AssemblyFabSim.AssemblyFab.AssemblyLines[0].Speed;
}
}
private double _test;
public double test
{
get { return _test; }
set
{
_test = value;
NotifyOfPropertyChange();
}
}
And I now bind my progressbar value like Value="{Binding test}. Then ShellModel.cs also will inherit INotifyPropertyChanged and I add:
public void UpdateSpeed()
{
try
{
TestSpeed = AssemblyFab.AssemblyLines[0].Speed;
}
catch (Exception e)
{
throw new Exception(e.Message);
}
NotifyOfPropertyChange(nameof(TestSpeed));
}
public event PropertyChangedEventHandler PropertyChanged;
private void NotifyOfPropertyChange([CallerMemberName] string propertyName = null)
{
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}
And the UpdateSpeed() method is called from within the Assemblyline.
New problem: The value of the processbar gets updated, but only after the simulation is finished I see the result. That is, the GUI just freezes until the simulation stops and it then shows the last value of Speed.
If your shellViewModel has a property like
public ShellModel AssemblyFabSim {get;}
you should be able to bind to it, and if all the other properties in the path is correct they should also work. But as far as I know, bindings does not support indexers, so I do not think AssemblyLines[0] will work.
Wpf does not care about what projects classes are defined in, only that it has a object to bind to, and the properties are correctly named. Usually everything should also implement INotifyPropertyChanged to work well.
But note that deeply nested paths is probably not a good idea, you should try to separate the UI and business logic, so you should try to avoid binding to anything other than viewModel classes designed for it.
Notably, if you have a progress bar you should bind to a Progress<T> object that is handed to the method that needs to report progress. You should avoid using a progress-property on the object performing the work, after all, what would happen if the method was called concurrently from multiple threads?
You need to ensure that you are calling the UpdateSpeed() on a background thread since the UI thread cannot both update the progress bar and execute your code simultaneously.
I have a BottomAppBar.AppBarButton in a Windows Phone specific page, that is bound to a relay command. The code, binding and viewmodel implementation have all been used in basically the same way on other pages in the project and works exactly as expected there.
The issue in this particular scenario is that the button remains disabled even after raising the .RaiseCanExecuteChanged() method, and the CanExecute() returns true.
I originally thought that it might be due to excess calls to manually raising the notification with property changes, so have tightened that part of my code so that the method is only raised as needed, and when it is needed to change the button's status. Even still, the button remains disabled despite CanExecute() returning true.
If I comment out all the checks in CanExecute() and default to true, the button is enabled as expected, and when tapped fires the expected Execute() function, so it appears that the initialization of the RelayCommand is ok. If I then let the checks back in, and run step through each time CanExecute() is fired, when it returns true, the button doesn't become enabled.
Any ideas? For what its worth, I've added code below, but I don't think that is the cause.
RelayCommand class is the standard class that comes with the HubApp in VS, so I will omit that code.
last line of the viewmodel constructor is the RelayCommand;
AddStrikeTeamCommand = new RelayCommand(async() => await AddStrikeTeam(), CanAddStrikeTeam);
Can Add is;
private bool CanAddStrikeTeam()
{
//if (NameWorking == string.Empty) return false;
//if (FactionWorking == string.Empty) return false;
//if (PointsLimitWorking < 1) return false;
//if (!IsValidTeamWorking) return false;
return true;
}
And finally, the button binding
<AppBarButton x:Name="accept" Icon="Accept" Label="accept"
Command="{Binding AddStrikeTeamCommand}"/>
I'd probably bet your problem has to do with RaiseCanExecuteChanged(). This is especially true if you are used to WPF and how it automatically refreshes CanExecute for you. Check out this Delegate Command implementation:
http://codepaste.net/ho9s5a
The ICommand interface defines the event CanExecuteChanged which instructs the button (or UI Element) to refresh its Enabled status. In WPF, this was raised constantly by the static, command manager. This does not exist in WinRT. In WPF, because it was raised so frequently, WPF developers had to be careful that CanExecute() was not an expensive operation. WinRT provides for expensive tests, but consequently requires the developer to raise the event manually. I hope this makes sense.
One way I handle this is:
DelegateCommand _SaveCommand = null;
public DelegateCommand SaveCommand
{
get
{
if (_SaveCommand != null)
return _SaveCommand;
_SaveCommand = new DelegateCommand
(
() =>
{
// TODO
},
() => true
);
this.PropertyChanged += (s, e) => _SaveCommand.RaiseCanExecuteChanged();
return _SaveCommand;
}
}
This basically refreshes the CanExecute based on the change of any property in (usually in my View Model). This is not sufficient if you have potential changes in models that you have in an ObservableCollection, but it's a nice start to the whole thing.
There's a possibility that you don't have this problem at all. And that you are calling to raise the event, it is returning true, and is still not working. If that is what is happening, it just has to be your code because Commands are working for thousands of apps. But, if you want to send me your code, I'll take a look.
Best of luck!
I know this is a late answer, but this post is being linked in another question so I feel like I should post a better code sample.
Jerry's answer is most likely correct that the problem is RaiseCanExecuteChanged is not raised automatically in that implementation of ICommand, however the code sample provided re-introduces the exact same problem that caused it to be taken out in the first place - it raises CanExecuteChanged whenever any property changes, resulting in CanExecute being called far more than necessary.
The PropertyChanged event handler should include a check and only raise CanExecuteChanged if the property changed is one that is used in CanExecute.
Since your CanExecute is
private bool CanAddStrikeTeam()
{
if (NameWorking == string.Empty) return false;
if (FactionWorking == string.Empty) return false;
if (PointsLimitWorking < 1) return false;
if (!IsValidTeamWorking) return false;
return true;
}
then the event handler needs to only raise CanExecuteChanged if one of those for properties changes
this.PropertyChanged += (s, e) =>
{
switch (e.PropertyName)
{
case "NameWorking":
case "FactionWorking":
case "PointsLimitWorking":
case "IsValidTeamWorking":
AddStrikeTeamCommand.RaiseCanExecuteChanged();
break;
}
}
If you are using Mvvm Light, make sure you are including the GalaSoft.MvvmLight.CommandWpf namespace instead of the GalaSoft.MvvmLight.Command namespace.
(See the second answer on MVVM RelayCommand CanExecute)
I'm in the process of translating a WPF window. I'm using WPF Localize Extension . So far I only have a Spanish translation for testing purposes in <Resource>.es.resx file . At design time translations work . So I guess I'm on the right track .
I have included menu items to translate the GUI dynamically at run time . Initially I tried this (naïve) command ...
public class CmdTranslateUI : ICommand
{
bool ICommand.CanExecute(object parameter)
{
// TODO: Query available translations
return true;
}
public event EventHandler CanExecuteChanged;
void ICommand.Execute(object parameter)
{
LocalizeDictionary.Instance.Culture = new CultureInfo(
(string) parameter);
}
}
... and menu items for each language are bound to it in XAML this way .
<MenuItem Header="Español" CommandParameter="es-ES">
<MenuItem.Command>
<l:CmdTranslateUI />
</MenuItem.Command>
</MenuItem>
The fact is that such approach is not working . Culture info remains set to "en-US" anyway . I read that on setting LocalizeDictionary.Instance.Culture its DictionaryEvent is triggered, so I thought this would update the GUI automatically . Obviously I'm wrong .
On the other hand , it seems current thread's culture won't influence library behavior either.
So I ask ...
Q:
What's the recommended approach to translate a window at run time with WPF Localize Extension ?
How could I list available translations ?
Thanks in advance .
It seems I introduced a typo by accident last time I compiled the library (or I had ghosts in my HDD / CPU) . Language switching is working now after setting LocalizeDictionary.Instance.SetCurrentThreadCulture .
Just for the record , this is what command class mentioned above should look like
public class CmdTranslateUI : ICommand
{
bool ICommand.CanExecute(object parameter)
{
CultureInfo ci = new CultureInfo((string)parameter);
foreach (CultureInfo c in ResxLocalizationProvider.Instance.AvailableCultures)
{
if (ci.Name == c.Name)
return true;
else if (ci.Parent.Name == c.Name)
return true;
}
return false;
}
public event EventHandler CanExecuteChanged;
void ICommand.Execute(object parameter)
{
LocalizeDictionary.Instance.SetCurrentThreadCulture = true;
LocalizeDictionary.Instance.Culture = new CultureInfo(
(string) parameter);
}
}
... at least that's a simple approach that will work as long as resource files l10n provider is active.
The LocalizeExtension's Culture property is independent of the threads UI culture. Sometimes this may be desired, because the threads culture does affect a lot of things. We are using the extension in our own project and settings the threads culture manually to match the LocalizeDictionary's culture.
Normally this should update the UI automatically. Make sure you are using the LocText markup extension in your XAML, e.g:
<TextBlock Text="{lex:LocText Bla:Bla:Bla}" />
Update:
To get the list of available translations you might try this:
Get all available cultures from a .resx file group
However I would recommend that you just provide a fix list of languages in code or if you are using an IoC container, register the available languages there.
This does not answer OP's question, but thought I'd post it here anyway for those wandering here from Google since the title of the question is relevant.
I was having a problem where my application would be partially translated when changing the language in runtime. At first thought it was a convention problem since I had separate resources for each page, but the real problem was that the last control in the first page failed to translate, so it broke the chain and as a result all the subpages didn't get translated.
I was translating the FallbackValue of a textblock, I was using this property to show a default text when the binding was null.
Anyway, to catch errors like this, you can subscribe to the following event:
LocalizeDictionary.Instance.MissingKeyEvent += (sender, args) =>
{
//Do something
};
I am using VS2010, writing unit tests with MSTest. My project uses WPF, MVVM and the PRISM framework. I am also using Moq to mock interfaces.
I am testing the interaction between a command and a selected item in a list. The interaction is encapsulated in a ViewModel according to the MVVM pattern. Basically, when the SelectedDatabase is set, I want the Command to raise CanExecute. I have written this test for the behaviour:
public void Test()
{
var databaseService = new Mock<IDatabaseService>();
var databaseFunctionsController = new Mock<IDatabaseFunctionsController>();
// Create the view model
OpenDatabaseViewModel viewModel
= new OpenDatabaseViewModel(databaseService.Object, databaseFunctionsController.Object);
// Mock up the database and its view model
var database = TestHelpers.HelpGetMockIDatabase();
var databaseViewModel = new DatabaseViewModel(database.Object);
// Hook up the can execute changed event
var resetEvent = new AutoResetEvent(false);
bool canExecuteChanged = false;
viewModel.OpenDatabaseCommand.CanExecuteChanged += (s, e) =>
{
resetEvent.Set();
canExecuteChanged = true;
};
// Set the selected database
viewModel.SelectedDatabase = databaseViewModel;
// Allow the event to happen
resetEvent.WaitOne(250);
// Check that it worked
Assert.IsTrue(canExecuteChanged,
"OpenDatabaseCommand.CanExecuteChanged should be raised when SelectedDatabase is set");
}
On the OpenDatabaseViewModel, the SelectDatabase property is as follows:
public DatabaseViewModel SelectedDatabase
{
get { return _selectedDatabase; }
set
{
_selectedDatabase = value;
RaisePropertyChanged("SelectedDatabase");
// Update the can execute flag based on the save
((DelegateCommand)OpenDatabaseCommand).RaiseCanExecuteChanged();
}
}
And also on the viewmodel:
bool OpenDatabaseCanExecute()
{
return _selectedDatabase != null;
}
TestHelpers.HelpGetMockIDatabase() just gets a mock IDatabase with some properties set.
This test passes when I run the test from VS2010, but fails when executed as part of an automated build on the server. I put in the AutoResetEvent to try to fix the problem, but it's had no effect.
I discovered that the automated tests were using the noisolation flag in the MSTest command line, so I removed that. However, that produced a 'pass' once, but a 'fail' the next.
I think I am missing something important in all of this, but I can't figure out what it is. Can anyone help by telling me what I'm doing wrong?
Updated
The only other remaining places where your code could fail is in these two lines in your snippet for the SelectedDatabase property.
RaisePropertyChanged("SelectedDatabase");
// Update the can execute flag based on the save
((DelegateCommand)OpenDatabaseCommand).RaiseCanExecuteChanged();
There are others who have had some problems with RaisePropertyChanged() and it's use of magic strings; but this is probably not your immediate problem. Nonetheless, you can look at these links if you want to go down the path of removing the magic string dependency.
WPF, MVVM, and RaisePropertyChanged # WilberBeast
MVVM - RaisePropertyChanged turning code into a mess
The RaiseCanExecuteChanged() method is the other suspect, and looking up documentation in PRISM reveals that this method expects to dispatch events on the UI thread. From mstest, there are no guarantees that a UI thread is being used to dispatch tests.
DelegateCommandBase.RaiseCanExecuteChanged # MSDN
I recommend you add a try/catch block around it and see if any exceptions are thrown when RaiseCanExecuteChanged() is called. Note the exceptions thrown so that you can decide how to proceed next. If you absolutely need to test this event dispatch, you may consider writing a tiny WPF-aware app (or perhaps a STAThread console app) that runs the actual test and exits, and having your test launch that app to observe the result. This will isolate your test from any threading concerns that could be caused by mstest or your build server.
Original
This snippet of code seems suspect. If your event fires from another thread, the original thread may exit the wait first before your assignment, causing your flag to be read with a stale value.
viewModel.OpenDatabaseCommand.CanExecuteChanged += (s, e) =>
{
resetEvent.Set();
canExecuteChanged = true;
};
Consider reordering the lines in the block to this:
viewModel.OpenDatabaseCommand.CanExecuteChanged += (s, e) =>
{
canExecuteChanged = true;
resetEvent.Set();
};
Another issue is that you don't check if your wait was satisfied. If 250ms did elapse without a signal, your flag will be false.
See WaitHandle.WaitOne to check what return values you'll receive and update this section of code to handle the case of an unsignaled exit.
// Allow the event to happen
resetEvent.WaitOne(250);
// Check that it worked
Assert.IsTrue(canExecuteChanged,
"OpenDatabaseCommand.CanExecuteChanged should be raised when SelectedDatabase is set");
I have found an answer to explain what was going on with this unit test. There were other complicating factors that I didn't realise were significant at the time. I didn't include these details in my original question because I did not think they were relevant.
The view model described in the question of code is part of a project that is using integration with WinForms. I am hosting a PRISM shell as a child of an ElementHost. Following the answer to the question on stackoverflow How to use Prism within an ElementHost, this is added to create an appropriate Application.Current:
public class MyApp : System.Windows.Application
{
}
if (System.Windows.Application.Current == null)
{
// create the Application object
new MyApp();
}
The above code is not exercised by the unit test in question. However, it was being exercised in other unit tests that were being run beforehand, and all were run together using the /noisolation flag with MSTest.exe.
Why should this matter? Well, buried in the PRISM code that is called as a consequence of
((DelegateCommand)OpenDatabaseCommand).RaiseCanExecuteChanged();
in the internal class Microsoft.Practices.Prism.Commands.WeakEventHandler is this method:
public static DispatcherProxy CreateDispatcher()
{
DispatcherProxy proxy = null;
#if SILVERLIGHT
if (Deployment.Current == null)
return null;
proxy = new DispatcherProxy(Deployment.Current.Dispatcher);
#else
if (Application.Current == null)
return null;
proxy = new DispatcherProxy(Application.Current.Dispatcher);
#endif
return proxy;
}
It then uses the dispatcher to call the event handler in question:
private static void CallHandler(object sender, EventHandler eventHandler)
{
DispatcherProxy dispatcher = DispatcherProxy.CreateDispatcher();
if (eventHandler != null)
{
if (dispatcher != null && !dispatcher.CheckAccess())
{
dispatcher.BeginInvoke((Action<object, EventHandler>)CallHandler, sender, eventHandler);
}
else
{
eventHandler(sender, EventArgs.Empty);
}
}
}
So it attempts to dispatch the event on the UI thread on the current application if there is one. Otherwise it just calls the eventHandler. For the unit test in question, this led to the event being lost.
After trying many different things, the solution I settled on was just to split up the unit tests into different batches, so the unit test above is run with Application.Current == null.
I am looking for a sample that demonstrates in the lightest way possible the following:
A Model that invokes a SOAP based web service; regularly polling to get the latest value (assume the SOAP service returns a boolean). The model should also support invoking a SOAP method that changes the boolean on the server.
A ViewModel that enables the underlying boolean to be bound to controls in the View (e.g. to a checkbox).
A View with the above checkbox control bound to the underlying boolean. Depending on the poll interval the checkbox will update as the server's state changes. If the checkbox is clicked the event will be dispatched to the model causing the server to be updated.
Optimally this sample will work on Windows Phone 7, but in a pinch I'd be happy with something that supported SL3 (no use of SL4 command routing allowed).
I am struggling with trying to understand how to make MVVM-Light work for me and I suspect that an expert could code a sample up like this very quickly... I also suspect this is a fairly common pattern for a lot of apps.
Mick N's pointer helped, but what really got me over the hump was this post by Jeremy Likness:
http://csharperimage.jeremylikness.com/2010/04/model-view-viewmodel-mvvm-explained.html
Here's the sample for the benefit of others (assuming I'm not doing anything really stupid):
First, I started using the Mvvm-Light Windows Phone 7 project.
I added a checkbox to my MainPage.xaml:
<CheckBox Content="Switch 1"
IsChecked="{Binding Switch1.PowerState, Mode=TwoWay}"
Height="72" HorizontalAlignment="Left" Margin="24,233,0,0"
Name="checkBox1" VerticalAlignment="Top" Width="428" />
Notice the IsChecked is bound to Switch1.PowerState using the TwoWay mode so that the property flows both ways.
A key learning for me is how to enable communication from my timer callback (TimerCB) which will be running on a new thread to the Silverlight UI thread. I used the Mvvm-Light DispatcherHelper.CheckBeginInvokeOnUI helper which waits on the UI thread.
I then had to decide whether to implement INotifyPropertyChanged myself in my model, or use Mvvm-Light's ViewModelBase implementation. I actually tried it both ways and had it working but decided I liked using ViewModelBase better because it supports "broadcast" and I think in my actual project that will be handy because I will have multiple ViewModels. It seems a bit uncouth to be basing a "Model" on ViewModelBase class, but I don't think there's any harm in doing so. (???).
My model .cs is below.
public class OnOffSwitchClass : ViewModelBase // ignore that it's derived from ViewModelBase!
{
private const Int32 TIMER_INTERVAL = 5000; // 5 seconds
private Timer _timer;
// Upon creation create a timer that changes the value every 5 seconds
public OnOffSwitchClass()
{
_timer = new System.Threading.Timer(TimerCB, this, TIMER_INTERVAL, TIMER_INTERVAL);
}
private static void TimerCB(object state)
{
// Alternate between on and off
((OnOffSwitchClass)state).PowerState = !((OnOffSwitchClass)state).PowerState;
}
public const string PowerStatePropertyName = "PowerState";
private bool _myProperty = false;
public bool PowerState
{
get
{
return _myProperty;
}
set
{
if (_myProperty == value)
{
return;
}
var oldValue = _myProperty;
_myProperty = value;
// Update bindings and broadcast change using GalaSoft.MvvmLight.Messenging
GalaSoft.MvvmLight.Threading.DispatcherHelper.CheckBeginInvokeOnUI(() =>
RaisePropertyChanged(PowerStatePropertyName, oldValue, value, true));
}
}
}
The MainViewModel.cs was modified to include the following
private OnOffSwitchClass _Switch1 = new OnOffSwitchClass();
public OnOffSwitchClass Switch1
{
get
{
return _Switch1;
}
}
And I added a call to DispatcherHelper.Initialize(); in my App() constructor.
Does this look right?