Some weird issues with "Forms in DLL" lazarus / 31-LCL ---------------------------------------------------------------------- ExSystem · 2017-02-18 14:52 https://github.com/exsystem/EkuProductCatalogSolution There are two projects. EkuProductCatalogSupplierManager - Indicating the form inside DLL. EkuProductCatalogManager - The main project loading the form from the DLL. Some weird issues found, with the projects provided by the link above: 1. In project EkuProductCatalogManager: TFormMain.MenuItem1Click can load and display the form from EkuProductCatalogSupplierManager correctly. 2. If comment both 2 lines marked with (***) in unit EkuProductCatalogManager.View.FormMain of project EkuProductCatalogManager, the form dynamically loading from the DLL (by clicking TFormMain.MenuItem1Click) couldn't show.  Any idea about the problem? I'm using CodeTyphon 6.0, the latest version, contains FPC3.1.1, on Windows 10 (64bit). Thanks. ---------------------------------------------------------------------- Cyrax · 2017-02-18 22:04 You can't use Forms or other LCL stuff from DLLs. It is not supported. ---------------------------------------------------------------------- Akira1364 · 2017-02-18 22:36 Quote from: Cyrax on February 18, 2017, 11:04:40 pmYou can't use Forms or other LCL stuff from DLLs. It is not supported. By "not supported" do you mean "not officially supported or recommended by the Lazarus developers"? Because I imagine that's probably true. (Although there were a lot of Delphi apps that did this back in the day...) If you mean "not possible" though, that's not true. You definitely can... I've tested it a few times out of curiosity.  If I recall correctly, I had to make sure that the "Win32 GUI Application" checkbox was set to true in the project options menu. (This was on Windows, obviously.) EDIT: Yeah, I just tried it, and their code works perfectly fine (meaning the form shows as expected) if you compile "EkuProductCatalogSupplierManager.dll" with the "Win32 GUI Application" checkbox set to true. So they just need to do that and they should be good to go. ---------------------------------------------------------------------- ExSystem · 2017-02-19 02:23 Quote from: Akira1364 on February 18, 2017, 11:36:21 pmQuote from: Cyrax on February 18, 2017, 11:04:40 pmYou can't use Forms or other LCL stuff from DLLs. It is not supported. By "not supported" do you mean "not officially supported or recommended by the Lazarus developers"? Because I imagine that's probably true. (Although there were a lot of Delphi apps that did this back in the day...) If you mean "not possible" though, that's not true. You definitely can... I've tested it a few times out of curiosity.  If I recall correctly, I had to make sure that the "Win32 GUI Application" checkbox was set to true in the project options menu. (This was on Windows, obviously.) EDIT: Yeah, I just tried it, and their code works perfectly fine (meaning the form shows as expected) if you compile "EkuProductCatalogSupplierManager.dll" with the "Win32 GUI Application" checkbox set to true. So they just need to do that and they should be good to go. No, it doesn't work... Just a blank form showed up, no caption, no icon, no button since I've put a button on it. See https://github.com/exsystem/EkuProductCatalogSolution/blob/master/ LCLinDLL.zip   , that will work well, I don't know why? What's the differences with my projects and them? ---------------------------------------------------------------------- Akira1364 · 2017-02-19 03:25 Odd... tried it on the latest "normal" release of Lazarus/FPC and got the same result as you. Not sure why it works fine in trunk but not there..... however, using Release FPC/Lazarus, I boiled it down to: it works when the form is included as an "LRS" in the initialization section (which no one should be doing anymore), but not when it is included as an "LFM" (as is the proper way nowadays) in the implementation section. Again, I don't know why this is, exactly. It appears to be an entirely arbitrary limitation, as there is really no reason this shouldn't work all the time (and especially, it's strange that it works with an outdated form file format, but not a current one.) ---------------------------------------------------------------------- ExSystem · 2017-02-19 06:28 Quote from: Akira1364 on February 19, 2017, 04:25:38 amOdd... tried it on the latest "normal" release of Lazarus/FPC and got the same result as you. Not sure why it works fine in trunk but not there..... however, using Release FPC/Lazarus, I boiled it down to: it works when the form is included as an "LRS" in the initialization section (which no one should be doing anymore), but not when it is included as an "LFM" (as is the proper way nowadays) in the implementation section. Again, I don't know why this is, exactly. It appears to be an entirely arbitrary limitation, as there is really no reason this shouldn't work all the time (and especially, it's strange that it works with an outdated form file format, but not a current one.) Now it seems to work!  using LRS, and I embed TFrame from DLL successfully. ---------------------------------------------------------------------- Akira1364 · 2017-02-19 17:24 Good to hear. I'd still be quite interested to know why exactly it works with LRSes but not LFMs.. any Lazarus devs care to shed some light on it? ---------------------------------------------------------------------- ExSystem · 2017-02-20 03:36 Quote from: Akira1364 on February 19, 2017, 06:24:53 pmGood to hear. I'd still be quite interested to know why exactly it works with LRSes but not LFMs.. any Lazarus devs care to shed some light on it? There still some limitations: eg. I can't debug my DLL form/frame. You can have a try, and prove me wrong. ---------------------------------------------------------------------- Akira1364 · 2017-02-20 05:33 That's moreso just a general limitation of the ability of Lazarus to debug DLL's in general... I'm not aware of any way you'd be able to do that. ---------------------------------------------------------------------- marcov · 2017-02-20 06:12 Quote from: Akira1364 on February 19, 2017, 04:25:38 amOdd... tried it on the latest "normal" release of Lazarus/FPC and got the same result as you. Not sure why it works fine in trunk but not there..... however, using Release FPC/Lazarus, I boiled it down to: it works when the form is included as an "LRS" in the initialization section (which no one should be doing anymore), but not when it is included as an "LFM" (as is the proper way nowadays) in the implementation section. Again, I don't know why this is, exactly. It appears to be an entirely arbitrary limitation, as there is really no reason this shouldn't work all the time (and especially, it's strange that it works with an outdated form file format, but not a current one.) Unsupported because it can't be guaranteed. Limited use can be metastable though, but strange things might happen at any rearrangement or version switch. ---------------------------------------------------------------------- Thaddy · 2017-02-20 06:14 Quote from: Akira1364 on February 20, 2017, 06:33:35 amThat's moreso just a general limitation of the ability of Lazarus to debug DLL's in general... I'm not aware of any way you'd be able to do that. Well, as long as the dll is compiled with debug info you will be able to debug the dll with a small host application and the debugger will happily step into the dll... Does so for years. Choose Run|Attach to program to select a host for the library. ---------------------------------------------------------------------- balazsszekely · 2017-02-20 06:26 First of all forms are officially supported in dynamic libraries since May 2016. Here is the relevant wiki page: http://wiki.freepascal.org/Form_in_DLL. Secondly even before the official support it was possible to embed forms inside a library, cross platform way. Take a look at the following example(download attachment Plugin.zip): http://forum.lazarus.freepascal.org/index.php/ topic,30252.msg192411.html#msg192411 Thirdly it is possible to debug the dll. ---------------------------------------------------------------------- Akira1364 · 2017-02-20 17:34 Quote from: Thaddy on February 20, 2017, 07:14:48 amWell, as long as the dll is compiled with debug info you will be able to debug the dll with a small host application and the debugger will happily step into the dll... Does so for years. Choose Run|Attach to program to select a host for the library. Oh I know that. Really I just meant I didn't think it would be able to step into form-specific methods when they're inside a DLL. (And after testing the OPs code again, it indeed segfaults when attempting to do so.) Quote from: GetMem on February 20, 2017, 07:26:34 amFirst of all forms are officially supported in dynamic libraries since May 2016. Here is the relevant wiki page: http://wiki.freepascal.org/Form_in_DLL. Secondly even before the official support it was possible to embed forms inside a library, cross platform way. Take a look at the following example(download attachment Plugin.zip): http://forum.lazaru s.freepascal.org/index.php/topic,30252.msg192411.html#msg192411 Thirdly it is possible to debug the dll. Well, I was just guessing that it still wasn't officially supported. Obviously I should have confirmed that first. As I said, I already knew it was possible, since I had successfully tried it in the past. I'm still curious to know why it works correctly with LRS files but not LFMs. (Interesting that the example you posted there uses neither but creates the form in code.) ---------------------------------------------------------------------- ExSystem · 2017-02-23 03:14 Quote from: Akira1364 on February 20, 2017, 06:34:49 pmQuote from: Thaddy on February 20, 2017, 07:14:48 amWell, as long as the dll is compiled with debug info you will be able to debug the dll with a small host application and the debugger will happily step into the dll... Does so for years. Choose Run|Attach to program to select a host for the library. Oh I know that. Really I just meant I didn't think it would be able to step into form-specific methods when they're inside a DLL. (And after testing the OPs code again, it indeed segfaults when attempting to do so.) Quote from: GetMem on February 20, 2017, 07:26:34 amFirst of all forms are officially supported in dynamic libraries since May 2016. Here is the relevant wiki page: http://wiki.freepascal.org/Form_in_DLL. Secondly even before the official support it was possible to embed forms inside a library, cross platform way. Take a look at the following example(download attachment Plugin.zip): http://forum.lazaru s.freepascal.org/index.php/topic,30252.msg192411.html#msg192411 Thirdly it is possible to debug the dll. Well, I was just guessing that it still wasn't officially supported. Obviously I should have confirmed that first. As I said, I already knew it was possible, since I had successfully tried it in the past. I'm still curious to know why it works correctly with LRS files but not LFMs. (Interesting that the example you posted there uses neither but creates the form in code.) AGREE!  segfaults on debugging DLL. So it's too hard to use DLL forms in practical situations. eg: Passing an object from EXE to DLL, and in DLL you consuming the object, your EXE may behave abnormal(hanging, displaying runtime error 219 with memory-leak checking, etc, ...), unless you built both DLL and EXE projects in RELEASE mode. My practical solution so far is: Wrap my DLL project source units into another normal EXE project to debug my DLL. And finally built the DLL project in RELEASE mode.