I know that some people asked about this before. But it isn't clear enough for me :-) So. Is it possible to include forms or other lcl graphic component in a DLL so, for example, a DLL function can create or modify a form?
If it is not possible... There any initiative or way to try to participate and code it to get it?
Thans.
Regards.

Juan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110808/04ee9390/attachment.html>

I know that some people asked about this before. But it isn't clear enough for me :-) So. Is it possible to include forms or other lcl graphic component in a DLL so, for example, a DLL function can create or modify a form?
If it is not possible... There any initiative or way to try to participate and code it to get it?

Generally speaking, no. The LCL in the dll comes with it's own messagepump and you can have only one per process. What works for me: a modal form created in a dll. Modal forms are kind of "exclusive" for the process and having 2 message pumps isn't a problem. There is an issue when the dll is called from MFC. Details and workaround here:
http://bugs.freepascal.org/view.php?id=19327.
OSX requires the patch attached to
http://bugs.freepascal.org/view.php?id=19253.

Ludo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110808/d0cbba3b/attachment.html>

I have tried it. From main program, one button call a procedure in a DLL with a form. Inside this procedure I code this:

Application.Initialize;
Application.CreateForm(TForm2, Form2);
Form2.ShowModal();
Is this Ok?

What I can see is that main window in programa never is blocked so I can access both modal and main window. If I click twice button to get two modal windows from DLL, both are modal and now I can access last window created and main window.

2011/8/8 Ludo Brands

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110808/41b8dea9/attachment.html>

What I wrote in last message was about win32. In Mac main window remains innactive when I click button and get modal window :-)

Juan.
El 08/08/2011 17:28, "Ludo Brands" escribi?:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110808/6cd03cb5/attachment.html>

I have tried it. From main program, one button call a procedure in a DLL with a form. Inside this procedure I code this:

Application.Initialize;
Application.CreateForm(TForm2, Form2);
Form2.ShowModal();

Is this Ok?

In my apps I used Form2:=TForm2.create(nil); instead of Application.CreateForm(TForm2,Form2); I don't think that makes a lot of difference for the main (from dll perspective), modal window.

What I can see is that main window in programa never is blocked so I can access both modal and main window. If I click twice button to get two modal windows from DLL, both are modal and now I can access last window created and main window.

Are all controls working in both the main and the modal window? Clicking on buttons, entering data, tabbing from one control to another, etc.

Ludo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110808/d98322cd/attachment.html>

Yes. It's a nice thing. I put an edit control and I can type on it. But only in Windows. In Mac main window is blocked.
Juan.
El 08/08/2011 19:22, "Ludo Brands" escribi?:

modal

on

buttons, entering data, tabbing from one control to another, etc. Ludo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110808/e46995d5/attachment.html>

I don't think so. The main thread of the main application (may same be in Pascal or some other language) already attaches to the external GUI and I don't suppose it's allowed or makes sense to have the same thread create another GUI hook.

It might be possible to do

GUI2Thread.Execute;
  begin
   Application.Initialize;
   Application.CreateForm(TForm2, Form2);
   Application.Run;
  ...

in a thread.

(In the main program itself this is not allowed, as the LCL GUI environment is not reentrant, but I understand that the DLL uses it's own LCL GUI environment.)

Good luck (I never tested this) :) !

-Michael

Juan S?nchez wrote

But only in Windows. In Mac main window is blocked.

Windows uses messages to notify a running thread about a GUI event, so multiple GUIs per thread (even if IMHO not supported by the LCL) are possible in theory.

With Linux and Mac the GUI uses a blocking function returning when an event happens, so only one GUI instance per thread is possible.Using a thread per GUI in theory could help (only with multiple instances of the LCL GUI stuff).

-Michael

Thans Michael.

I have not developed with threads. I've tried the following. I do not know if it is right. The window is created from the main application, but you can not close it.

This code goes in DLL:

...

Type
    TGUI2Thread = class(TThread)
    private
    protected
      procedure Execute; override;
    public
      Constructor Create(CreateSuspended : boolean);
    end;

...

constructor TGUI2Thread.Create(CreateSuspended : boolean);
 begin
   FreeOnTerminate := True;
   inherited Create(CreateSuspended);
 end;

