Re: [Lazarus] Strip debug info
Am 30.04.2012 07:30 schrieb Richard Mace rich...@shrinkyourbills.co.uk: On 30 April 2012 04:49, Alexander Klenin kle...@gmail.com wrote: While I am personally ambivalent about the default state of -Xg switch, I'd like to point out another use case where it matters: compiling on Windows on slow machine with antivirus installed. When I tried to persuade my students to switch to Lazarus from Delphi, I've got many complaints about Lazarus being too slow. About a third of these complaints were fixed by either excluding Lazarus directory from AV's monitoring list, or turning -Xg on. Sorry, I might have missed this, but what would be the main disadvantage for a newbie of having the -Xg switch on at default. I don't really understand about the difference between having the debug info internal to the .exe or external, and I am guessing that the majority of people coming to Lazarus won't either. I just think the more people will be complaining about the default size of the .exe as apposed to having the debug info stored externally, unless I am really missing the point (quite possibly). The main disadvantage is that -Xg is rather untested (especially considering the things that Martin wrote about the IDE) so in the end it might be less newb friendly than the debug info included in the executable (co.Audrey questions like why can't I debug anymore?). Also AFAIK FPC's lineinfo units (for both Stabs and Dwarf) don't work with external debug info (I don't remember exactly so this needs to be tested). Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Strip debug info
Alexander Klenin schrieb: While I am personally ambivalent about the default state of -Xg switch, I'd like to point out another use case where it matters: compiling on Windows on slow machine with antivirus installed. When I tried to persuade my students to switch to Lazarus from Delphi, I've got many complaints about Lazarus being too slow. About a third of these complaints were fixed by either excluding Lazarus directory from AV's monitoring list, or turning -Xg on. AV software tends to affect Delphi and its compiled projects, too. It's not a good idea to use AV software on a Windows development machine. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Strip debug info
On Mon, Apr 30, 2012 at 16:56, Hans-Peter Diettrich drdiettri...@aol.com wrote: AV software tends to affect Delphi and its compiled projects, too. Yes, but in recent years Delphi was included in safe lists of most AV products. It's not a good idea to use AV software on a Windows development machine. It is also not a good idea to use Windows on a development machine :) However, we live in imperfect world. -- Alexander S. Klenin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Strip debug info
On 04/29/2012 12:09 PM, Martin wrote: Then you have an outdated debug info file, The release build could just delete this file (provided it's there where a corresponding debug build would create it). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Strip debug info
On 04/30/2012 05:49 AM, Alexander Klenin wrote: When I tried to persuade my students to switch to Lazarus from Delphi, I've got many complaints about Lazarus being too slow. About a third of these complaints were fixed by either excluding Lazarus directory from AV's monitoring list, or turning -Xg on. Dud you not try to persuade them to use Linux (where Viruses are no big problem) . :-) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Object inspector hints ?
Hi, The lazarus code editor shows tooltip hints about identifiers; It gets those from the sources or even fpdoc. Is there any reason why the object inspector would not be able to offer the same hints ? Properties and events are also just identifiers after all. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Object inspector hints ?
On Mon, 30 Apr 2012 10:03:41 +0200 (CEST) Michael Van Canneyt mich...@freepascal.org wrote: Hi, The lazarus code editor shows tooltip hints about identifiers; It gets those from the sources or even fpdoc. Is there any reason why the object inspector would not be able to offer the same hints ? Properties and events are also just identifiers after all. Right click on OI: enable Show hints Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Object inspector hints ?
On Mon, 30 Apr 2012, Mattias Gaertner wrote: On Mon, 30 Apr 2012 10:03:41 +0200 (CEST) Michael Van Canneyt mich...@freepascal.org wrote: Hi, The lazarus code editor shows tooltip hints about identifiers; It gets those from the sources or even fpdoc. Is there any reason why the object inspector would not be able to offer the same hints ? Properties and events are also just identifiers after all. Right click on OI: enable Show hints Unbelievable... How many years this gem remained hidden from me. You can learn everything there is to know about lazarus in a week, and yet after many years, it can still surprise you. ( (c) Gandalf ) Thanks. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Object inspector hints ?
On 30/4/12 9:23, Mattias Gaertner wrote: On Mon, 30 Apr 2012 10:03:41 +0200 (CEST) Michael Van Canneytmich...@freepascal.org wrote: Hi, The lazarus code editor shows tooltip hints about identifiers; It gets those from the sources or even fpdoc. Is there any reason why the object inspector would not be able to offer the same hints ? Properties and events are also just identifiers after all. Right click on OI: enable Show hints There is also the (optional) OI information box which displays limited documentation. However, it is often very limited. e.g. TControl.OnClick Event Handler for mouse click which hardly aids a programmer looking for more information, and in fact is hardly worth displaying at all. Would it be difficult to add parameter and parameter type information, and function return type such as codetools offers in the Editor? Howard -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] build modes - I have an idea
On 30/04/12 02:02, Juha Manninen wrote: The GUI should indeed be more intuitive. It should indicate the build more setting is above all other settings, affecting them all. Build mode modifier/override is a good idea, too, but requires (maybe difficult) code changes. True, but they are very flexible: - They override the setting you need, and leave the other settings as per the default build mode - No need to change a common setting in several places (paths, target filename, checks, etc...) - You can mix build mode overrides, eg cross compilation and debug/release example (bmo=build mode override): - bmoLinux: Linux OS / GTK2 widgetset - bmoWin32: Win32 OS / Win32 widgetset - bmoWin64: Win64 OS / Win32 widgetset - bmoWinCE: WinCE OS / WinCE widgetset - bmoDebug: Debug mode - bmoRelease: release mode then - Build mode Linux/Debug: bmoLinux + bmoDebug - Build mode Linux/Release: bmoLinux + bmoRelease The IDE toolbar will have the usual build mode dropdown button or - Build mode Target type = (bmoLinux, bmoWin32, bmoWin64, bmoWinCE) - Build mode Usage type = (bmoDebug, bmoRelease) Since there are 2 build mode types defined, there will be 2 dropdown buttons in the IDE toolbar to select/combine the Target and Usage types. I don't see this implemented any time soon, but it is something to think about. Bernd's change is mostly about GUI. Indeed. Stephano -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Object inspector hints ?
On Mon, 30 Apr 2012 09:50:30 +0100 Howard Page-Clark h...@talktalk.net wrote: On 30/4/12 9:23, Mattias Gaertner wrote: On Mon, 30 Apr 2012 10:03:41 +0200 (CEST) Michael Van Canneytmich...@freepascal.org wrote: Hi, The lazarus code editor shows tooltip hints about identifiers; It gets those from the sources or even fpdoc. Is there any reason why the object inspector would not be able to offer the same hints ? Properties and events are also just identifiers after all. Right click on OI: enable Show hints There is also the (optional) OI information box which displays limited documentation. However, it is often very limited. e.g. TControl.OnClick Event Handler for mouse click which hardly aids a programmer looking for more information, and in fact is hardly worth displaying at all. Would it be difficult to add parameter and parameter type information, and function return type such as codetools offers in the Editor? The OI and the source editor show the same hint. Since 0.9.31 the hint shows some more fpdoc content. For example the description. Since yesterday it shows the type of redefined properties like OnClick. That means it shows property OnClick: TNotifyEvent. It's a todo to show related information like parameters of TNotifyEvent. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Object inspector hints ?
Howard Page-Clark schrieb: Right click on OI: enable Show hints There is also the (optional) OI information box which displays limited documentation. However, it is often very limited. e.g. TControl.OnClick Event Handler for mouse click which hardly aids a programmer looking for more information, and in fact is hardly worth displaying at all. Would it be difficult to add parameter and parameter type information, and function return type such as codetools offers in the Editor? What's the use of such additional information in OI? You can let the OI create the event handler for you, no need to bother with parameters here. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Inconsistent results from MessageDlg()
On 4/29/12, patspiper patspi...@gmail.com wrote: Someone with a recent Delphi (as in D3) tested this for me. Delphi XE? Yes, executable run under XP. Bart -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Object inspector hints ?
On 30/4/12 11:54, Hans-Peter Diettrich wrote: Howard Page-Clark schrieb: What's the use of such additional information in OI? You can let the OI create the event handler for you, no need to bother with parameters here. For people who use a stable release all the time, set up according to their established preferences, this is true. I prefer to work mainly with the cutting-edge. And working help for some reason is often the first casualty of a new installation. Since Lazarus does not yet install all help files on all platforms ready-to-run, I often find on upgrading or using a daily snapshot that help and hints have stopped working for me, and require quite a lot of downloads and file copying and setting of help parameters (as URLs, not usual directory locations) before the new help installation is rolling again. Unaccountably this process sometimes goes quickly and smoothly, and at other times takes far too long, and I have to refer to wiki articles and mail list archives to try to solve the problem. OTOH the OI already lists all published events nicely, without need to look up the sources. So it is quicker for me (if help is not yet working) to drop a component on a form, inspect some information in the OI as needed, and perhaps delete the component again if it is not actually needed. Obviously for classes that are not on the Component Palette this method is not applicable, but often it seems the quickest way to get to the information I need. Otherwise I quickly end up with loads of source files open in the Editor (which I prefer to avoid because it makes it harder to find the few files I am working on; and if ever I close a file, I nearly always seem to need it only a few moments later). Howard -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Removing read-only files in FileUtil.DeleteDirectory ?
On 4/29/12, Juha Manninen juha.mannine...@gmail.com wrote: Removing files in windows can fail also. The flag RemoveReadOnlyFiles actually means try to also remove read-only files (just like DeleteDirectory actually tries to delete a directory). As long as the function returns False if removing of a file/dir fails it should be OK. I would change the declaration to: function DeleteDirectory(const DirectoryName: string; OnlyChilds: boolean; const RemoveReadOnlyFiles: Boolean = False): boolean; But that is possibly just a matter of taste. One might also consider retuning the actual filename/foldername that could not be removed if things fail, so feedback to the user can be given. Bart -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Removing read-only files in FileUtil.DeleteDirectory ?
On 30/4/12 11:45, Bart wrote: On 4/29/12, Juha Manninenjuha.mannine...@gmail.com wrote: I would change the declaration to: function DeleteDirectory(const DirectoryName: string; OnlyChilds: boolean; const RemoveReadOnlyFiles: Boolean = False): boolean; If the suggestion is adopted it needs to be function DeleteDirectory(const DirectoryName: string; OnlyChildren: boolean; ... -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] RE : Removing read-only files in FileUtil.DeleteDirectory ?
Regarding issue #21855 http://bugs.freepascal.org/view.php?id=21855 I am planning to reject the patch but I would like to have other opinions, too. I'm in favor of patch with current definition (no default parameters as suggested by Bart) and with following ammendment: if RemoveReadOnlyFiles and ((FileInfo.Attr and faReadOnly)0) then if FileSetAttrUTF8(CurFilename, FileInfo.Attr-faReadOnly) 0 then exit; Instead of if RemoveReadOnlyFiles and ((FileInfo.Attr and faReadOnly)0) then FileSetAttrUTF8(CurFilename, FileInfo.Attr-faReadOnly); This way the function exits as soon as something goes wrong. No need iterating in directories when the attribute of the directory itself can't be changed. Ludo -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] RE : Removing read-only files in FileUtil.DeleteDirectory ?
On Mon, 30 Apr 2012 14:16:22 +0200 Ludo Brands ludo.bra...@free.fr wrote: Regarding issue #21855 http://bugs.freepascal.org/view.php?id=21855 I am planning to reject the patch but I would like to have other opinions, too. I'm in favor of patch with current definition (no default parameters as suggested by Bart) and with following ammendment: if RemoveReadOnlyFiles and ((FileInfo.Attr and faReadOnly)0) then if FileSetAttrUTF8(CurFilename, FileInfo.Attr-faReadOnly) 0 then exit; Instead of if RemoveReadOnlyFiles and ((FileInfo.Attr and faReadOnly)0) then FileSetAttrUTF8(CurFilename, FileInfo.Attr-faReadOnly); This way the function exits as soon as something goes wrong. No need iterating in directories when the attribute of the directory itself can't be changed. How to find out what went wrong? Maybe add parameter 'ExceptionOnError:boolean=false' and if true then raise an exception with the file name. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] RE : RE : Removing read-only files in FileUtil.DeleteDirectory ?
How to find out what went wrong? Maybe add parameter 'ExceptionOnError:boolean=false' and if true then raise an exception with the file name. Good idea. I just kept it along the lines of the existing DeleteDirectory that just failed without raising a exception. Ludo -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Object inspector hints ?
On 30 April 2012 09:23, Mattias Gaertner nc-gaert...@netcologne.de wrote: On Mon, 30 Apr 2012 10:03:41 +0200 (CEST) Michael Van Canneyt mich...@freepascal.org wrote: Hi, The lazarus code editor shows tooltip hints about identifiers; It gets those from the sources or even fpdoc. Is there any reason why the object inspector would not be able to offer the same hints ? Properties and events are also just identifiers after all. Right click on OI: enable Show hints When I do this, I don't get a menu? I think I am being stupid, could someone elberate? Thanks Richard -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] build modes - I have an idea
On Mon, Apr 30, 2012 at 12:13 PM, patspiper patspi...@gmail.com wrote: True, but they are very flexible: - They override the setting you need, and leave the other settings as per the default build mode - No need to change a common setting in several places (paths, target filename, checks, etc...) - You can mix build mode overrides, eg cross compilation and debug/release I understand your idea but I would like to see an intuitive GUI for it. It requires many other changes, too. Now that Lazarus 1.0 branch has been forked, trunk is open for new experimental features. Patches are welcome. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] build modes - I have an idea
On 30/04/12 17:45, Juha Manninen wrote: On Mon, Apr 30, 2012 at 12:13 PM, patspiper patspi...@gmail.com mailto:patspi...@gmail.com wrote: True, but they are very flexible: - They override the setting you need, and leave the other settings as per the default build mode - No need to change a common setting in several places (paths, target filename, checks, etc...) - You can mix build mode overrides, eg cross compilation and debug/release I understand your idea but I would like to see an intuitive GUI for it. Your previous email was a reply to Bernd's, so I thought you were referring to his changes. I have to think about the GUI, and will post some ideas for brain storming in a later email. Stephano -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Removing read-only files in FileUtil.DeleteDirectory ?
Bart schrieb: I would change the declaration to: function DeleteDirectory(const DirectoryName: string; OnlyChilds: boolean; const RemoveReadOnlyFiles: Boolean = False): boolean; Yes, I think this needs to be changed/added . And what about system-hidden files? Are they already deleted by DeleteDirectory? In general, there was a reason for having read-only attributes in the past but meanwhile it is of not much use anymore because many programs delete such files anyway (as this thread shows ;-)). One might also consider retuning the actual filename/foldername that could not be removed if things fail, so feedback to the user can be given. This would only make sense if a programmer wants to present the file name to a user. But if the only reason is to know which file attributes have to be changed and let the program try to delete them again, then the programmer should be saved to do such crude cycles and a flag should tell the routine to delete in all cases (read-only or not). -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Overloading with generic type as parmeter causes compiler error.
Hi All! I am working on a generic type library and ran into a problem at compile time. type generic TMyTypeT = class * * * function IndexOf( Item : T ) : Integer; overload; functionIndexOf( aName : String) : Integer; overload; // generics1.pas Error: Function is already declared Public\Forward TMyType.IndexOf(AnsiString):LongInt; // or, reverse the declarations: function IndexOf( aName : String ) : Integer; overload; function IndexOf( Item : T ) : Integer; overload; // generics1.pas Error: Function is already declared Public\Forward TMyType.IndexOf(undefined type):LongInt; end; Similar errors occur in implementation of the overloaded subprograms, as in: // generics1.pas Error: function header IndexOf doesn't match forward : var name changes aName = Item The obvious work-around is to avoid overloading with generic types as parameters, but that is really a hack in this case. Keep up the GREAT work, Don Z. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Strip debug info
On Monday, April 30, 2012 09:37 Michael Schnell wrote: On 04/29/2012 12:09 PM, Martin wrote: Then you have an outdated debug info file, The release build could just delete this file (provided it's there where a corresponding debug build would create it). -Michael Please don't oversimplify a release build. At least one other difference is smart linking. You shouldn't smart link for debug purposes, but it would be a good idea to smart link for release. Also optimizations should be turned of for debug while they should (or at least could) be enabled for release. It helps to have several checks (overflow, range, etc.) on during debug too, but not for release. It is (or should) not simply (be) a matter of debug info. In that light I find the big exe even good as it gets users to find out why and think about debug/release builds. If they simply ship a debug exe (without actual debug info) they might still find bad things like slow performance etc, which might be caused by enabled checks and/or missing optimizations. I think you have to understand the full package to properly build release ready software. And a far too huge size might be the best indicator that something isn't right yet :-) -- Best Regards, Andreas pgpHENAoV3vac.pgp Description: PGP signature -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Strip debug info
Well, the problem is the size of the exe file. ;-) When I am working on a project I usually want to generate debug information for debugging. But when I give the generated file to someone else I surely do not need this information in the exe file anymore. So why should I be forced to search for ways to delete this information from the exe if there could be a way to avoid this hassle? There is no need to search for ways to delete this information, you need only a proper workflow: exes compiled for distribution shall be compiled with release settings which means: - no debug info - symbols fully stripped - full optimization (which would make debugging harder) - asserts ignored - custom debug code ignored - ... Using debug and release settings is something very basic when working on software being deployed to others. This is interesting, I'd had never actually thought of a work flow like this. So, would you have 2x different projects? 1 with as dubug and the 2nd as release, or is there a better way of doing it? Richard -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Return of Frame3D issue
In upgrading to Lazarus 1.1 and issue I first came across in this thread
has returned. I think I decided not to use the controls in 0.9.31 but I
want to consider them again in Lazarus 1.1,
http://lists.lazarus.freepascal.org/pipermail/lazarus/2011-August/065582.html
.
There is also a mantis issue for it -
http://bugs.freepascal.org/view.php?id=8328.
In 0.9.30 it is defined in lclintf.h as
function Frame3d(DC: HDC; var ARect: TRect; const FrameWidth : integer;
const Style : TGraphicsBevelCut): Boolean; {$IFDEF
IF_BASE_MEMBER}virtual;{$ENDIF} and is also in the Graphics unit as
procedure Frame3d(var ARect: TRect; const FrameWidth: integer; const Style:
TGraphicsBevelCut); virtual;
The control I am working with, TJanPanelButton uses the signature in
lclintfh.inc calling it as Frame3d( Self.Canvas.Handle, R, FFrameWidth,
bvRaised );
Juha Mahinnen added a patch to Extctrls to match the Delphi implementation
here - http://docwiki.embarcadero.com/Libraries/en/Vcl.ExtCtrls.Frame3D.
Although it matches the Delphi definition is it in the wrong place as it
affects the apparently original Lazarus implementation?
In the mean time I have to ifdef it and call Self.Canvas.Frame3D(R,
FFrameWidth, bvRaised ) instead of Frame3d( Self.Canvas.Handle, R,
FFrameWidth, bvRaised ) which matches the definition of TCanvas in
Graphics. Is that any good?
;
--
Frank Church
===
http://devblog.brahmancreations.com
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Form in DLL
Hello,
in http://bugs.freepascal.org/view.php?id=1866 is described, that forms
in dlls are not working at this moment. I have coded a dll which opens a
form and it works. But I am not sure if there are some hidden problems
or side-effects. Before I implement this in a real application, I want
to read some opinions.
Here is the code for the DLL:
88888888
library server;
{$mode objfpc}
{$H+}
{$DEFINE USE_BIN_STR}
uses
Classes, SysUtils, Interfaces, Windows, LCLType, Unit1, Forms;
{$R *.res}
procedure ShowText(AText: String); stdcall;
begin
try
Form1 := TForm1.Create(Application);
Form1.Memo1.Text := AText;
Form1.ShowModal;
finally
FreeAndNil(Form1);
end;
end;
exports
ShowText;
begin
Application.Initialize;
end.
88888888
The Unit1 contains a form with a TMemo on it. I can show the form and
load some text into it via:
88888888
procedure DllShowText(AText: String); stdcall; external 'server.dll'
name 'ShowText';
// ...
DllShowText('Blafasel');
88888888
Is this a bad idea?
Thanks for any help.
Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Strip debug info
2012/4/30 Richard Mace rich...@shrinkyourbills.co.uk: This is interesting, I'd had never actually thought of a work flow like this. So, would you have 2x different projects? 1 with as dubug and the 2nd as release, or is there a better way of doing it? There are build modes. There is a page in the project options dialog where you can set up different build modes and each can have different settings. There is also a toolbar button in the IDE main window to change the currently active build mode. The UI to configure the build modes is not yet as intuitive as it could ideally be but it works. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Form in DLL
2012/4/30 Michael Fuchs freepas...@ypa-software.de: Hello, in http://bugs.freepascal.org/view.php?id=1866 is described, that forms in dlls are not working at this moment. I have coded a dll which opens a form and it works. But I am not sure if there are some hidden problems or side-effects. I have once also experimented with this but the host application was *not* written with FPC/LCL (it was a proprietary trading and charting software (MetaTrader4) that had a built in scripting language with rudimentary support for importing dll functions that would load my dll and call functions). The problem was that all these function calls into my dll did not originate from the main GUI thread, of the host application. I was able to show a form but it was frozen, it did not receive any events. I ended up starting a separate thread in my dll, told the RTL that this new thread is now the main thread (and was surprised that this actually worked) and then wrote my own message loop (because application.run did not seem to work properly). I also had to synchronize all other function calls from the host with this thread because they came from even more different threads, At the end it worked but it all looked so ridiculously complicated and fragile and I had the impression it was sheer coincidence that it actually worked so that I finally decided to abandon these experiments and instead make the gui part of my dll a separate .exe file that communicates via some sort of IPC (I ended up starting the GUI exe with a TProcess and send/receive simple commands via stdin/stdout). This still seemed somehow complicated but at least it did no dirty undocumented tricks with the LCL and seemed quite robust (and enough for my needs). Bernd -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Form in DLL
This is almost exactly the way I wrote plugin architecture for my apps. The difference is that the dll function call (which opens a form) is blocked within Application.Initialize and Application.Terminate, so the dll function (and the form) lifetime is only along the executed function. The only currently missing feature (that I need) using this approach is that if the dll contains form that must be shown as modal, I can't pass my main form's instance to make it modal (the dll form is still non-modal). -- View this message in context: http://free-pascal-lazarus.989080.n3.nabble.com/Lazarus-Form-in-DLL-tp3952007p3952303.html Sent from the Free Pascal - Lazarus mailing list archive at Nabble.com. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
