I am having a C# application to sync data between PC and palm devices.
There are codes written like below:
showMessage("synchronizing Table1");
Sync(destTable1,sourceTable1);
Sync(destTable2,sourceTable2);
showMessage("synchronizing Table2");
// more code
How do I separate the actual process of synchronizing from displaying message?
Which design pattern to follow?
Thanks in advance...
You should run the sync process on a separate thread and inform the main thread of the progress. The main thread displays messages.
You can obtain this behavior using the BackgroundWorker class that has all the feature ready.
Related
I am creating winform to process (convert txt files to tiff) large amount of files. I put all the code behind a button (btnProcess). Is this a good idea? It works but I noticed when I go away from the winform and come back to this I see blank window until the process is complete. I heard about background worker. what is the purpose of background worker?
What you need here is multi-threading. That means that two (or more) threads of code would run in parallel. One of them would be the UI thread, the one responsible for drawing the window. In your case you are running your code in the UI thread and thus blocking the UI rendering while your code is running.
The purpose of the BackgroundWorker is to start an operation on a new thread and is what you need.
BackgroundWorker class
The BackgroundWorker class allows you
to run an operation on a separate,
dedicated thread. Time-consuming
operations like downloads and database
transactions can cause your user
interface (UI) to seem as though it
has stopped responding while they are
running. When you want a responsive UI
and you are faced with long delays
associated with such operations, the
BackgroundWorker class provides a
convenient solution.
The page I linked above contains a complete BackgroundWorker example.
It depends on your application. If this is a single purpose application that is not extremely long and the only problem is the screen doesn't paint. Which is what it sounds like to me, just throw an Application.DoEvents into the loop and be done with it.
I'm looking for less technical and more conceptual answers on this one.
I am looking to build a WPF application using .NET 4.5 for controlling a rover, (glorified RC Car). Here is the intended functionality:
The application and rover will communicate wirelessly by sending and receiving strings - JSON over TCP Socket.
The GUI will display multiple video feeds via RTSP.
A control panel - custom hardware - will connect to the computer via USB and these signals will be converted to JSON before being sent over the TCP connection and providing movement instructions.
The GUI will need to update to reflect the state of the control panel as well as the state of the rover based on data received.
I'm not sure which technologies to use to implement this, but from my research, BackgroundWorkers or Threads, and Asynchronous techniques would be things to look into. Which of these seems like a good route to take? Also, should I use TCP Sockets directly in the application or should/could I use WCF to provide this data?
Any wisdom on this would be great. Thanks in advance.
EDIT:
Here was the final implementation used and boy did it workout great:
Everything fell into place around using the MVVM pattern.
There were Views for the control panel and the networking component which each had a corresponding ViewModel that handled the background operations.
Updating the UI was done via databinding, not the Dispatcher.
Wireless Communication was done Asynchronously (async/await) via TCPListener along with the use of Tasks.
Serial Port Communication was done Asynchronously via SerialPort and Tasks.
Used ModernUI for interface.
Used JSON.NET for the JSON parsing.
Here is a link to the project. It was done over the course of a month so it isn't the prettiest code. I have refined my practices a lot this summer so I'm excited to work on a refactored version that should be completed next year.
As you are using .NET 4.5 you dont need to use Threads and background workers for your project. you dont need to take care of all of your threads. As WPF's Dispatcher is a very powerful tool for handling UI from other threads.
For TCP Communication i would suggest you to use TCP Client and TCP Listner with Async Callbacks. and use Dispatcher for Updating your UI.
For Displaying Cameras over RTSP, Use VLC.Net an Open source wrapper for VLC library good for handling many real time video protocols.
Use Tasks instead of Threads, set their priority according to your requirement.
You don't need WCF for your application.
As far as I can tell (I'm no expert), MS's philosophy these days is to use asynchronous I/O, thread pool tasks for lengthy compute operations, and have a single main thread of execution for the main part of the application. That main thread drives the GUI and commissions the async I/O and thread pool tasks as and when required.
So for your application that would mean receiving messages asynchronously, and initiating a task on the thread pool to process the message, and finally displaying the results on the GUI when the task completes. It will end up looking like a single threaded event loop application. The async I/O and thread pool tasks do in fact use threads, its just they're hidden from you in an as convenient a way as possible.
I've tried (once) bucking this philosophy with my own separate thread handling all my I/O and an internal pipe connection to my main thread to tell it what's happening. I made it work, but it was really, really hard work. For example, I found it impossible to cancel a blocking network or pipe I/O operation in advance of its timeout (any thoughts from anyone out there more familiar with Win32 and .NET?). I was only trying to do that because there's no true equivalent to select() in Windows; the one that is there doesn't work with anything other than sockets... In case anyone is wondering 'why of why oh why?', I was re-implmenting an application originally written for Unix and naively didn't want to change the architecture.
Next time (if there is one) I'll stick to MS's approach.
I am creating a program that interacts with a game and I want it to do the following:
Get a list of messages from the admins.
Let them display how often it is to be displayed
Simple enough right?
I'm not asking for code, just some ideas on how to handle the message and to handle the timing of each message?
Should I use a timer and keep the messages in memory?
I plan on storing this information in an xml file.
My question is more how should I handle displaying the messages on the given times efficiently?
Any suggestions?
I would use DispatcherTimer to achieve that.
DispatcherTimer runs on the UI/Dispatcher thread and not on thread pool thread, another reason to use it when you are doing UI operations with timer. Also one can set the priority of the dispatcher thread.
I have a highly multithreaded application , where threads are started from multiple places and i would like to know if i can hook into the running process and just get alerted whenever a new Managed Thread is spawned. I should be able to get the following information
The parent thread
New thread
the method from which the new thread is started like <className>.<methodName>
The application is in C# 3.5
As far as I know there is no way to detect when a thread starts. The best solution is probably not to create thread directly, but instead do it via a "thread manager" class that will raise an event when it starts a thread.
State should be handle within the thread processing logic.
I suggest you create a wrapper class which wraps the thread logic and reports it's status and other items as needed. I created such a class for a multi-threaded application where I could corral the status of the threads and pipe that information to the GUI in a standardized way.
Of course I had the luxury of designing it up front, to which, you may not have.
In my C# Desktop application, I want to show all temporary files in a datagridview but when the datagridview is loading, my program hangs and is not responsive until the datagridview is completely loaded.
How can I make it such that my application is still alive while execution is still going on?
Have a look at using
BackgroundWorker Class
The BackgroundWorker class allows you to run an operation on a
separate, dedicated thread. Time-consuming operations like downloads
and database transactions can cause your user interface (UI) to seem
as though it has stopped responding while they are running. When you
want a responsive UI and you are faced with long delays associated
with such operations, the BackgroundWorker class provides a convenient
solution.
Use BackGroundWorker to Load the grid. It is a separate dedicated thread. Read these articles before implementing
http://www.dotnetperls.com/backgroundworker
http://msdn.microsoft.com/en-us/library/cc221403(v=vs.95).aspx