...

 procedure TGUI2Thread.Execute;
 begin
   Application.Initialize;
   Application.CreateForm(TForm2, Form2);
   Application.Run;
 end;

...

// Function exported and called from main window
procedure DllMessage(); export;
var
  GUI2Thread: TGUI2Thread;
begin
  GUI2Thread := TGUI2Thread.Create(True);
  GUI2Thread.Execute;
end;

Thanks a lot for your help.
Juan.

2011/8/9 Michael Schnell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110809/d8ba80ae/attachment.html>

Juan S?nchez wrote

Thans Michael. I have not developed with threads. I've tried the following. I do not know if it is right. The window is created from the main application, but you can not close it.

I did a lot of work with threads, but I did not use Lazarus in Windows and did not do dlls (or so's) with same. :(

On the first look the code looks good.

I don't know what DllMessage is.

If this is the code that is executed when the dll is initialized, creating the thread there might be OK, even if I think it would be more appropriate to have the main program call a dedicated function in the DLL to initialize the GUI.

In any case I think it is not a good idea to have the var GUI2Thread in a local context. I would do it outside of a function to allow for accessing it when necessary.

Does your code sample somehow work ?

-Michael

2011/8/9 Michael Schnell

Sorry for typing too fast (again :( ).

No, It's good. Thanks.

I'll try it so.

When I call DLL funtion (DllMessage) from main program, new Window shows but it's imposible to close it with close button in title bar. It only closes where I close main window.

Regards,
Juan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110809/e802499b/attachment.html>

Sorry for typing too fast (again :( ).

in fact I would try something like this:

var
   GUI2Thread: TGUI2Thread;
GUI2Application: TApplication
  procedure TGUI2Thread.Execute;
   begin
GUI2Application:= TApplication.create;
   GUI2Application.Title:='GUI2Test';
   GUI2Application.Initialize;
   GUI2Application.CreateForm(TForm2, Form2);
   GUI2Application.Run;
end;

Juan S?nchez wrote

The window is created from the main application, but you can not close it.

How are you trying to close it ?

If you close the Form Run should exit, but of course, before this the Form should be discarded from the screen and the memory.

Have fun,
-Michael

I did understand this, please try with the new created TApplication instance, too. But maybe this does not help in case the dll loading code already does create it's own Application instance. In case it uses the one created by the main program creating a new instance might help.

Did you create a button on the Form ? (Can you use the form designer to do this ?)

Regarding using the form designer: Of course you need to include the appropriate resource to have CreateForm create the correct form :) .

Maybe it's easier to for a first test create the form and it's components manually instead of using the complex functionality of "CreateForm"

Does clicking the button work ?

-Michael

Juan S?nchez wrote

Well. I've tried new method. Now DLL window closes but main window not... :-)) And now, I can get many Windows from DLL.

Sounds rather good :)

Yes. I designed forms with form designer.

So quite obviously the correct resource is included in the dll file.

Do buttons work ?

-Michael

Yes... I will testing more and more this evening at home as in windows as in mac and I'll inform. I will not stop :-) untill get it. Juan.
El 09/08/2011 15:35, "Michael Schnell" escribi?:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110809/1ad69dc8/attachment.html>

Juan S?nchez wrote

I will not stop :-) untill get it.

Brave man...

-Michael

In the past, there were some efforts to allow a DLL/so to use the GUI of the main program and e.g. create additional forms in that context.

AFAIK, this is possible by synchronizing the memory manager and passing some pointers for application and/or forms.

The downside is:
- I seem to remember that it is quite complicated to do
- this is only possible if the main program is done with Lazarus as well
- I don't know if the GUI designer can be used for this.

So your works seems to offer a better choice.

-Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110810/677898a5/attachment.html>

Yep. This is how it should be done. (The procedure to be queued is defined to have a parameter).

But I can see that I cannot close main windows with close button. I think that "GUI2Application.Run" doesn't end.

I never tried QueueAsyncCall in Windows and I do know that it once was buggy in Linux, so maybe it in fact does not work correctly.

-Michael

2011/8/10 Michael Schnell :

http://wiki.lazarus.freepascal.org/shared_library

Marcos Douglas

Re: Process messages.

I suppose I was not clear here. ProcessMessages needs to be called in the GUI2Thread, thus within the queued call (after Close).

