Recent

Author Topic: Compiling a .dll  (Read 68503 times)

CWBudde

  • New Member
  • *
  • Posts: 24
    • http://www.savioursofsoul.de/Christian
Re: Update on using LCL in DLL
« Reply #30 on: August 07, 2006, 05:47:40 pm »
Quote from: "Phil"
See this bug report for sample code illustrating the problems using an LCL form in a DLL:

  http://www.freepascal.org/mantis/view.php?id=7181

I tried to fix the bug by myself an and soon got a clue about what might went wrong here. I need to make some changes to the customforms.inc to be sure, but unfortunately no change will compile. What do I need to include? To compile this file together with the test program.
I already tried to add the whole LCL directory to the compile path, but I got lots of errors, so there must be another way.

Christian

Vincent Snijders

  • Administrator
  • Hero Member
  • *
  • Posts: 2661
    • My Lazarus wiki user page
RE: Re: Update on using LCL in DLL
« Reply #31 on: August 07, 2006, 10:17:27 pm »
Revert all the changes you made to setting and make sure all files from previous compile attempts are removed. If you want to test the LCL, you need to compile the complete LCL. Use the Build Lazarus menu option, see wiki for details.

duncanparsons

  • Jr. Member
  • **
  • Posts: 83
RE: Re: Update on using LCL in DLL
« Reply #32 on: September 01, 2008, 03:03:36 pm »
I'm having another look at this, so thought I'd give it a bump to see if anyone had any further ideas in the last 2 years :)

I'm looking at perhaps using a callback system where the dll and application know about each other, and the app iterates it's list of 'child applications' telling them to process their messages.. it may help with getting forms communicating but wouldn't solve any more subtle LCL errors in sharing memory, etc. I'm envisioning a C-style thing, rather than something akin to packages - but even then I'm not totally sure it would work; and it would mean implementing changes at the widgetset level.

Any ideas before I start?

DSP

ZL

  • New Member
  • *
  • Posts: 16
Re: Compiling a .dll
« Reply #33 on: December 25, 2008, 01:02:07 pm »
duncanparsons, how is your work with this issue going? Any progress?
I'm interested in this issue for coulpe of years too, but didn't post anything because I know I won't be able to contribute to solving it...

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Compiling a .dll
« Reply #34 on: December 25, 2008, 07:06:12 pm »
I've had quite a bit of luck with forms in libraries on OS X/Carbon, but not with Lazarus win32. These same libraries compile and run fine with Delphi, as do non-form DLL's compiled with FPC, so this suggests something wrong in the win32 widgetset.

Here are some of the things I've successfully tested:

- 50,000 line library with multiple forms compiled with Laz 0.9.26/FPC 2.2.2 called from C++/Qt app on Mac. Works identically to its standalone counterpart.

- Same code compiled into a library with Delphi can be called modally or non-modally (the forms, that is) from same C++/Qt app on Windows or even from a .NET app. When compiled with Laz 0.9.26/FPC 2.2.2, Windows is not able even to load the DLL.

Since I have Delphi, I don't need Lazarus on Windows, but it would be great for this to work too. Odd to see Carbon ahead of Windows in this regard.

Thanks.

-Phil

ZL

  • New Member
  • *
  • Posts: 16
Re: Compiling a .dll
« Reply #35 on: December 27, 2008, 01:26:12 am »
Phil, thanks for info. But can you load Laz compiled library with Laz compiled executable in Mac (both containint forms)?

If I actually can load library with forms in Mac (so maybe in Linux too?) and if I will be able to load from Laz compiled exe a Delphi dll with forms in Windows it could be at least some kind of solution.
I think I'll try to test it in next month (I hope).

But yes, it would be nice to have Lazarus-only solution :)

Phil

  • Hero Member
  • *****
  • Posts: 2737
Re: Compiling a .dll
« Reply #36 on: December 27, 2008, 01:55:35 am »
Yes, that works too. You can load the library either by declaring it external or by manually loading and working with the library using LoadLibrary, GetProcAddress and FreeLibrary in the DynLibs unit. For former is simpler to get started with but, as you probably know, you have to put the .dll somewhere that Windows can find it. Doing everything yourself provides more flexibility and allows you to put the library anywhere that your code can find it. This also allows you to handle missing libraries more gracefully - on Windows, it just puts up an error message and quits.

Don't know anything about Linux but I would imagine it's more of a GTK/GTK2 widgetset question than it is a Linux question.

