gui implementation approach in c# and .NET

Question

Hi,

I am a complete begginer in C# and .NET.
I am supposed to implement a GUI for a back-end process in C#.
The design I am required to follow, is to have a datagrid to display the data and as users click on rows, other representations appear.E.g. a graph of the data.
The gui is managed by a process, e.g. ProcessA. Another process, e.g. ProcessB, doing processing and comunicating with remote services generates the data that are to be displayed in the gui.
ProcessB and ProcessA are communicating via a shared memory. I.e. ProcessB updates a shared memory and ProcessB when it sees an update (via dirty bits) updates the corresponding data row in the grid.
My questions are:

1. is this design a usual approach for GUIs in .NET and such scenarios? I am asking because I personally do not like it at all, and was wondering if I am wrong not to like it.

2. Is there a better design for this, if the requirements is to have a really fast update of GUI? E.g. Should ProcessA and ProcessB, be just one process?

3. is this design possible to be implemented in C#? I.e. update a datagrid via shared memory? Because, I googled a bit and it seems that most tutorials describe that a datagrid is bound to a data source (for db access or xml file reading)

4. In C# is the gui updated completely i.e. it is fully redrawn each time an update to a row is made? In this case is the use of dirty bits to know which part of shared memory was updated so as to update the corresponding part of the gui, useless?

5. Is it possible to create a gui in a way so that it is automatically updated each time shared memory changes?

UPDATE: ProcessA and ProcessB are on the same machine

Thank you

Answer 1

1. using a GUI to talk to a WCF service is quite common. if that is what you mean by ProcessA and ProcessB.
2. you could use a single process but, you already have requirements...
3. you could update an ArrayList or something similar, and then use that as a data source
4. no, i don't think so
5. well, you have to realize exactly when the update takes place and create an event for that. thus your data source would be updated and so would your data grid

Answer 2

1. You can use EventWaitHandle to signal between the processes, or use WCF. Sending data between the processes via shared memory is certainly the fastest way, but WCF is maybe nicer. (For speed check my blog post)
2. If you can have them in the same process it might be a good idea, and just have separate threads
3. Yes and no. You can pass the data via shared memory (using memory mapped files), and then you need to deserialize the data into a managed object which can be bound to the datagrid. Then again, you could create a reader/list on top of the memory mapped file, which reads and deserializes one element at a time as they are bound to the grid.
4. If you can detect which data has changed and only update that gui part, that is a good approach. If you use dirty bits in shared memory, or expose a richer service layer in WCF with duplex binding which has callback methods on the different data, that is more of a design option.
5. With signalling you can achieve this. The server signals what part has changed, the client picks up the signal and updates accordingly.

In general a client/server approach with a defined interface and methods creates cleaner code, and you know what each part does. Using shared memory and for example signaling creates a tighter coupling, and reading the code will not immediately tell you what is going on as it's more complex (in my personal opinion). That said, if speed is of utmost, and I mean utmost importance, use shared memory. If not, go for WCF and named pipes binding, with a duplex service contract. It's clean, and reusable.

Answer 3

By Process do you mean thread? Or are we talking a GUI and a Windows service?

If you're using threading, shared memory is fine. If they are actual processes the "correct" way is to create a WCF service over named pipes for on machine inter process communication. (It also makes moving processes off the machine really easy). This way you can use a duplex (two way) WCF binding to update your Gui when the data changes.

By the sounds of things you need threads more than processes. In .NET there is a class called BackgroundWorker that is designed exactly for this sort of scenario. The big gotcha to look out for is that that if you need to update the gui from a background thread, you need to use the Gui thread dispatcher. http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx

It may be a little bit of a learning curve, but I would highly recommend you look into using WPF and MVVM to do this. It's a gui framework that lends itself very nicely to binding to dynamic data.