-Michael

Michael Schnell wrote

I never tried QueueAsyncCall in Windows and I do know that it once was buggy in Linux, so maybe it in fact does not work correctly.

I use it for transferring control to a handler immediately after startup, apparently OK. Mostly Linux, some Windows, circa 2.4.x and 0.9.26 or later.

There should not be any difference (but speed) when running in a virtual machine.

-Michael

Sorry I never used Mac. Did you try Linux ?

-Michael

Hello, I don't know if it works, but FYI
http://wiki.lazarus.freepascal.org/Creating_LCL_Control_From_Libraries

2011/8/12 Michael Schnell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110812/fba69f37/attachment-0001.html>

Thans a lot.
I remember that one year ago I read it for another job. Now reading it I take in mind a couple of ideas that combined with work of that days and the tests I've made that days could result. I'll try it with both ideas... :-)

Juan.
El 12/08/2011 20:55, "Gast?n Dall&apos; Oglio"
escribi?:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110812/0598fe7d/attachment.html>

Dear Gast?n,

I'm trying to use reference from url you have write. I understand procces but, really, I don't know how it can be implemented because what are these objects: TRHandle, TRWinControl, FillRWinControlInterface, etc...

Could you help me to understand them?

Thanks a lot.

2011/8/12 Gast?n Dall' Oglio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110813/40be1025/attachment.html>

I sorry, I only know this link for the moment about this theme :( ... and I also failed to find such units: TRHandle, TRWinControl...

2011/8/12 Juan S?nchez

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110812/26e3b07a/attachment.html>

Ok. Don't worry. I've wrote to article creator and I hope he can help us.

Thanks.
Juan.

2011/8/13 Gast?n Dall' Oglio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110813/93c63eba/attachment-0001.html>

Ok, let me know if you perform some work in this theme, I'm interested in add this at my programs.
Thank you.

2011/8/13 Juan S?nchez

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110813/38098b97/attachment.html>

Of course! Author of page has respond me and I have yet source of article. I will begin review his method and see how mix with my work to get it. I will inform about every step.

Juan.
El 13/08/2011 16:18, "Gast?n Dall&apos; Oglio"
escribi?:

what are

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110813/e5ad0a4b/attachment.html>

Forgive me for the intrusion, but I'm brand new to Lazarus and trying to find the correct list to address with my questions. Example: What is the "General widget set restrictions" tab in the object inspector window?

The list here is clearly for the well-experienced and I don't want to clutter -- but I'm not having any luck finding the right list and the "forums" link on the Lazarus home page seems to be broken.

A pointer would be much appreciated.

Thanks

Curt Carpenter

2011/8/13 Curt Carpenter :

Forgive me for the intrusion, but I'm brand new to Lazarus and trying to find the correct list to address with my questions. ?Example: ?What is the "General widget set restrictions" tab in the object inspector window?

This is the right list.

The list here is clearly for the well-experienced and I don't want to clutter -- but I'm not having any luck finding the right list and the "forums" link on the Lazarus home page seems to be broken.

What link on what page?

A pointer would be much appreciated.

If you want a forum, try here:
http://www.lazarus.freepascal.org/index.php?action=forum

Vincent

Thanks for the instantaneous reply! I will post my questions here when I can't find the answers on my own. (I'm a Delphi user since D1, but think it's time for me to abandon ship there.)

When I installed Lazarus yesterday (Windows XP box), the Lazarus directory included a shortcut to
http://www.lazarus.freepascal.org/modules.php?op=modload&name=PNphpBB2&file=index When I use this link, I get a "Not Found" report from my Firefox browser.

Can you point me to an answer to "What is the "General widget set restrictions" tab in the object inspector window?" A pointer to the correct place in the docs would be most helpful, since I'm trying to learn how to use those as well, and
need the experience.

Thanks again!

Curt

Vincent:

Yes, that link (
http://www.lazarus.freepascal.org/index.php?action=forum ) is great, Thanks again.

2011/8/13 Curt Carpenter

Can you point me to an answer to "What is the "General widget set restrictions" tab in the object inspector window?"

They are features that don't work on every platform. The GUI is not very intuitive though. It has an image for each platform with is either colored (supported platform) or geyed (not supported platform).

Juha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110814/fa96a258/attachment.html>

Thanks for the reply. It is a good, useful feature, I think. I discovered that if you right-click on a restriction, a window opens giving more information about the restriction.

It seems that this is a new feature that's not been covered in the documentation yet. Would you consider adding your note to the document wiki? (I don't know enough to do it myself yet).

Thanks again.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110814/94e01c38/attachment.html>

Curt Carpenter wrote

Forgive me for the intrusion,

No problem, but don't hijack a running communication thread !

-Michael

Juan S?nchez wrote

Of course!...

A year ago I did some investigations on doing two main windows with Delphi. Maybe you might want to read this.

http://forum.madshi.net/viewtopic.php?f=5&t=5274

-Michael

Juan S?nchez wrote

. I've discovered a simple method that seems to run ok on both Win and Mac.

You don't create the application instance but you initialize it.

Seemingly this does not harm the Application instance of the main executable. So it seems like the DLL automatically instantiates it's own independent Application instance (and has its own "Application" variable to manage same).

This in fact is possible. You might want to verify this by printing both the Application pointers via IntToHex(integer(Application)), 8) ) and verify that they are different.

