Re: [Lazarus] [ISSUE] Nice bug in TIPropertyGrid
On 17/03/2014 03:35, silvioprog wrote: Hello, Please see in: http://bugs.freepascal.org/view.php?id=25872 Thank you! As you're asking for extra attention (over people who just submit a bug to the bug tracker without mailing the list) I do hope you either include a patch/fix with the report or it is a high priority problem ;) -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Console app
On 03/15/2014 08:10 AM, Richard Mace wrote: Hi All, I have never written a console app and was wondering 2 things. Firstly, if I was to write an app that doesn't require a GUI, that runs on both Windows and Linux (with no XServer) is that classed as a console app? And secondly, is it fairly straight forward to write a console app that stores and retrieves data from a Firebird database, on the basis that I want to be able to use either the standard Lazarus components (or Zeos) to talk to the database? A problem might be that there (right now) is no Widget Type in Lazarus, that has no GUI binding and allows for using stuff like TTimer, TThread.Synchronize, TThread.Queue and QueuAsyncCall(). In fact I am planning to do such a Widget Type, but unfortunately I currently am busy with unrelated things. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/16/2014 02:47 AM, Marcos Douglas wrote: Like all Windows programmer, I use PostMessage/SendMessage a lot. Lazarus team has created Application.QueueAsyncCall method to substitute the (old) Windowish method todo async calls aka PostMessage. Ok. But what is the best way to use QueueAsyncCall when the caller to not knows what type is the receiver? As QueueAsyncCall does not exist in Delphi you might want to avoid it to stay Delphi compatible. So you can use TThread.Queue that is available both in Delphi (even though undocumented in some older versions) and in Lazarus/fpc (even though only in the not too old versions). QueueAsyncCall need to know the instance and the method to call... QueueAsyncCall is given the procedure to call and a parameter for same, but no instance. TThread.Queue only gets the (parameter-less) procedure to call. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/16/2014 09:23 AM, zeljko wrote: Why you must substitute PostMessage ? This is a Windowish left-over and really alien regarding the OS-independent making of the LCL (even though In fact the LCL even simulates PostMessage in Linux. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 10:56 AM, Michael Schnell wrote: On 03/16/2014 02:47 AM, Marcos Douglas wrote: Like all Windows programmer, I use PostMessage/SendMessage a lot. Lazarus team has created Application.QueueAsyncCall method to substitute the (old) Windowish method todo async calls aka PostMessage. Ok. But what is the best way to use QueueAsyncCall when the caller to not knows what type is the receiver? As QueueAsyncCall does not exist in Delphi you might want to avoid it to stay Delphi compatible. I don't care about Delphi compatibility in any case (in my applications).I'm using Lazarus and don't have any plan to use any commercial developer tool in the future. :) So you can use TThread.Queue that is available both in Delphi (even though undocumented in some older versions) and in Lazarus/fpc (even though only in the not too old versions). No, I'll keep using QueueAsyncCall as it is because it satisfies my needs. zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Console app
On 3/17/14, Michael Schnell mschn...@lumino.de wrote: A problem might be that there (right now) is no Widget Type in Lazarus, that has no GUI binding and allows for using stuff like TTimer, TThread.Synchronize, TThread.Queue and QueuAsyncCall(). The NoGUI WS doesn't allow this? Bart -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [ISSUE] Nice bug in TIPropertyGrid
On 3/17/14, Reinier Olislagers reinierolislag...@gmail.com wrote: ...or it is a high priority problem ;) Well, crashing the IDE should have a rather hight priority IMO ;-) Bart -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Console app
On 03/17/2014 11:04 AM, Bart wrote: The NoGUI WS doesn't allow this? No. It does not provide an Event Queue for the main thread. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Console app
On Mon, 17 Mar 2014 11:04:07 +0100 Bart bartjun...@gmail.com wrote: On 3/17/14, Michael Schnell mschn...@lumino.de wrote: A problem might be that there (right now) is no Widget Type in Lazarus, that has no GUI binding and allows for using stuff like TTimer, TThread.Synchronize, TThread.Queue and QueuAsyncCall(). The NoGUI WS doesn't allow this? The NoGUI has not implemented it. Feel free to add it. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [ISSUE] Nice bug in TIPropertyGrid
On 17/03/2014 11:05, Bart wrote: On 3/17/14, Reinier Olislagers reinierolislag...@gmail.com wrote: ...or it is a high priority problem ;) Well, crashing the IDE should have a rather hight priority IMO ;-) Yes. I read the bug report after posting... would have been even better if Silvio had included a short description or the word crash... That said, I suspect the bug is getting the attention it needs.. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Console app
On 03/17/2014 11:14 AM, Mattias Gaertner wrote: Feel free to add it. It's not as impossible as I initially thought, as the fpc RTL already provides the basic Queue implantation that can be used (while all other active Widget Types use a queue provided by the GUI infrastructure they attach to). Doing TTimer needs some afterthoughts: there are multiple ways, each with some pro's and cons: e.g. - simply using the timeout parameter of the RTL queue poll procedure, - doing one or several dedicated threads with sleep() for handling the timers, feeding timer events into the queue - ... -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 11:03 AM, zeljko wrote: No, I'll keep using QueueAsyncCall as it is because it satisfies my needs. I am with you, as QueueAsyncCall additionally provides queuing a parameter for the procedure to be called in the main thread. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 6:56 AM, Michael Schnell mschn...@lumino.de wrote: On 03/16/2014 02:47 AM, Marcos Douglas wrote: Like all Windows programmer, I use PostMessage/SendMessage a lot. Lazarus team has created Application.QueueAsyncCall method to substitute the (old) Windowish method todo async calls aka PostMessage. Ok. But what is the best way to use QueueAsyncCall when the caller to not knows what type is the receiver? As QueueAsyncCall does not exist in Delphi you might want to avoid it to stay Delphi compatible. I don't care about Delphi compatibility. Today I only use FPC/Lazarus. So you can use TThread.Queue that is available both in Delphi (even though undocumented in some older versions) and in Lazarus/fpc (even though only in the not too old versions). QueueAsyncCall need to know the instance and the method to call... QueueAsyncCall is given the procedure to call and a parameter for same, but no instance. TThread.Queue only gets the (parameter-less) procedure to call. Yes, but the QueueAsyncCall needs to know what procedure to call for a especific object (instance). Of course you can simulate not to know which instance calling this procedure and the implementation will instanciate the especific class... adding complexity IMHO. Using PostMessage you can send a broadcast. Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] How to bundle HTML help to package?
Hello, I'd like to ask how to bundle offline HTML help to *.lpk package, to make key [F1] work. I've created some units as a part of project and documentation (using FPDoc). I created package, copied units and xml documentation there. I renamed xml headers (package name) and created html using console: $ fpdoc --format=html . I set the path in Package dialog - Options - IDE Integration - FPDoc settings / Search path to docs. Directory structure is: $(PkgOutDir) ... pas, inc, lpk, lrs files $(PkgOutDir)/docs ... xml files $(PkgOutDir)/docs/html ... html files When I start a new project and I place component from my package there (project must be saved): - when I hover identifier, Lazarus displays correct hint with desription, OK - when I open FPDoc editor, it works too, when I place carret in Source Editor on identifier, OK - when I press F1, Lazarus shows dialog: No help found for line 36, column 35 of /media/disk/v1/Projects/Test/packagehelp/unit1.pas When I try to press F1 for other identifiers, it works. Example: TForm opens default web browser with online help: http://lazarus-ccr.sourceforge.net/docs/lcl/forms/tform.html What should I do? Thanks. Vojtěch aka Blaazen -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 01:31 PM, Marcos Douglas wrote: Yes, but the QueueAsyncCall needs to know what procedure to call for a especific object (instance) I don't understand. The definition of the function (I use) is procedure TApplication.QueueAsyncCall(const AMethod: TDataEvent; Data: PtrInt); with TDataEvent = procedure (Data: PtrInt) of object; I don't see an instance here. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 11:11 AM, Michael Schnell mschn...@lumino.de wrote: On 03/17/2014 01:31 PM, Marcos Douglas wrote: Yes, but the QueueAsyncCall needs to know what procedure to call for a especific object (instance) I don't understand. The definition of the function (I use) is procedure TApplication.QueueAsyncCall(const AMethod: TDataEvent; Data: PtrInt); with TDataEvent = procedure (Data: PtrInt) of object; I don't see an instance here. CASE 1: You have MainForm (Main) and ProcessForm (Proc). Proc do not know Main but Main needs to be updated about what happen in Proc so, Proc can use QueueAsyncCall that need a TDataEvent procedure as argument. If Proc not know Main, how he know the procedure (TDataEvent) to pass on argument? Sugestion: I can Create Proc passing the procedure (TDataEvent) to call inside Proc. CASE 2: You have MainForm (Main), InfoForm (that have 2 Frames F1 and F2 that not know InfoForm) and ProcessForm (Proc). Proc do not know Main, InfoForm or frames but they needs to be updated about what happen in Proc so, Proc can use QueueAsyncCall that need a TDataEvent procedure as argument. If Proc not know about these Handlers, how he know the procedure (TDataEvent) to pass on argument? -- I think that I need is too much for a simple call to QueueAsyncCall. I'm doing tests with FP Observer implementation too. Best regards, Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Console app
I have never written a console app and was wondering 2 things. Firstly, if I was to write an app that doesn't require a GUI, that runs on both Windows and Linux (with no XServer) is that classed as a console app? And secondly, is it fairly straight forward to write a console app that stores and retrieves data from a Firebird database, on the basis that I want to be able to use either the standard Lazarus components (or Zeos) to talk to the database? A problem might be that there (right now) is no Widget Type in Lazarus, that has no GUI binding and allows for using stuff like TTimer, TThread.Synchronize, TThread.Queue and QueuAsyncCall(). Ah, yes. That would be ab issues as using a TTimer would be essential for what I am planning :( Richard -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 03:36 PM, Marcos Douglas wrote: The pointer to the Event Procedure, the self pointer of it's instance (both denoted by AMethod) and the pointer to the parameter to have it called with (denoted byData are queued and when the main thread is ready to handle the event, it calls AMethod appropriately. If you meant the self pointer of AMethod, I of course am with you (as same is a procedure of object). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 04:09 PM, Michael Schnell wrote: If you meant the self pointer of AMethod, I of course am with you (as same is a procedure of object). But that is rather trivial, and AMethod could be a procedure of any class (inducing but not forcing the TThread instance that schedules the call. I think that I need is too much for a simple call to QueueAsyncCall. I'm doing tests with FP Observer implementation too. A nice trick is to create an instance of a data holding object, fill it and provide it as Data with QueueAsyncCall. In the call you can free the data holding object. Another trick that also works with TThread.Queue is to provide the data holding class with a procedure, create and fill same and provide the procedure (including instance) with TThread.Queue. Here you need to take more care with freeing the object. I'm not sure if you simply can do free; as the last instruction before returning from the procedure. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 04:20 PM, Michael Schnell wrote: I'm not sure if you simply can do free; as the last instruction before returning from the procedure. I just did a test and even this seems to work: An object seemingly can free itself and return to the caller of the function just as if this function would be another destructor. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 12:20 PM, Michael Schnell mschn...@lumino.de wrote: On 03/17/2014 04:09 PM, Michael Schnell wrote: If you meant the self pointer of AMethod, I of course am with you (as same is a procedure of object). But that is rather trivial, and AMethod could be a procedure of any class (inducing but not forcing the TThread instance that schedules the call. I think that I need is too much for a simple call to QueueAsyncCall. I'm doing tests with FP Observer implementation too. A nice trick is to create an instance of a data holding object, fill it and provide it as Data with QueueAsyncCall. In the call you can free the data holding object. I do that today using PostMessage. IMHO the problem in QueueAsyncCall, comparing with PostMessage, it is needs to know what procedure (method of an instance) to call to use on queue meanwhile PostMessage function just put a message on queue. The object that is listening for messages knows what procedure/method to execute itself. Another trick that also works with TThread.Queue is to provide the data holding class with a procedure, create and fill same and provide the procedure (including instance) with TThread.Queue. Here you need to take more care with freeing the object. I'm not sure if you simply can do free; as the last instruction before returning from the procedure. I do not have problems using Threads but I don't use TThread.Queue. I just use TThread.Synchronize and this is works for me. I know TThread.Queue is new, but I never used... maybe you can explain me what advantages, please. Regards, Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 1:35 PM, Michael Schnell mschn...@lumino.de wrote: On 03/17/2014 04:20 PM, Michael Schnell wrote: I'm not sure if you simply can do free; as the last instruction before returning from the procedure. I just did a test and even this seems to work: An object seemingly can free itself and return to the caller of the function just as if this function would be another destructor. Could you send the sources of this test? Thanks, Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] debugging parts of rtl from within lazarus
Marc Santhoff wrote: Hi, the FAQ gives instructions for debugging FCL from within lazarus. http://wiki.lazarus.freepascal.org/Lazarus_Faq#How_can_I_debug_FCL_components_from_packages_with_Lazarus Does this work for RTL packages as well? I need to set breakpoints inside serial.pp to see what data SerRead and SerWrite really get. I'm fairly sure that I used Lazarus to set breakpoints in that unit, but when I was working on it I'd have been using a copy in my project's working directory. The patch at http://mantis.freepascal.org/view.php?id=18946 contains a test program that you might find useful, it's quirky but I used it heavily when testing the unit for Linux/Solaris/Windows. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 05:42 PM, Marcos Douglas wrote: Could you send the sources of this test? I could if you are interested. This is a testing project I did for the development of Widget Types (with and without GUI Binding) on behalf of TThread.Synchronize, TThread.Queue, Application.QueueAsyncCall, and PostMessage. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] debugging parts of rtl from within lazarus
Hi, the FAQ gives instructions for debugging FCL from within lazarus. http://wiki.lazarus.freepascal.org/Lazarus_Faq#How_can_I_debug_FCL_components_from_packages_with_Lazarus Does this work for RTL packages as well? I need to set breakpoints inside serial.pp to see what data SerRead and SerWrite really get. TIA, Marc -- Marc Santhoff m.santh...@web.de -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 2:25 PM, Michael Schnell mschn...@lumino.de wrote: On 03/17/2014 05:42 PM, Marcos Douglas wrote: Could you send the sources of this test? I could if you are interested. This is a testing project I did for the development of Widget Types (with and without GUI Binding) on behalf of TThread.Synchronize, TThread.Queue, Application.QueueAsyncCall, and PostMessage. I'm interested. Could you send for my mail, please? Thank you. Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] debugging parts of rtl from within lazarus
On 17/03/2014 16:40, Marc Santhoff wrote: the FAQ gives instructions for debugging FCL from within lazarus. http://wiki.lazarus.freepascal.org/Lazarus_Faq#How_can_I_debug_FCL_components_from_packages_with_Lazarus Does this work for RTL packages as well? The IDE doesn't rebuild RTL , or fpc packages. But if you have your own fpc build, you can always rebuild and install it with debug info. Once the debug info is there it will work. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Em 15/03/14 22:47, Marcos Douglas escreveu: So, what the best way to substitute PostMessage? Maybe using QueueAsyncCall + IFPObserved/IFPObserver? Have you tried decoupling your classes with interfaces? If I understood your scenario correctly: Main implements an interface known by Proc, which sends itself to the Proc constructor. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Michael Schnell schrieb: On 03/16/2014 09:23 AM, zeljko wrote: Why you must substitute PostMessage ? This is a Windowish left-over and really alien regarding the OS-independent making of the LCL (even though In fact the LCL even simulates PostMessage in Linux. How would you handle keyboard and mouse input and painting in an application? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] debugging parts of rtl from within lazarus
On Mo, 2014-03-17 at 17:22 +, Mark Morgan Lloyd wrote: Marc Santhoff wrote: Hi, the FAQ gives instructions for debugging FCL from within lazarus. http://wiki.lazarus.freepascal.org/Lazarus_Faq#How_can_I_debug_FCL_components_from_packages_with_Lazarus Does this work for RTL packages as well? I need to set breakpoints inside serial.pp to see what data SerRead and SerWrite really get. I'm fairly sure that I used Lazarus to set breakpoints in that unit, but when I was working on it I'd have been using a copy in my project's working directory. The patch at http://mantis.freepascal.org/view.php?id=18946 contains a test program that you might find useful, it's quirky but I used it heavily when testing the unit for Linux/Solaris/Windows. Many thanks, it will be useful. :) But some questions popping up: In the patch report you write SerFlush() is non-destructive and the new SerFlushInput/Output() are destructive. What does this mean exactly? From my memory using flush on a file descriptor is used to force writing the pending contents through to the disk or file or whatever is connected. Regarding serial ports there mostly is a hardware function for emptying the read oder write queue while throwing away anything in there. Is that the difference in the flushing you're talking about? -- Marc Santhoff m.santh...@web.de -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] debugging parts of rtl from within lazarus
On Mo, 2014-03-17 at 18:03 +, Martin Frb wrote: On 17/03/2014 16:40, Marc Santhoff wrote: the FAQ gives instructions for debugging FCL from within lazarus. http://wiki.lazarus.freepascal.org/Lazarus_Faq#How_can_I_debug_FCL_components_from_packages_with_Lazarus Does this work for RTL packages as well? The IDE doesn't rebuild RTL , or fpc packages. But if you have your own fpc build, you can always rebuild and install it with debug info. I have no own build but the sources. Reading the FAQ it should work to cd to .../rtl/unix, build with -gl, and afterwards install the new ppu to the same location as the compiler. I'd like better if I could switch a standard version and a debugging version of the RTL. If it works in general this could be done by some conditionals in .fpc.cfg, I think. Where I'm not sure is if the build RTL build and install works the same as for lazarus packages. Once the debug info is there it will work. I'll try. -- Marc Santhoff m.santh...@web.de -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 3:12 PM, Joao Morais l...@joaomorais.com.br wrote: Em 15/03/14 22:47, Marcos Douglas escreveu: So, what the best way to substitute PostMessage? Maybe using QueueAsyncCall + IFPObserved/IFPObserver? Have you tried decoupling your classes with interfaces? I thought, yes, but I want to keep simple as possible. If I understood your scenario correctly: Main implements an interface known by Proc, which sends itself to the Proc constructor. That's an idea... but isn't like that today. Proc (following example) do not know Main or any interface that Main knows. Proc could be used in many others classes and not knows nothing about these classes. Using PostMessage Proc just notify handlers about a message with the possibility to send value objects too. Regards, Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Em 17/03/14 16:28, Marcos Douglas escreveu: On Mon, Mar 17, 2014 at 3:12 PM, Joao Morais l...@joaomorais.com.br wrote: Em 15/03/14 22:47, Marcos Douglas escreveu: So, what the best way to substitute PostMessage? Maybe using QueueAsyncCall + IFPObserved/IFPObserver? Have you tried decoupling your classes with interfaces? I thought, yes, but I want to keep simple as possible. Simplicity and portability - two arguments on behalf of interfaces! =) If I understood your scenario correctly: Main implements an interface known by Proc, which sends itself to the Proc constructor. That's an idea... but isn't like that today. Proc (following example) do not know Main or any interface that Main knows. Proc could be used in many others classes and not knows nothing about these classes. Because of that Proc only knows an interface that Main, perhaps others should implement. Anyway just thinking out loud, you are the one that knows the requisites, what can and what can't be done. =) HTH -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] debugging parts of rtl from within lazarus
Am 17.03.2014 20:23 schrieb Marc Santhoff m.santh...@web.de: The IDE doesn't rebuild RTL , or fpc packages. But if you have your own fpc build, you can always rebuild and install it with debug info. I have no own build but the sources. Reading the FAQ it should work to cd to .../rtl/unix, build with -gl, and afterwards install the new ppu to the same location as the compiler. You should merely go to $fpcsrc/rtl and do make clean all OPT=-gl. Your source should be of the same compiler version as the compiler you build with. Also if you use a unit (or a package) that depends on any of the recompiled units that will need to be recompiled as well. So for RTL I would suggest you to only copy the Serial unit as dependencies on that should be rather low. Additionally you won't be annoyed by having the debugger step all helper routines used by the compiler. Note: the location same as compiler would be wrong. You need to copy the unit to the location where the normal serial.ppu and serial.o are stored (and you should make a backup of course). Normally thus should he something like /usr/lib/fpc/2.6.4/units/i386-linux/rtl or so... I'd like better if I could switch a standard version and a debugging version of the RTL. If it works in general this could be done by some conditionals in .fpc.cfg, I think. In that case you should recompile the complete source (inside the $fpcsrc directory) with OPT=-gl and then you'll need to install the units to a different location (e.g. /usr/lib/2.6.4/units-dbg) and then adjust the fpc.cfg to use a different set of paths if you specify a special define on the command line (e.g. -dDEBUG_UNITS) Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Am 17.03.2014 19:15 schrieb Hans-Peter Diettrich drdiettri...@aol.com: Michael Schnell schrieb: On 03/16/2014 09:23 AM, zeljko wrote: Why you must substitute PostMessage ? This is a Windowish left-over and really alien regarding the OS-independent making of the LCL (even though In fact the LCL even simulates PostMessage in Linux. How would you handle keyboard and mouse input and painting in an application? Like any other widgetset which does know nothing about PostMessage does? Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] CeCILL-C licence and Lazarus?
Somebody used this licence to release components for Lazarus? -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] debugging parts of rtl from within lazarus
Marc Santhoff wrote: On Mo, 2014-03-17 at 17:22 +, Mark Morgan Lloyd wrote: Marc Santhoff wrote: Hi, the FAQ gives instructions for debugging FCL from within lazarus. http://wiki.lazarus.freepascal.org/Lazarus_Faq#How_can_I_debug_FCL_components_from_packages_with_Lazarus Does this work for RTL packages as well? I need to set breakpoints inside serial.pp to see what data SerRead and SerWrite really get. I'm fairly sure that I used Lazarus to set breakpoints in that unit, but when I was working on it I'd have been using a copy in my project's working directory. The patch at http://mantis.freepascal.org/view.php?id=18946 contains a test program that you might find useful, it's quirky but I used it heavily when testing the unit for Linux/Solaris/Windows. Many thanks, it will be useful. :) But some questions popping up: In the patch report you write SerFlush() is non-destructive and the new SerFlushInput/Output() are destructive. What does this mean exactly? I'm working from memory here. SerFlush() tried to do a sync(), which was considered to be pointless so is now marked deprecated. If you really do want to do this, then use SerSync(). SerDrain() waits until pending output has been sent i.e. is non-destructive, SerFlushInput() and SerFlushOutput() both clear buffers so are destructive. Please note that these are basically very thin wrappers around the unix (Linux/Solaris) API. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
