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
Am 27.06.2012 15:59 schrieb "kyan" :
>
> 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 por
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 su
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
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.
Ho
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
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 fr
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 L
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 ob
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
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)
C:\development\lazarus\components\VirtualTreeView\VirtualTrees.
>> 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
12 matches
Mail list logo