As you don't use a thread, I suppose Application.Initialize in the DLL re-attaches the GUI framework to the main thread. I suppose this will freeze or destroy the GUI of the main program. This might or might not be desirable. I think it is not desirable, as e.g. TTimers are handled via the GUI binding.

You might want to check if the GUI and/or the TTimers of the main program are still workable wile/after the DLL's GUI is displayed.

-Michael

2011/8/15 Michael Schnell

Exact. I was surprising about what DLL does. I think as you. It seem that DLL instantiates it's own independent Application instance, but I did't expect this would work. I discovered that in Mac it's not necessary to initialize Application instance in DLL. In fact, InitAppDLL and TermAppDll are not necessaries in Mac, only in Windows.

Ok. I'll do it.

In main program simple controls as edit and buttons work ok. I'll test about TTimers and other controls. Only thing I've seen until now is that when a message is displayed from dll form, in Windows I get an error closing main windows if dll form is visible with this message box. In Mac this is not so because a message box from dll make all forms disabled until you close this modal message window.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110815/da8dfd26/attachment-0001.html>

Hello again :-)

I've included a TTimer in main form. It shows a message at start and every interval it changes a label (alternatively 1/2). I can see that it continues running (changing 1 to 2 and 2 to 1) ever if dll form is shown both in Mac and Win.

Juan.

2011/8/15 Michael Schnell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110815/f7b9ea1a/attachment.html>

I am really astonished how this is able to work without a thread. So maybe both event queues are alternately handled sucked from. Or maybe only a single event queue is created and fed from both GUIs. I'll think about a way to find out what is happening...

-Michael

I'm too. Now I've finished test it on Linux and it works too. In Scientific Linux 6.0 with last Lazarus snapshot and FPC 2.4.4. Please. Tell me about what you discover. I'll do it too. Juan.
El 15/08/2011 16:57, "Michael Schnell" escribi?:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110815/a0f0f4c3/attachment-0001.html>

Hello,

here is the screenshot of a simple application in Win32 (in C++) calling DLL with form made in Lazarus :-)

Juan.

2011/8/15 Michael Schnell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110815/17e239d4/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: dlltest.png
Type: image/png
Size: 38723 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110815/17e239d4/attachment-0001.png>

2011/8/15 Juan S?nchez :

What about memory leaks. Have you tested?

Marcos Douglas

No yet. I'm making some tests now.
El 15/08/2011 21:14, "Marcos Douglas" escribi?:

2011/8/15 Juan S?nchez : > Hello, > > here is the screenshot of a simple application in Win32 (in

C++) calling

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110815/e06b76ee/attachment.html>

Hello,

this is the first very basic test:

Objects:
- main app: basic win32 app.
- dll with a form and a button to display a message box.

For this test, libdllform.dll is copied to libdllform1.dll to let in a test be loaded and executed twice (with two dlls).

Result:

Main App disk size (stripped): 9K
DLL disk size (stripped): 1663K
App mem usage without dll link: 820K
App mem usage with dll linked and form: 4192K
App mem usage with dll linked and form with messagebox: 4196K App mem usage with two dlls linked and forms: 7688K App mem usage with two dlls linked and forms with messageboxex: 7692K

