how to create a thread and a modal dialog from a regular dll?

On Fri, 3 Jun 2005 09:16:06 -0700, "MechSoft"
<me******@discussions.microsoft.com> wrote:

Hi, there,

I have a multi-threaded non-MFC program that will include a regular dll
which would be part of the user interface, possibly a dialog based interface.
I would prefer to have the user interface dll run on its own thread. How to
do that? I can't find the answer from the msdn knowledge base.

Threads and DLLs are separate things; a DLL can start a thread, and a
program can call DLL routines from different threads.

If I understand what you want to do, it's probably to call a routine
in the DLL -- StartMyDllUserInterface(), for instance -- and within
that, begin the thread (_beginthreadex) to handle the UI for your DLL.

Note that the thread will require its own message loop, and be careful
not to update UI elements from multiple threads (this causes
deadlocks).

Communication back to the main program will depend on what it expects,
and whether you're in control of how this works. I would need more
details to give definite advice.

Also, you may end up with a confusing interface if you expect things
like keyboard focus, etc., to work well between the main program and
your separate UI thread.

--
Phillip Crews aka Severian
Microsoft MVP, Windows SDK
Posting email address is real, but please post replies on the newsgroup.

Thank you very much for your prompt response. It is very helpful to me.

Yes, my user interface dll will export a function to the application so that
the application can call it to launch the interface. In the function, as you
named, StartMyDllUserInterface(MyInterfaceClass*), the appplication will pass
a pointer which contains all functions that the UI dll needs to communicate
with the application. Most communications are one-way from the interface to
the application. The application is like a database to the UI. The interface
Dll will also export another function to allow the application to inform the
UI of data changes.

With the helpful information from your response, I think I need to create a
user-interface thread from the exported function "StartMyDllUserInterface". I
am going to look more to figure out the details. Any advice will be
appreciated.

Kate

"Severian [MVP]" wrote:

On Fri, 3 Jun 2005 09:16:06 -0700, "MechSoft"
<me******@discussions.microsoft.com> wrote:

Hi, there,

I have a multi-threaded non-MFC program that will include a regular dll
which would be part of the user interface, possibly a dialog based interface.
I would prefer to have the user interface dll run on its own thread. How to
do that? I can't find the answer from the msdn knowledge base.

Threads and DLLs are separate things; a DLL can start a thread, and a
program can call DLL routines from different threads.

If I understand what you want to do, it's probably to call a routine
in the DLL -- StartMyDllUserInterface(), for instance -- and within
that, begin the thread (_beginthreadex) to handle the UI for your DLL.

Note that the thread will require its own message loop, and be careful
not to update UI elements from multiple threads (this causes
deadlocks).

Communication back to the main program will depend on what it expects,
and whether you're in control of how this works. I would need more
details to give definite advice.

Also, you may end up with a confusing interface if you expect things
like keyboard focus, etc., to work well between the main program and
your separate UI thread.

--
Phillip Crews aka Severian
Microsoft MVP, Windows SDK
Posting email address is real, but please post replies on the newsgroup.

On Fri, 3 Jun 2005 11:24:04 -0700, "MechSoft"
<me******@discussions.microsoft.com> wrote:

"Severian [MVP]" wrote:

On Fri, 3 Jun 2005 09:16:06 -0700, "MechSoft"
<me******@discussions.microsoft.com> wrote:

>Hi, there,
>
>I have a multi-threaded non-MFC program that will include a regular dll
>which would be part of the user interface, possibly a dialog based interface.
>I would prefer to have the user interface dll run on its own thread. How to
>do that? I can't find the answer from the msdn knowledge base.
Threads and DLLs are separate things; a DLL can start a thread, and a
program can call DLL routines from different threads.

If I understand what you want to do, it's probably to call a routine
in the DLL -- StartMyDllUserInterface(), for instance -- and within
that, begin the thread (_beginthreadex) to handle the UI for your DLL.

Note that the thread will require its own message loop, and be careful
not to update UI elements from multiple threads (this causes
deadlocks).

Communication back to the main program will depend on what it expects,
and whether you're in control of how this works. I would need more
details to give definite advice.

Also, you may end up with a confusing interface if you expect things
like keyboard focus, etc., to work well between the main program and
your separate UI thread.

Thank you very much for your prompt response. It is very helpful to me.

