|
If this is a "windows" application, the first / main thread is typically the "UI thread." (You cannot create more than one UI thread).
Besides the "completed" event, which runs on the UI thread, the BackgroundWorker also has a "progress changed" event handler that can be invoked from the "do work" handler via the "on progress changed method"; this "progress changed" handler runs on the UI thread so you can update the UI there.
When using "progress changed" you need to insure that:
- the UI thread is available for "progress changed" to run
- "progress changed" may need to be re-entrant depending on how often / frequently you call it from "do work".
And passing parameters to your threads may not always be practical; you can however "share" memory safely between threads (except UI controls): see "collections.concurrent" and "interlocked" for "non-blocking" possible solutions.
(It's not that something is wrong; some things are just easier than others; and there is usually more than one way).
In general, the BackgroundWorker is suggested if a thread needs to interact with the UI (i.e. via progress changed).
|
|
|
|
|
Technically, you can have more than one UI thread. It's not recommended but it is possible.
|
|
|
|
|
Thanks for that.
Sometimes I equate "shouldn't" with "can't" ...
(Hmmm; now let's see where I can use multiple UI threads in "my" apps).
Yeah, but .... I think we were talking "one window". A window can only have one UI thread.
Multiple windows; one thread for each window; ok.
|
|
|
|
|
Yeah, one window one UI thread.
|
|
|
|
|
Thank you for your help.
I have been researching this and developing some test code.
The thing is that what I am doing is creating a series of bitmaps based upon the state of a user control. The user control displays an image or video and draws some shapes such as lines and rectangles and ellipses. I want to capture the state of the user control several times a second using a visualbrush and use rendertargetbitmap to save to bitmap on the disk.
This is a length process. With lengthy processes, it is recommended to use a background worker. However, I need some way of sharing the visualbrush with the backgroundworker thread. When I search google, people are saying try to refactor the code to use background worker. I am not sure how to do this as I need the background worker to have access to the UI elements. I think I need to use a single-threaded apartment (STA) thread. However, background workers are not STA?
The alternative of creating a new window is possible and using the windows UI thread. However, it is not advised to do lengthy process on a UI thread. I would need to pump for windows messages (I am getting debug warning in visual studio).
So I am not sure what is the best way forward...I might be missing something obvious....
Many thanks....
|
|
|
|
|
I have a rather complex user control for which I use RenderTargetBitmap to create an image that I can "print preview" or "print"; it takes an average of 700ms to render the image (no "saving").
On the other hand, I can do a full screen capture (using System.Drawing.Graphics) AND save the bitmap in about 120ms (where saving is probably the lengthy process).
If I was required to render my user control "several times a second" using RenderTargetBitmap, I would need a multi-core machine dedicated to just that.
Use multiple windows: one for user interaction, and the others for rendering.
|
|
|
|
|
What of the many MVVM frameworks would be recommended for a team that wants to start developing WPF/SL apps?
As a background the team is mainly experienced in VB6/Access VBA, and a lot of TSQL knowledge as well.
Obviously we have a lot to learn, but I'm not sure we want to start on the wrong step and start with the code-behind method.
At the moment I'm leaning toward Prism, but mainly because it seems to have the most complete documentation.
Or will we be taking a step to far, and should stick to code-behind until we have the experience?
|
|
|
|
|
MVVM Light now comes with training from Pluralsight. It's a good place to start.
|
|
|
|
|
I saw that, have you done the course? MVVMLight looked fairly good, enough to do it, without too much to digest. The VS snippets and templates where a nice help too.
|
|
|
|
|
I haven't done the course - primarily because I know MVVM Light pretty much inside out, and Laurent is using some of my codebase in there already. That reminds me, I really must poke him to update the attribution list to point back to my entries.
|
|
|
|
|
Have you heard about:
Catel
|
|
|
|
|
Thanks, looking at it now, certainly seems to be aimed at the type of apps we'll be creating.
I like the emphasis on documentation too.
|
|
|
|
|
I'm another vote for MVVM Lite from Galasoft, we were lucky enough to start with that before most of the others appeared.
You do know the Silverlight is dead, MS are no longer extending it and it has and EOL in 2022 or thereabouts.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I am worried about Silverlight, but has there actually been an official announcement of its EOL? I was leaning towards Silverlight as it can do desktop client and also be easily web hosted too.
Given that most of our apps are Access 97 and VB6, and were still on XP...with Win7 maybe appearing next year. The Win Store apps are a no go, and I've not seen any actual Win Store apps that aren't glorified web pages.
|
|
|
|
|
I'm pretty sure there has been an official announcement of the EOL.
If you don't actually need the web browser IE the apps are completely behind the firewall the WPF/WCF/Click once is a solution, it is the one I will be pushing. The reason we went to Silverlight was that it allows a very rich UI, the bonus is that once you have a reasonable depth on it is it FAST. It took us a year to get really conversant and develop our framework (code generator for stored procs and the WCF, build up a good set of snippets and styles, standardise our navigation) which allows us to push out an app at least twice as fast as an MVC developer and the UI is mush richer and faster performance.
The idea that you can code once and deploy on multiple form factors is still a ways off I believe, so I'm comfortable with WPF and a separate code base for any mobile requirements that come along. If you wxpect a mobile requirement it may be worth researching your data transport style (collections/json/odata etc) to make sure you don't end up needing a different service layer for mobile.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
First of all, what type of application are you creating?
Do you know why you are doing MVVM? A lot of people throw around 'it's great/separation of concerns etc.' without properly taking advantage of underlying strengths of the pattern.
Unless you are creating massive applications with big managed teams, skip Prism. I'd go with Caliburn Micro or MVVMLight..
Before making a decision you should create a basic application with a couple of forms, one with one to many/parent child data, a lot of buttons/menus and throw in some mouse/drag click events. This may sound trivial from a traditional Access/VB6 form perspective but can take a lot of work to function successfully in MVVM.
You might want to look at this library I did to take out a lot of the pain associated with MVVM https://github.com/steinborge/ProxyTypeHelper
While not strictly a framework it greatly simplify view model creation. It works with PRISM and should work with other frameworks. It still maintains full MVVM i.e. no strong couple of view or view model.
The following code demonstrates a viewmodel using the library, using the traditional method would be a lot more code.
public string FirstName {get;set;}
public string LastName {get;set;}
[LinkToProperty("FirstName")] [LinkToProperty("LastName")]
public string FullName
{
get
{
return String.Format("{0} {1}", FirstName, LastName);
}
}
[PropertyChangedEvent]
void person_PropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e)
{
}
[LinkToCommand("RollBackChangesCommand")]
private void btnRollBackChanges()
{
}
[LinkToEvent("AddingNewItemEvent")]
private void DataGrid_AddingNewItem(AddingNewItemEventArgs e)
{
}
modified 19-Jun-14 0:35am.
|
|
|
|
|
The apps are usually basic LoB CRUD apps, outputting to word/excel is fairly common, occasional imports of raw data etc.
Most a small team users, though there are a few where that team is spread about the country.
Their lifetime is fairly long with not a massive amount of regular change, most apps will be <1 release per year, and some have never changed in the 10 years I've worked here.
I have seen others that point out for simple apps MVVM isn't a requirement, but I don't think we're big enough to support multiple types of approach. So although MVVM could be overkill for some apps, at least they'd all be consistent.
|
|
|
|
|
Here are a few more thoughts..
You don't need any of the aforementioned libraries to implement MVVM - it's just without some of their features UI interaction (even something as a simple as displaying a message box) and communication between modules can be difficult.
Another option is WPF Application Foundation. https://waf.codeplex.com
It's not being supported but provides some excellent documentation and samples on a concept of passing a IView interface to the view model:
https://waf.codeplex.com/wikipage?title=Model-View-ViewModel%20Pattern&referringTitle=Home
This allows you to call view (UI) operations from the view model without violating MVVM.
My experience with Prism is version 4, which has been out for years. It's kinda of a all or nothing approach. But Prism 5 breaks it out into separate parts - so you could use the MVVM library and not the Composition library. And as you mentioned it has excellent documentation.
|
|
|
|
|
Yes, in theory you don't need anything. My experience with this is that people that go this way end up in rubbish applications because they fall in exactly the same pitfalls everyone falls into. Then the people that recommended that you didn't need anything aren't there to help you out. Please, for your own sake, pick a framework that fits your application. Don't try to re-invent the wheel, these frameworks / toolkits / whatever you like to call them are out there for years and being used in production for years. Just pick one that you like and have a good feeling with and that fits you use-cases.
If you have a light-weight app, mvvm light can do everything you need and is probably a good option. If you need more (such as authentication, behaviors, nested user controls, resolve by naming convention, etc), pick something that supports that (for example, Catel[^]).
Another tip: don't pick an abandoned project if you want to use if for LoB applications. You'll end up fixing someone else's code that isn't maintained any longer.
|
|
|
|
|
I couldn't disagree more!
My experience is that often people who use a framework spend a great deal of their time trying to find out how to work around ways the framework's limitations in order to do something that would be relatively simple.
Of course, documentation and training is the key - if you and the team are allowed the time to learn a framework properly before using it in a real development, then all can be good, but that learning / experimenting time can equally well be spent learning the basics from the ground up and developing the features your project actually needs.
Another issue with frameworks can be the need to modify the framework in some way in order to do what is required - and then suffering because one cannot update to the latest version of the framework without some angst.
MVVM isn't really that hard - it's far simpler than many of the frameworks out there. And developing your own allows you to pick and choose features from other frameworks at will.
PooperPig - Coming Soon
|
|
|
|
|
Hello!
I have managed to bind a label's Content property to a static property in a class. But when I change the property, the label's content wont update.
XAML code:
<Window x:Class="WpfApplication1.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:WpfApplication1"
Title="MainWindow" Height="350" Width="525">
<Grid>
<Label Content="{Binding Source={x:Static local:MainWindow.Age}}" />
<Button Width="100" Height="100" Click="Button_Click" />
</Grid>
</Window>
C# code:
namespace WpfApplication1
{
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
}
private void Button_Click(object sender, RoutedEventArgs e)
{
age = age == 10 ? 11 : 10;
}
static int age = 10;
public static int Age
{
get { return age; }
}
}
}
I use the button to change the property Age between 10 and 11.
Works this bind only when the application starts/loaded?
It would be really neat if I can make this binding update the value in runtime. Btw I use .NET 4.0 and cannot change.
/Steffe
|
|
|
|
|
You need to raise a property changed event that tells WPF that the value it has bound to has changed. WPF isn't magic - it doesn't watch values to see if they have changed, it relies on you the developer telling it that the value has changed. So, to fix this, you need to implement INotifyPropertyChanged like this:
public partial class MainWindow : Window, INotifyPropertyChanged
{
public MainWindow()
{
InitializeComponent();
}
private void Button_click(object sender, RoutedEventArgs e)
{
Age = Age == 10 ? 11 : 10;
}
private static int age = 10;
public static int Age
{
get { return age; }
set
{
if (age == value) return;
age = 10;
RaisePropertyChanged("Age");
}
}
public event PropertyChangedEventHandler PropertyChanged;
private void RaisePropertyChanged(string propertyName)
{
PropertyChangedEventHandler handler = PropertyChanged;
if (handler == null) return;
handler(this, new PropertyChangedEventArgs(propertyName));
}
} Now, I don't really see any reasons why your property has to be static. Also, if I were writing this, I'd look at writing this using MVVM, so the logic of maintaining Age would be moved away from the code behind of the view all together.
|
|
|
|
|
You won't be able to call the non-static RaisePropertyChanged event from the setter of a static property.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Doh! Of course not. I was that busy thinking that I wouldn't use a static property that I got stuck in that mindset.
|
|
|
|
|
Pete's answer is almost there, except you can't raise a non-static event from the setter of a static property.
Pete Brown has the solution:
There are two ways to notify the binding system of property changes, both of which follow the same pattern as their instance-based relatives. The first is to create a static event named <propertyName>Changed . The second approach is to create a single event which is the static version of the INPC PropertyChanged event named StaticPropertyChanged .
So in your code, you would either have:
public static event EventHandler AgeChanged;
static int age = 10;
public static int Age
{
get { return age; }
private set
{
age = value;
var handler = AgeChanged;
if (handler != null) handler(null, EventArgs.Empty);
}
}
private void Button_Click(object sender, RoutedEventArgs e)
{
Age = (Age == 10) ? 11 : 10;
}
or:
public static event EventHandler<PropertyChangedEventArgs> StaticPropertyChanged;
private static void NotifyStaticPropertyChanged(string propertyName)
{
var handler = StaticPropertyChanged;
if (handler != null) handler(null, new PropertyChangedEventArgs(propertyName));
}
static int age = 10;
public static int Age
{
get { return age; }
private set
{
age = value;
NotifyStaticPropertyChanged("Age");
}
}
private void Button_Click(object sender, RoutedEventArgs e)
{
Age = (Age == 10) ? 11 : 10;
}
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|