Juan.

2011/8/15 Marcos Douglas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110816/a6be2f71/attachment-0001.html>

Marcos Douglas wrote

What about memory leaks. Have you tested?

+1

Thanks for providing your results, Juan.

Some more background:

(AFAIK:)

A normal Lazarus/FPC (and Delphi) created SO (shared object) ( = Windows DLL, Linux .so, Mac ???, ...???) instantiates its own independent memory manager. This is perfectly fine, as it does not know in what language the calling program is done and what memory manager same uses.

The Plus is that it just works, the Minus is that the interface between the program and the SO always needs to be "flat" (just using simple C compatible types, no Objects no Pascal Strings etc.)

The SO is not supposed to do anything on it's own but is just a "library" of functions that can be called

Thus such a SO is not supposed to provide any kind of GUI, neither reusing the GUI of the main program nor creating its own GUI binding.

As a result e.g. TTimer will not work (or at least is not supposed to work).

A SO can use threads to implement "free running" activities. AFAIK, you can use TThread instances for this, but any normal (portable, LCL-defined) communication with the main Thread (such as TThread.Synchronize and Application.QueueAsyncCall) is not allowed.

Now it does make sense to use Pascal SOs from Pascal programs (e.g. for creating a "plug in" system).

Here it is highly desirable to use a non-flat interface, communicating objects and Pascal stings. This in fact is possible (I did test it with Delphi but AFAIK something similar is provided for Lazarus/FPC as well) by using a memory manager in the SO that hooks into the main program's memory manager.

Now in the end a SO-designer might want to provide a GUI for his SO. Here in theory two alternatives are possible (1) plugging into the GUI of the main program and (2) do a completely independent GUI.

For (1) is seems obvious that the main program needs to be done in Lazarus/FPC as well and a common memory manager needs to be used. (thus aiming to a very tight integration).

For (2) the main program does not need to be done in Lazarus/FPC and it is not necessary (but possible) to use a common memory manager (thus aiming to a rather self-contained SO). IMHO, to make this decently work, the SO needs it's own independent "main thread" and do a GUI binding (aka TApplication instance) for same. With that normal GUI work and things like TTimer, TThread.Synchronize and
Application.QueueAsyncCall can work (completely internally in the DLL). How to do a notification of events generated in the DLL onto the main program (and vice versa) is an additional question. It should be achieved e.g.by Application.QueueAsyncCall using the other site's TApplication instance in case the main project in fact is done by Lazarus and by some kind of "callback" in case of the main program done somehow else.

Conclusion:

It would be great, if Lazarus would provide a kind of "SO-Application" project prototype that allows for all this in a decently reliable and verified and portable way.

The user should be allowed to select if (s)he want to use

(a) a common memory manager or not ("Yes" forces that the main program is done in Lazarus, too) and
(b) no, a shared, or an independent GUI ("shared" forces a common memory manager)

for the SO.

Of course some support for the main program for providing the appropriate hooks for the SO needs to be necessary.

have fun :-) ,
-Michael

well, all of this would be a moot conversation if fpc actually did something with the "package" application.

In delphi, the program type "package" is just that what you are trying to do:
- a SO that has a shared environment with the exe, thus allowing to do away of all the limitations you described

Take for instance Delphi 7.

Every program can be build in one of 2 ways =>
1) monolithic build
- everything you need is build-in one giant exe and smartlinking is applied (if optioned)
- if you want to use so's; you would have to load them manually through LoadLibrary
- if you want to use packages (*.bpl) from this setup => use LoadPackage. It would instantiate one (!) new rtl environment shared by all the loaded packages, but still separate from your main program

2) with a set of "runtime packages", dynamically linking
- your set of "runtime packages" are scanned recursively for dependancy on other packages, who are all added to a set of "selected runtime packages"
- the "selected runtime packages" and their units' contents are dynlinked in the main program
- EVERY package has as a requirement the RTL package (in Delphi 7 rtl70.bpl)

A smart algorithm is used to "register" the packages (and the main program is one as well in this context) on startup/initialization of the package in an "in order" fashion, which does the loop over the package's units' initializations.