You're quite welcome.
Yes, my user interface dll will export a function to the application so that
the application can call it to launch the interface. In the function, as you
named, StartMyDllUserInterface(MyInterfaceClass*), the appplication will pass
a pointer which contains all functions that the UI dll needs to communicate
with the application. Most communications are one-way from the interface to
the application. The application is like a database to the UI.
Be aware that callbacks to the application will be done in the context
of your thread! This may have unusual consequences unless the
application is carefully designed and written to handle calls from
arbitrary threads.
The interface
Dll will also export another function to allow the application to inform the
UI of data changes.
Since this function will be called from a different thread than the UI
thread, it should only post messages to the UI thread or UI windows.
It should not use SendMessage or any UI call that implies SendMessage
(i.e., SetWindowText, SetDlgItemText). Otherwise, you could have two
threads updating the same UI, which is dangerous and often causes
deadlocks.
With the helpful information from your response, I think I need to create a
user-interface thread from the exported function "StartMyDllUserInterface". I
am going to look more to figure out the details. Any advice will be
appreciated.

Your UI thread will probably look much like WinMain(); it will need to
create a window (or dialog box) and start a message loop.

If the main application also has a user interface, you may need to
become familiar with such calls as AttachThreadInput(). Here are some
articles that may help:

http://support.microsoft.com/default...kb;en-us;90975
http://support.microsoft.com/default...kb;en-us;97925

and especially:

http://msdn.microsoft.com/library/de...sdn_winthr.asp
--
Phillip Crews aka Severian
Microsoft MVP, Windows SDK
Posting email address is real, but please post replies on the newsgroup.

Thank you! Those references are very good readings. I have learnt quite a lot
today! And I have been able to display a dialog box already from the dll.
Thanks again,

Kate

"Severian [MVP]" wrote:

On Fri, 3 Jun 2005 11:24:04 -0700, "MechSoft"
<me******@discussions.microsoft.com> wrote:

"Severian [MVP]" wrote:

On Fri, 3 Jun 2005 09:16:06 -0700, "MechSoft"
<me******@discussions.microsoft.com> wrote:

>Hi, there,
>
>I have a multi-threaded non-MFC program that will include a regular dll
>which would be part of the user interface, possibly a dialog based interface.
>I would prefer to have the user interface dll run on its own thread. How to
>do that? I can't find the answer from the msdn knowledge base.

Threads and DLLs are separate things; a DLL can start a thread, and a
program can call DLL routines from different threads.

If I understand what you want to do, it's probably to call a routine
in the DLL -- StartMyDllUserInterface(), for instance -- and within
that, begin the thread (_beginthreadex) to handle the UI for your DLL.

Note that the thread will require its own message loop, and be careful
not to update UI elements from multiple threads (this causes
deadlocks).

Communication back to the main program will depend on what it expects,
and whether you're in control of how this works. I would need more
details to give definite advice.

Also, you may end up with a confusing interface if you expect things
like keyboard focus, etc., to work well between the main program and
your separate UI thread.

Thank you very much for your prompt response. It is very helpful to me.

You're quite welcome.

Yes, my user interface dll will export a function to the application so that
the application can call it to launch the interface. In the function, as you
named, StartMyDllUserInterface(MyInterfaceClass*), the appplication will pass
a pointer which contains all functions that the UI dll needs to communicate
with the application. Most communications are one-way from the interface to
the application. The application is like a database to the UI.

Be aware that callbacks to the application will be done in the context
of your thread! This may have unusual consequences unless the
application is carefully designed and written to handle calls from
arbitrary threads.

The interface
Dll will also export another function to allow the application to inform the
UI of data changes.

Since this function will be called from a different thread than the UI
thread, it should only post messages to the UI thread or UI windows.
It should not use SendMessage or any UI call that implies SendMessage
(i.e., SetWindowText, SetDlgItemText). Otherwise, you could have two
threads updating the same UI, which is dangerous and often causes
deadlocks.

With the helpful information from your response, I think I need to create a
user-interface thread from the exported function "StartMyDllUserInterface". I
am going to look more to figure out the details. Any advice will be
appreciated.

Your UI thread will probably look much like WinMain(); it will need to
create a window (or dialog box) and start a message loop.

If the main application also has a user interface, you may need to
become familiar with such calls as AttachThreadInput(). Here are some
articles that may help:

http://support.microsoft.com/default...kb;en-us;90975
http://support.microsoft.com/default...kb;en-us;97925

and especially:

http://msdn.microsoft.com/library/de...sdn_winthr.asp
--
Phillip Crews aka Severian
Microsoft MVP, Windows SDK
Posting email address is real, but please post replies on the newsgroup.