Hi, All:

If there is a more proper group for multi threads, let me know please.

I have a winform application written in C#.net with the capability to
work offline. If there is a network connection, then the application
will connect to the central database and retrieve data from/save data
into the central database. If there is no network connection, then the
application will save the data to a local xml file.

Here are my questions.

1. Is there an easy way to detect that the network is disconnected.
More specifically, the database is disconnected? Do I need to keep try
to select from a table and wait to the failed result to know it is
disconnected?

2. When the network is broken and the appl tries to connect to the
database, it will take a long time to get the failed connection from
database. the GUI will not respond in this period. I am thinking using
another thread to do all the database work.

3. With another threads doing all the database work, I am from C++
world, in C++ we have postmessage so that we can communicate between
two thread so that the GUI can send a message to the database thread
to retrieve data. And the when the database thread finished retrieve
data, it will send the result back to the GUI thread so the GUI
thread can handle the result. But, in C#, how do we implement this
kind of communication?

I search the internet and some example just have the worker thread
doing some sample work without communicate with the main thread at
all. What I need to know is How the main thread ask the worker thread
to do some task with parameters passed to the worker thread. Once the
worker finished the task, how does the work thread inform the main
thread the work is done and send the result back to main thread to
process.

Any examples /links will be appreciated.

Thanks a lot
-Rockdale

Hi,

> 1. Is there an easy way to detect that the network is disconnected.

See :
http://blogs.msdn.com/adarshk/archiv...16/323162.aspx to test for
network connectivity. You'll likely still have to what you do at this time
for db connectivity (but in almost all cases I suppose it should work) as
most often the real issue is the network not the db.

> 2. When the network is broken and the appl tries to connect to the
> database, it will take a long time to get the failed connection from
> database. the GUI will not respond in this period. I am thinking using
> another thread to do all the database work.

It's likely a connection timeout. Testing for network first allow to prevent
the db driver to run into this (unless the db is really unavailable because
of some other issue).

> 3. But, in C#, how do we implement this
> kind of communication?

Some more details could be needed. In general ADO.NET provides support for
async db calls. See http://msdn.microsoft.com/en-us/library/hz8wbs6k.aspx

--
Patrice

HI, Patrice:

Thanks for the reply. The network available change event is very
helpful to my situation.

The ado.net async calls is also an interesting feature. But it is kind
not what I wanted.

The GUI is a thread - call it GUIthread, the appl will sprawl another
thread - let's call it DBthread.

Say if user clicked a button to retrieve data(suppose this will take a
very long time), instead of do the data retrieving in the GUIthread -
which the GUI will freeze to wait for the data to return. I want to
send an event/message to the dbthread let it does the data retrieving.
and now GUIthread still can respond to end user. once the dbthread
finished retrieving, the dbthread will send an event/message back
GUIthread, inform GUIthread that the data is ready, the GUIthread then
can process the data.

I do not know how to pass data (query parameters and query result)
between those 2 threads, I do not know how GUIthread can send an event/
message to signal DBThread to start the task.

in MFC world, we have PostMessage so it is not a problem to me.
In C#, I can see lot of samples using delegate, but I am not exactly
know how it works.

Again, thanks for the links. It is very helpful.

-Rockdale



On Oct 17, 12:35*pm, "Patrice" <http://scribe-en.blogspot.com/> wrote:
> Hi,
>
> > 1. Is there an easy way to detect that the network is disconnected.
>
> See :http://blogs.msdn.com/adarshk/archiv.../323162.aspxto test for
> network connectivity. You'll likely still have to what you do at this time
> for db connectivity (but in almost all cases I suppose it should work) as
> most often the real issue is the network not the db.
>
> > 2. When the network is broken and the appl tries to connect to the
> > database, it will take a long time to get the failed connection from
> > database. the GUI will not respond in this period. I am thinking using
> > another thread to do all the database work.
>
> It's likely a connection timeout. Testing for network first allow to prevent
> the db driver to run into this (unless the db is really unavailable because
> of some other issue).
>
> > 3. But, in C#, how do we implement this
> > kind of communication?
>
> Some more details could be needed. In general ADO.NET provides support for
> async db calls. Seehttp://msdn.microsoft.com/en-us/library/hz8wbs6k.aspx
>
> --
> Patrice

Do you mean you are looking for a producer/consumer model such as
http://www.java2s.com/Tutorial/CShar...ndconsumer.htm ?

Else try http://msdn.microsoft.com/en-us/library/9xyf641a.aspx in which you
could find what you are used to. You have also one or two more things that
could help (such as the BackgroundWorker component that is easy to use and
could be enough for simple non blocking UI needs).