in other words, with this setup, one would get following: === setup
main.exe build with runtime packages "mypackage"
mypackage.bpl has dependencies rtl70
=== real runtime packages
main.exe is dynlinked with rtl70.bpl, mypackage.bpl === load order
main.exe -- rtl70.bpl -- mypackage.bpl
=== rtl70.bpl:registerpackage call order/initialization order rtl70.bpl -- mypackage.bpl -- main.exe

And guess what is contained in rtl70? the SHARED memory manager, sysutils/system, classes, ...

Likewise, the classtypes are unique because the used units are scanned in that registerpackage procedure to ensure that there are no 2 packages/exe that share the same unit!

There are however 3 different kinds of packages (to make this again about Lazarus and draw the parallels with Delphi)
- runtime only => the real workhorse with the definitions/code of your library
- designtime only => stuff that interacts with the IDE (Delphi) and a runtime package, like property editors, designers, ...
- designtime+runtime => all rolled into one => the question is, why would you need IDE-specific property editors in your production code for instance?

kind regards,
Dimitri Smits

Michael Schnell wrote

The Plus is that it just works, the Minus is that the interface between the program and the SO always needs to be "flat" (just using simple C compatible types, no Objects no Pascal Strings etc.)

This is not entirely true. _ANY_ RTL state is duplicated. This means that other process resources like e.g. standard I/O handles are also only usable in a very limited manner.

This also goes for the thread implementation, though I'm not sure about this, see below.

A SO can use threads to implement "free running" activities. AFAIK, you can use TThread instances for this, but any normal (portable, LCL-defined) communication with the main Thread (such as TThread.Synchronize and Application.QueueAsyncCall) is not allowed.

I'm not even sure if tthread is allowed. What was your testprogram?

I've told you already a thousand times that this ONLY fixes the state of the memory manager, not the rest of the RTL and LCL state. Thus this will solve nothing, since there are still two different copies of the sysutils state that handles the message pump. (and the LCL parts that actually implement it)

So yes, it solves the ansistring problem, no it doesn't solve the .synchronize problem.

project prototype that allows for all this in a decently reliable and verified and portable way.

The only safe solution is to avoid any duplicated state, RTL or LCL.

But that is not a matter of project, but of engineering, and a bit of engineering that is waiting for sb to implement it.

It is not a matter of project, since a project in lazarus can only instrument the FPC compiler and RTL, and for this to be resolve, massive changes to those are needed first.

Marco van de Voort wrote

What was your testprogram?

I never did any tests on SOs with Lazarus. I did some tests with Delphi ages ago. So I would need to retest anything it it's important.

So yes, it solves the ansistring problem, no it doesn't solve the.synchronize problem.

This is obvious and this is what I wanted to say, as well. I there is only one main thread and only one copy of of "the LCL" (in fact the Application instance) there is only one event queue and thus only the main thread of the main program will be notified ("synchronized") The only chance to have the SO work on its on is to have another totally independent TApplication instance (and thus the static memory of the LCL) and its own mainthread.

Juan seems to have found out that the SO in fact automatically creates it's own Application instance (I can't comment if that is true). But as the SO seemingly in fact creates it's own static memory for the LCL, it should be possible to have it run as it's own independent application with it's own main thread and its own binding to the GUI framework. I don't see the major difference between this and two independent executables only here the same MMU memory mapping is used (and the main program is provided with some pointers to procedures defined in the SO).

The only safe solution is to avoid any duplicated state, RTL or LCL.

This would create a single application with a common GUI (and only one event queue). I feel that the other option to create a completely independent SO with its own main thread and completely independent LCL/Application should be easier to do. Of course here the mutual notification of upcoming events is an "interesting" task.

Of course this is not viable to introduce any changes in the current code base. Only an Add-on might be considered.

I'm very interested in seeing if Juan comes up with something useful and would like to test it.

-Michael

Well,

of course, this is very complicate theme. Reading all mails I can see that is a hard way. But, I've designed a basic prototype to see if it can be useful.

