Can such an alternative entry point in the main unit be called by
a shared library, i.e. either resolved at load time or with the main
binary reopened like a library? Or is the only way to pass a main-
program entry point to a shared library by using it as a parameter
to a procedure?
I
I'm getting the below error messages and I suspect virtualstringtree /
VirtualTrees.pas is the cause.
The virtualtrees.pas line it objects to is:
TVTDragManager = class(TInterfacedObject, IVTDragManager,
IDropSource, IDropTarget)
Mark Morgan Lloyd wrote:
Can such an alternative entry point in the main unit be called by
a shared library, i.e. either resolved at load time or with the main
binary reopened like a library? Or is the only way to pass a main-
program entry point to a shared library by using it as a
I am sure that this has been asked before but I couldn't find an answer.
I am in the process of porting a large application consisting of an
exe and many dlls from Delphi7 to FPC 2.7.1/Lazarus for Windows/WinCE
with hopes of being able to finally port it to Linux. I have managed
to overcome all
Le 27/06/2012 15:58, kyan a écrit :
I am sure that this has been asked before but I couldn't find an answer.
I am in the process of porting a large application consisting of an
exe and many dlls from Delphi7 to FPC 2.7.1/Lazarus for Windows/WinCE
with hopes of being able to finally port it to
Hello,
Regular exceptions, those raised with the raise keyword are always
trapped by try..except blocks but you have to make sure that EVERY
method in the DLL that is called by the host exe has such a construct so
as not to let the exception escape.
However, there are exceptions that come
On Wed, 27 Jun 2012, Antonio Fortuny wrote:
Le 27/06/2012 15:58, kyan a écrit :
I am sure that this has been asked before but I couldn't find an answer.
I am in the process of porting a large application consisting of an
exe and many dlls from Delphi7 to FPC 2.7.1/Lazarus for Windows/WinCE
Le 27/06/2012 16:14, OBones a écrit :
Hello,
Regular exceptions, those raised with the raise keyword are always
trapped by try..except blocks but you have to make sure that EVERY
method in the DLL that is called by the host exe has such a construct
so as not to let the exception escape.
Thank you all for your replies.
Regular exceptions, those raised with the raise keyword are always trapped
by try..except blocks but you have to make sure that EVERY method in the DLL
that is called by the host exe has such a construct so as not to let the
exception escape.
As I already
On 27-6-2012 16:22, Antonio Fortuny wrote:
Le 27/06/2012 16:14, OBones a écrit :
Hello,
Regular exceptions, those raised with the raise keyword are always
trapped by try..except blocks but you have to make sure that EVERY
method in the DLL that is called by the host exe has such a
Apologies for my poor threading. Sven said:
Unix based systems might be a different topic altogether. I've no
experience regarding cross module excetions on *nix, so I can't
comment whether it works or not...
Summa summarum: don't let exceptions travel past the DLL boundary. One
might be
11 matches
Mail list logo