On Windows, if you need to display your Delphi form non-modally (via Show instead of ShowModal) there are issues with some keystrokes not getting sent through to the form (tabbing doesn't work, for example), but there are workarounds by passing the keystrokes through from the host app. If you're using ShowModal, that works fine - apparently a different mechanism is used to detect keystrokes.

Thanks.

-Phil

PeterX

  • Sr. Member
  • ****
  • Posts: 404
Re: Compiling a .dll
« Reply #37 on: December 12, 2017, 12:51:36 pm »
Just to keep things together .. for people seaching on 'VST Plugins'

http://wiki.freepascal.org/Form_in_DLL
usually using latest Lazarus release version with Windows 10

Thaddy

  • Hero Member
  • *****
  • Posts: 14161
  • Probably until I exterminate Putin.
Re: Update on using LCL in DLL
« Reply #38 on: December 12, 2017, 01:29:43 pm »
Quote from: Phil
See this bug report for sample code illustrating the problems using an LCL form in a DLL:

  http://www.freepascal.org/mantis/view.php?id=7181
I tried to fix the bug by myself an and soon got a clue about what might went wrong here. I need to make some changes to the customforms.inc to be sure, but unfortunately no change will compile. What do I need to include? To compile this file together with the test program.
I already tried to add the whole LCL directory to the compile path, but I got lots of errors, so there must be another way.

Christian
You are looking too deep... It is just a matter of alignment which should be 16 in both application and vst.
There is a simple repaint problem that can be solved by, Ahum, Application.ProcessMessages. And make sure the correct handle is in place (The client handle, not the VST), but you know that.

(As an aside: you still did not give me the credits for the reverb -freeverb - translation  O:-) You claim that's your code. It isn't.  I released it as do what you want, but to claim you wrote it it gross. You may have improved on it but I can not see where?
Even my original comments are still in...
The true story is that I wrote the initial VST host code and TobyBear and you improved on it. Fair enough, good job. :D. And the VST basics were layed down by Frederic VanMol )

I am not grumpy, but some original credits should be in place. They aren't.
[edit]
I missed the date, which is 12 years ago. Remark still stands.... (As I remarked 12 years ago....)
« Last Edit: December 12, 2017, 04:35:35 pm by Thaddy »
Specialize a type, not a var.

PeterX

  • Sr. Member
  • ****
  • Posts: 404
Re: Update on using LCL in DLL
« Reply #39 on: December 12, 2017, 01:39:49 pm »
There is a simple repaint problem that can be solved by, Ahum, Application.ProcessMessages. And make sure the correct handle is in place (The client handle, not the VST),
I am still not this far.

My plugin compiles and replays the MIDI notes it receives.
But the plugin does not paint ..

http://forum.lazarus.freepascal.org/index.php/topic,39210.msg268729.html#msg268729
« Last Edit: December 12, 2017, 01:43:03 pm by PeterX »
usually using latest Lazarus release version with Windows 10

Thaddy

  • Hero Member
  • *****
  • Posts: 14161
  • Probably until I exterminate Putin.
Re: Update on using LCL in DLL
« Reply #40 on: December 12, 2017, 01:43:19 pm »
But the plugin does not paint ..
It is a matter of the VST getting the right handle from the main program and an extra processmessages.
I have a small function that sets it in the VST if you want. But it is easy. Do it at load time.
« Last Edit: December 12, 2017, 01:45:17 pm by Thaddy »
Specialize a type, not a var.

PeterX

  • Sr. Member
  • ****
  • Posts: 404
Re: Update on using LCL in DLL
« Reply #41 on: December 23, 2017, 12:38:21 am »
But the plugin does not paint ..
It is a matter of the VST getting the right handle from the main program and an extra processmessages.
I have a small function that sets it in the VST if you want. But it is easy. Do it at load time.

To the DLL library file (*.lpr / *.dpr) I added today ..

Code: Pascal  [Select][+][-]
  1. begin
  2.   {$IFDEF FPC}Application.Initialize;{$ENDIF}
  3. end.
  4.  

and now the surface of the VST plugin appears !
(.. after moving the plugin form once ..)
usually using latest Lazarus release version with Windows 10

Thaddy

  • Hero Member
  • *****
  • Posts: 14161
  • Probably until I exterminate Putin.
Re: Compiling a .dll
« Reply #42 on: December 23, 2017, 07:56:39 am »
Oh, yes, forgot to mention that. There were a few things more that I do in that function, like masking all floating point exceptions. (Necessary for ms C(++) compiled hosts, do not forget that...)
I also initialize tables there, for LUT's. I think my function example is somewhere on musicdsp. You may also want to examine Christian Budde's examples, these are also for FreePascal AFAIK.
Specialize a type, not a var.

PeterX

  • Sr. Member
  • ****
  • Posts: 404
Re: Compiling a .dll
« Reply #43 on: December 23, 2017, 12:05:30 pm »
Oh, yes, forgot to mention that.
Oh .. and it took me two weeks now to track down the exception that (now I know ..) occurs on
Code: Pascal  [Select][+][-]
  1.  GUI := TVSTEditorForm.Create(nil);

This ...
Code: Pascal  [Select][+][-]
  1.   {$IFDEF FPC}Application.Initialize;{$ENDIF}
didn't make sense to me in the DLL code, I just played around and compared with code from Form_in_DLL


There were a few things more that I do in that function, like masking all floating point exceptions. (Necessary for ms C(++) compiled hosts, do not forget that...)
I didn't know about that. Maybe it is already done in the example code from VSTPluginwizard1.0 or Delphi ASIO & VST Packages 1.3


You may also want to examine Christian Budde's examples, these are also for FreePascal AFAIK.
The Delphi ASIO & VST Packages 1.3 had no working Lazarus compatible code .. :-(

But I made TestPlugin.dpr  from VSTPluginwizard1.0 compile and run now.
« Last Edit: December 23, 2017, 12:18:13 pm by PeterX »
usually using latest Lazarus release version with Windows 10

Thaddy

  • Hero Member
  • *****
  • Posts: 14161
  • Probably until I exterminate Putin.
Re: Compiling a .dll
« Reply #44 on: December 23, 2017, 12:41:43 pm »
The ASIO unit most definitely works (at least my original version that pre-dates most others) but only in WIN32.
Specialize a type, not a var.

 

TinyPortal © 2005-2018