Ofr now I thought you were creating something from the ground up using C# or
do you intract with something else in whihc case the design has some
constraints on it ?
--
Patrice


"rockdale" <(E-Mail Removed)> a écrit dans le message de
news:b49db684-b972-4060-954a-(E-Mail Removed)...
HI, Patrice:

Thanks for the reply. The network available change event is very
helpful to my situation.

The ado.net async calls is also an interesting feature. But it is kind
not what I wanted.

The GUI is a thread - call it GUIthread, the appl will sprawl another
thread - let's call it DBthread.

Say if user clicked a button to retrieve data(suppose this will take a
very long time), instead of do the data retrieving in the GUIthread -
which the GUI will freeze to wait for the data to return. I want to
send an event/message to the dbthread let it does the data retrieving.
and now GUIthread still can respond to end user. once the dbthread
finished retrieving, the dbthread will send an event/message back
GUIthread, inform GUIthread that the data is ready, the GUIthread then
can process the data.

I do not know how to pass data (query parameters and query result)
between those 2 threads, I do not know how GUIthread can send an event/
message to signal DBThread to start the task.

in MFC world, we have PostMessage so it is not a problem to me.
In C#, I can see lot of samples using delegate, but I am not exactly
know how it works.

Again, thanks for the links. It is very helpful.

-Rockdale

Have you looked at BackgroundWorker component that is available in Win Form
designer's toolbox since VS2005?

It does exactly what you want: runs another thread from win form UI. You
simply use this component to kick off another thread to accessing database
and when the data access thread returns, you update the UI with data from
database.


"rockdale" <(E-Mail Removed)> wrote in message
news:b49db684-b972-4060-954a-(E-Mail Removed)...
HI, Patrice:

Thanks for the reply. The network available change event is very
helpful to my situation.

The ado.net async calls is also an interesting feature. But it is kind
not what I wanted.

The GUI is a thread - call it GUIthread, the appl will sprawl another
thread - let's call it DBthread.

Say if user clicked a button to retrieve data(suppose this will take a
very long time), instead of do the data retrieving in the GUIthread -
which the GUI will freeze to wait for the data to return. I want to
send an event/message to the dbthread let it does the data retrieving.
and now GUIthread still can respond to end user. once the dbthread
finished retrieving, the dbthread will send an event/message back
GUIthread, inform GUIthread that the data is ready, the GUIthread then
can process the data.

I do not know how to pass data (query parameters and query result)
between those 2 threads, I do not know how GUIthread can send an event/
message to signal DBThread to start the task.

in MFC world, we have PostMessage so it is not a problem to me.
In C#, I can see lot of samples using delegate, but I am not exactly
know how it works.

Again, thanks for the links. It is very helpful.

-Rockdale



On Oct 17, 12:35 pm, "Patrice" <http://scribe-en.blogspot.com/> wrote:
> Hi,
>
> > 1. Is there an easy way to detect that the network is disconnected.
>
> See :http://blogs.msdn.com/adarshk/archiv.../323162.aspxto test
> for
> network connectivity. You'll likely still have to what you do at this time
> for db connectivity (but in almost all cases I suppose it should work) as
> most often the real issue is the network not the db.
>
> > 2. When the network is broken and the appl tries to connect to the
> > database, it will take a long time to get the failed connection from
> > database. the GUI will not respond in this period. I am thinking using
> > another thread to do all the database work.
>
> It's likely a connection timeout. Testing for network first allow to
> prevent
> the db driver to run into this (unless the db is really unavailable
> because
> of some other issue).
>
> > 3. But, in C#, how do we implement this
> > kind of communication?
>
> Some more details could be needed. In general ADO.NET provides support for
> async db calls. Seehttp://msdn.microsoft.com/en-us/library/hz8wbs6k.aspx
>
> --
> Patrice

> I search the internet and some example just have the worker thread
> doing some sample work without communicate with the main thread at
> all. What I need to know is How the main thread ask the worker thread
> to do some task with parameters passed to the worker thread. Once the
> worker finished the task, how does the work thread inform the main
> thread the work is done and send the result back to main thread to
> process.
>
> Any examples /links will be appreciated.

The most adequate alternative in the .NET world for
- SendMessage(hwnd, ...) is Control.Invoke( ... )
- PostMessage(hwnd, ...) is Control.BeginInvoke( ... )

Both functions take a delegate which are ensured to run in the context
of the thread which created the control/form. Just check MSDN or
Google for "Invoke".

Guys, thanks for all the reply and I think backgroundworker is what I
am looking for.

Thanks
-Rockdale