Based on the fact that every dll has its own application system, this prototipe includes a unit with a class that all forms in a dll can use for some protocols needed to all run wel. I found that there was an important problem. When a main form calls a dll function to create a formfrom dll, dll "subsystem" runs ok but there are several problems when user wants to include modal forms from dll forms. These modal forms include message box. In this cases, main form is independent and never goes to disabled and if user closes this main form application crashes.

To resolve this problem, I've designed this prototype. I've tested it on Win32 only both in Win32 native an Win32 GTK and it runs ok. As my English is not rich enough :-) I think that it's better to attach source to let everybody test it. All functions are commented and also functions unit to be included in all dll units is commented.

I hope it will be a useful idea.

Regards,

Juan.

2011/8/17 Michael Schnell

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110818/ff1da32f/attachment-0001.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: dllgui.zip
Type: application/zip
Size: 8066 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110818/ff1da32f/attachment-0001.zip>

Tested on Mac. It seems to work fine.

El 18 de agosto de 2011 10:23, Juan S?nchez escribi?:

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110818/00fd7ddf/attachment.html>

Tested on Mac. It seems to work fine.

I'm afraid I have less luck. It crashes with a sigsegv on win32 (XP sp2) when I click on "create Dll Form".
When debugging with gdb I can't get a stack trace. When tracing in the dll it crashes somewhere at the end of createform before or in Show. The crash location changes depending on where I put a breakpoint, which indicates something going wrong in the message loop (events). Attaching the Visual Studio debugger to test.exe gives a partial stackframe. The last real address is APPPROCESSMESSAGES +352. That is the return address from DispatchMessageW(@AMessage)DispatchMessageW(@AMessage). Again the message loop. This is APPPROCESSMESSAGES from the test unit, not the dll.

Ludo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110818/5aec9a58/attachment.html>

In my win7 there isn't problem. I've just test it on Linux (scientific Linux 6.1) and it works well too. I'll try it to test it on xp. If you get this error clicking this button maybe because dll or procedures hadn't been found and loaded.
El 18/08/2011 15:10, "Ludo Brands" escribi?:

stackframe.

The last real address is APPPROCESSMESSAGES +352. That is the return

address

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110818/7ef70eab/attachment.html>

In my win7 there isn't problem. I've just test it on Linux (scientific Linux 6.1) and it works well too. I'll try it to test it on xp. If you get this error clicking this button maybe because dll or procedures hadn't been found and loaded.

Didn't I mention that I traced in the CreateForm in the dll ;) Dll not found and calling an invalid address would give a nice stack trace which isn't the case here.

Ludo.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110818/cf9943b3/attachment.html>

Yes. Sorry :-) As soon as I can test it on xp I'll write. I hope test it in an hour.
El 18/08/2011 16:00, "Ludo Brands" escribi?:

In my win7 there isn't problem. I've just test it on Linux (scientific

Linux

6.1) and it works well too. I'll try it to test it on xp. If you get this error clicking this button maybe because dll or procedures hadn't been

found

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110818/39773772/attachment-0001.html>

Hello again,

I've just test it on Windows XP SP3 with last Lazarus snapshot and it works well for me.

Juan.

2011/8/18 Ludo Brands

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110818/1ba48502/attachment.html>

Juan S?nchez wrote

Based on the fact that every dll has its own application system,

Did you in fact verify this (different hex values of the content of the "Application" variable) ?

I found that there was an important problem. When a main form calls a dll function to create a formfrom dll,

I feel that if there are two different "Application" objects this can't work decently. Each "Program" (main program and DLL) need to do their GUI handling completely separate, as if they were independent executables. As said the communication between the "programs" might be an interesting task.

-Michael

2011/8/19 Michael Schnell

Yes, they've got different hex values both in main an dll.

I think as you. And making new tests I see as you that communication between these in fact "programs" might be an interesting task.

In my prototype there is a little problem that I got main window goes disabled when modal windows are shown but in Linux main windows when is disabled, user can select it and close it while in other OS this window remains blocked.

Juan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110819/1e050872/attachment.html>

Juan S?nchez wrote

Yes, they've got different hex values both in main an dll.

IMHO this proves that the complete static memory of the LCL is duplicated. So in fact it should be possible to overcome the fact that "the LCL is not reentrant" and have the Shared Object create it's own independent GUI.

