Watch, Follow, &
Connect with Us

Welcome, Guest
Guest Settings
Help

Thread: C++ Builder/Delphi VCL form from VS DLL


This question is not answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 4 - Last Post: May 31, 2017 2:21 PM Last Post By: Remy Lebeau (Te... Threads: [ Previous | Next ]
Michael Thomason

Posts: 3
Registered: 11/15/15
C++ Builder/Delphi VCL form from VS DLL  
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 30, 2017 1:50 PM
All:

I wanted to see if anyone had experience and could answer a few more questions regarding Delphi/C++ Builder forms from DLL. I understand that all VCL forms run in the primary thread and you can host forms in a DLL. Here is my project layout:

1. I have a C++ Builder project which contains a "thread" which calls a Visual Studio DLL.
2. This Visual Studio DLL loads another C++ Builder (VCL based) DLL which displays a form on the screen.

Inside the Visual Studio is a thread which loads a C++ Builder VCL DLL and displays a form and contains its own message loop. The "visual studio" thread creates the form and contains it's own message loop.

VCL EXE -> Thread -> Visual Studio DLL -> C++ Builder VCL DLL -> Form

I checked Spy++ and there are two thread running in the process. One thread has a bunch of VCL forms and a TApplication object. Another has the progress form /w no application object.

It is working great but want to make sure there is no design issues here.

Edited by: Michael Thomason on May 30, 2017 1:52 PM
Rudy Velthuis (...


Posts: 6,890
Registered: 9/22/99
Re: C++ Builder/Delphi VCL form from VS DLL [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2017 6:35 AM   in response to: Michael Thomason in response to: Michael Thomason
Michael Thomason wrote:

All:

I wanted to see if anyone had experience and could answer a few more
questions regarding Delphi/C++ Builder forms from DLL. I understand
that all VCL forms run in the primary thread and you can host forms
in a DLL.

Don't do it. The forms will have a separate VCL, with diferent
addresses. This means that things like .Free and other memory
management issues will nto work, nor will RTTI, etc.

If you want to separate out code, use packages instead. These are ideal
for such purposes, as they are made for it. They do not need any import
units, they have no problems with types and addresses.

I still wonder why anyone wants to use DLLs for this purpose. Packages
are the best solution. But not that while C++Builder can use Delphi
packages, Delphi can't use C++Builder packages.

Anyway, more on DLLs:
"DLL dos and don'ts"
http://rvelthuis.de/articles/articles-dlls.html
--
Rudy Velthuis http://www.rvelthuis.de

"Try not to become a man of success but rather to become a man
of value."
-- Albert Einstein
Remy Lebeau (Te...


Posts: 8,201
Registered: 12/23/01
Re: C++ Builder/Delphi VCL form from VS DLL [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2017 9:07 AM   in response to: Michael Thomason in response to: Michael Thomason
Michael Thomason wrote:

I understand that all VCL forms run in the primary thread

More accurately, they run in whatever thread actually creates them at
runtime. Just like any other UI does. The Win32 API is not picky
about which threads run UIs, as long as those threads have message
loops. But the VCL is intended to be used in a single thread only,
generally the main UI thread, because it does certain things internally
that are not safe across thread boundaries.

and you can host forms in a DLL.

Yes, with caveats, if you are careful about threading and resource
usage.

Here is my project layout:

1. I have a C++ Builder project which contains a "thread" which calls
a Visual Studio DLL. 2. This Visual Studio DLL loads another C++
Builder (VCL based) DLL which displays a form on the screen.

If the C++Builder DLL is compiled to be self-contained (no runtime
packages, no shared RTL, etc), then it has its own copy of the RTL and
so this layout can be safe, if you can guarantee that the DLL is only
ever used in a single thread. But, if the DLL is compiled to share
packages/RTL with the main EXE, then all bets are off, and the DLL will
have to synchronize with the main UI thread properly when accessing UI
elements.

Inside the Visual Studio is a thread which loads a C++ Builder VCL
DLL and displays a form and contains its own message loop. The
"visual studio" thread creates the form and contains it's own message
loop.

You also have to keep in mind that a standard Win32 UI message loop is
different than a standard VCL message loop, since the VCL has extra
processing of internal messages before they are dispatched to UI
windows. So running a standard Win32 message loop in the Visual Studio
code may cause unexpected issues in the VCL code, depending on what
the VCL code is actually doing. At the very least, you might need to
export a function from the C++Builder DLL that calls the VCL's
TApplication::HandleMessage() function, and then have your Visual
Studio code call that function in a loop, letting the DLL do all of the
message retreive and processing logic for the calling thread. But, if
your VCL code is being used for just status displays, that may not be
necessary.

--
Remy Lebeau (TeamB)
Michael Thomason

Posts: 3
Registered: 11/15/15
Re: C++ Builder/Delphi VCL form from VS DLL [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2017 1:25 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy:

As usual a HUGE THANK YOU!!!!

As a note, I checked Spy ++ and there is no TApplication object created in the separate thread. I can add the callback but should I create the TApplication object manually.

Also wanted to clarify the following statement:...

then it has its own copy of the RTL and so this layout can be safe, if you can guarantee that the DLL is only ever used in a single thread.

I am assuming this follows same rules as EXE: the VCL form and all updating of the VCL form should run and be updated from a single thread. My DLL has other threads but nothing VCL related.


Remy Lebeau (TeamB) wrote:
Michael Thomason wrote:

I understand that all VCL forms run in the primary thread

More accurately, they run in whatever thread actually creates them at
runtime. Just like any other UI does. The Win32 API is not picky
about which threads run UIs, as long as those threads have message
loops. But the VCL is intended to be used in a single thread only,
generally the main UI thread, because it does certain things internally
that are not safe across thread boundaries.

and you can host forms in a DLL.

Yes, with caveats, if you are careful about threading and resource
usage.

Here is my project layout:

1. I have a C++ Builder project which contains a "thread" which calls
a Visual Studio DLL. 2. This Visual Studio DLL loads another C++
Builder (VCL based) DLL which displays a form on the screen.

If the C++Builder DLL is compiled to be self-contained (no runtime
packages, no shared RTL, etc), then it has its own copy of the RTL and
so this layout can be safe, if you can guarantee that the DLL is only
ever used in a single thread. But, if the DLL is compiled to share
packages/RTL with the main EXE, then all bets are off, and the DLL will
have to synchronize with the main UI thread properly when accessing UI
elements.

Inside the Visual Studio is a thread which loads a C++ Builder VCL
DLL and displays a form and contains its own message loop. The
"visual studio" thread creates the form and contains it's own message
loop.

You also have to keep in mind that a standard Win32 UI message loop is
different than a standard VCL message loop, since the VCL has extra
processing of internal messages before they are dispatched to UI
windows. So running a standard Win32 message loop in the Visual Studio
code may cause unexpected issues in the VCL code, depending on what
the VCL code is actually doing. At the very least, you might need to
export a function from the C++Builder DLL that calls the VCL's
TApplication::HandleMessage() function, and then have your Visual
Studio code call that function in a loop, letting the DLL do all of the
message retreive and processing logic for the calling thread. But, if
your VCL code is being used for just status displays, that may not be
necessary.

--
Remy Lebeau (TeamB)
Remy Lebeau (Te...


Posts: 8,201
Registered: 12/23/01
Re: C++ Builder/Delphi VCL form from VS DLL [Edit]  
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2017 2:21 PM   in response to: Michael Thomason in response to: Michael Thomason
Michael Thomason wrote:

As a note, I checked Spy ++ and there is no TApplication object
created in the separate thread.

There is an object created (it is created when the Vcl.Forms unit is
initialized), but not necessarily a window created. Two different
things. Spy++ only knows about windows.

I can add the callback but should I create the TApplication object
manually.

Don't create the TApplication object itself manually. It is created
automatically for you. However, there are cases where you might need
to pass the HWND from the main EXE's TApplication::Handle property to
the DLL and assign it to the DLL's TApplication::Handle property.

I am assuming this follows same rules as EXE: the VCL form and all
updating of the VCL form should run and be updated from a single
thread. My DLL has other threads but nothing VCL related.

Yes, if you can limit the usage to a single thread, you should be fine.
It does not necessarily have to be the main UI thread, though it
usually is.

--
Remy Lebeau (TeamB)
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02