OK. My impression that each TApplication instance needs it's own thread to work decently. Only this way the two Event queues that are created (even if in Windows the Event queues are implemented using the Message Queue for the main Window), can work decently and independent. I suppose this can be done just by doing Application.Run in the Execute procedure of a TThread instance.

I think as you. And making new tests I see as you that communication between these in fact "programs" might be an interesting task.

My suggestion is first to find out if/how a completely independent GUI for the main application and the Shared Object can be made decently working on all OSes.

After that try to do a mutual notification. This needs to be done via the appropriate event queue, and thus best by
Application.QueueAsyncCall, using the other sites Application object. Of course a DLL call needs to be implemented to provide the pointer to the Application Object to the other site.

have fun,
-Michael

Hello again,

I've just test it on Windows XP SP3 with last Lazarus snapshot and it works well for me.

Juan.

Tried this on Windows 7 64 bit. Both forms show but when I move the dll form repetitively the program crashes with SIGFPE. Stack frame shows only UxTheme!HitTestThemeBackGround, the instruction that crashes is divsd %mm6,%mm0.

Ludo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110819/c58791fd/attachment.html>

Hello again,

I've just test it on Windows XP SP3 with last Lazarus snapshot and it works well for me.

Juan.

Tried this on Windows 7 64 bit. Both forms show but when I move the dll form repetitively the program crashes with SIGFPE. Stack frame shows only UxTheme!HitTestThemeBackGround, the instruction that crashes is divsd %mm6,%mm0.

Ludo

Could you go to Project - Project Options, click on Show Options and paste the command line parameters in a message? There has to be something different in our setup because all works fine for you and it fails on 2 machines on my side. I use fpc 2.7.1 and lazarus trunk.

dllgui is compiled on win xp with -MObjFPC -Scghi -O1 -gl -vewnhi -l -Filib\i386-win32 -FuC:\lazarus\lcl\units\i386-win32\win32 -FuC:\lazarus\lcl\units\i386-win32 -FuC:\lazarus\packager\units\i386-win32 -Fu. -FUlib\i386-win32\ -dLCL -dLCLwin32

test with -MObjFPC -Scghi -O1 -gl -WG -vewnhi -l -Filib\i386-win32 -FuC:\lazarus\lcl\units\i386-win32\win32 -FuC:\lazarus\lcl\units\i386-win32 -FuC:\lazarus\packager\units\i386-win32 -Fu. -FUlib\i386-win32\ -dLCL -dLCLwin32

Ludo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110819/dc0062d2/attachment-0001.html>

Of course,

these are options in Windows XP SP3 with Lazarus svn and FPC 2.4.4

dllgui
-MObjFPC -Scghi -O1 -gl -vewnhi -l -Filib\i386-win32 -Fuc:\lazarus\lcl\units\i386-win32\win32 -Fuc:\lazarus\lcl\units\i386-win32 -Fuc:\lazarus\packager\units\i386-win32 -Fu. -FUlib\i386-win32\ -dLCL -dLCLwin32

test
-MObjFPC -Scghi -O1 -gl -WG -vewnhi -l -Filib\i386-win32 -Fuc:\lazarus\lcl\units\i386-win32\win32 -Fuc:\lazarus\lcl\units\i386-win32 -Fuc:\lazarus\packager\units\i386-win32 -Fu. -FUlib\i386-win32\ -dLCL -dLCLwin32
Regards.
Juan.
2011/8/19 Ludo Brands

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110819/19a47d3d/attachment.html>

OK. My impression that each TApplication instance needs it's own thread to work decently.

Sorry, I don't understand that whole discussion. Delphi uses one Application instance, residing in another DLL (if Build with Packages), so FPC/Lazarus should do the same.

IMO it's time to implement decent handling of shared libraries in FPC, so that packages can be loaded at runtime, and rebuilding the IDE is not required any more.

DoDi

IMHO both kinds of "Shared Object GUI" might be useful for appropriate projects: (1) doing an extension to the main program's GUI and (2) doing a completely independent GUI. Of course (1) is only possible if the main program is done in Lazarus, as well, so the relevance of (2) is immediately obvious as well.

While (1) seems more obvious and does not need an additional thread, regarding that with Lazarus seemingly the shared object creates it's own completely independent static LCL memory and Application instance (2) might be easier to do.

-Michael