Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
Michael Schnell schrieb: TThread.Queue in the end calls WakeMainThread() to wake the main thread (i.e. terminate the CheckSynchronize call waiting for a timeout). In Simula a single time base is used to trigger events at a known time. Each event, to occur after a given delay, is enterd into a queue, sorted by the absolute time of the event. Every clock tick increments the internal clock, and triggers all events waiting for the time just reached. For periodic events the event handler enters itself into the queue again, for the next event time. When the next time is calculated from the time of the previous event, incremented by the time period, jitter or delays in event processing are eliminated. Event handlers in the main loop can be invoked immediately, for handlers in other threads the thread is suspended when it waits for an event, and is resumed when the time has been reached. This way a thread also can wait for multiple events, it only has to fork to the handler associated with the just signaled event. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus project and git workflow
On 2014-06-26 20:36, Václav Valíček wrote: > mergetool command). If you use meld, I can suggest --auto-merge (or > --auto-compare - not sure). It is perfect timesaver. Beyond Compare is another brilliant tool for 3-way merges and anything else you need to diff (files, images, registry, directories etc). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazarus project and git workflow
Hi, it's normal to solve merge/rebase conflicts by hand... Sometimes, git is able to solve changes, if each of you edits another part of form (another part of lfm diffs). In other cases, you are forced to use 3 way merging, best with some GUI tool. For me, it was best to set mergetool in .gitconfig and then git opens editor for each file (afrer git mergetool command). If you use meld, I can suggest --auto-merge (or --auto-compare - not sure). It is perfect timesaver. Václav Valíček vac...@valicek.name Dne 26.6.2014 15:03, Petr Hlozek napsal(a): Hi, if two or more developers work on a project, they sometimes edit the same form. Git can't solve the changes and you have to do it by hand. Even it's better to use the form the other developer and add the changes again by hand. It's impossible to solve the conflict. What do you do when you have this problem? Thank you for you time! Petr -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Split Source Editor window
On Thu, 26 Jun 2014 20:37:19 +0200 (CEST) Michael Van Canneyt wrote: >[...] > If Ido Kanner left the community, then maybe the package should be added to > the > Lazarus source tree, so it does not get lost. The packages in the Lazarus sources need a maintainer. Without a maintainer the package can go to for example lazarus-ccr. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Split Source Editor window
On Thu, 26 Jun 2014, Vojtěch Čihák wrote: Hello, today I read IT news and there is announcement of the new release of Eclipse (version 4.4 Luna). One of the mentioned news is ability to split editor window vertically or horizontally. I would like to remind here that Lazarus has this ability too. The code comes from Ido Kanner who left our community ~1 year ago. You can download here: https://github.com/ik5/split_lazarus Ido Kanner himself announced this package here in February 2013. The code compiles still well. I tried a few minutes ago with Lazarus 1.3 r45669M FPC 2.7.1 x86_64-linux-qt. It is good piece of code and should not be forgotten. If Ido Kanner left the community, then maybe the package should be added to the Lazarus source tree, so it does not get lost. Michael.-- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] PoChecker possible cosmetical patch
On 6/26/14, Václav Valíček wrote: > I have opened bug no. #26395 > > Link: http://bugs.freepascal.org/view.php?id=26395 > > Václav Valíček Thanks. If I have questions I'll ask in the bugreport. Might take some time before I get to work on it though... Bart -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On Thu, 26 Jun 2014 16:52:59 +0200 Michael Schnell wrote: > On 06/26/2014 03:54 PM, Mattias Gaertner wrote: > > Application.ProcessMessages calls CheckSynchronize and calls the > > queued async calls. Under nogui that's all. > Here the waiting and sleeping mechanism is lacking. If you mean for TTimer: Yes, I'm waiting for your patch. > Application.ProcessMessages supposedly calls CheckSynchronize with the > Timeout set to 0. Yes. > The timeout is critical for me, as it is used to implement TTimer. > > In my Application CheckSynchronize always is called with the Timeout set > to a non zero Value. > > TThread.Queue in the end calls WakeMainThread() to wake the main thread > (i.e. terminate the CheckSynchronize call waiting for a timeout). > > I did not yet find any lower level non private queue-feed functionality > usable instead of TThread.Queue. So? Program a queue. > > Other widgetsets process > > the widgetsets events as well. > They implement a second queue besides the one the RTL implements for > TThread. Probably they have several. > > A LCL program calls Application.Run, which is a loop calling > > Application.ProcessMessages. You can create sub loops. A common example > > is TForm.ShowModal, which also calls Application.ProcessMessages. > > Or you can do your own loop, in which case you have to call it yourself. > > > > If you call CheckSynchronize instead of Application.ProcessMessages you > > simply omit the widgetsets and queued async calls. > Other "active" LCL Widget Types call CheckSynchronize with Timeout set > to Zero and implement their own arch depending waiting mechanism, as > they are greatly arch depending anyway. My tiny Application not > inherently arch depending implementation just uses CheckSynchronize to > do the waiting (e.g. for TTimer) and hence does not an arch depending > implementation for this. Ok. You have the tools, you have a proof of concept, now program it and create a patch. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Split Source Editor window
Hello, today I read IT news and there is announcement of the new release of Eclipse (version 4.4 Luna). One of the mentioned news is ability to split editor window vertically or horizontally. I would like to remind here that Lazarus has this ability too. The code comes from Ido Kanner who left our community ~1 year ago. You can download here: https://github.com/ik5/split_lazarus Ido Kanner himself announced this package here in February 2013. The code compiles still well. I tried a few minutes ago with Lazarus 1.3 r45669M FPC 2.7.1 x86_64-linux-qt. It is good piece of code and should not be forgotten. Have a nice time, Vojtěch. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE bug handling translations?
Il 25/06/2014 14:33, Václav Valíček ha scritto: If you have any knowledge of russian language, one of core maintainers maintains russian translations, so you can use ideas from it... For a Czech language, there is huge difference from Russian, becose of location - Czech (and Slovakian) people between 5-7 century moved to future Czech Republic as most eastern tribe of original Slovan people, so we were under influence of germanistic and romanian languages... Everybody is under some influence. You find a lot of French words in Russian, of Italian words in Croatian, etc. The secret is to take the best from each. Such as vodka from Russia, and beer from Czech. Personally I prefer Budvar beer to Pilsener Giuliano -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE bug handling translations?
Il 25/06/2014 21:29, Maxim Ganetsky ha scritto: 25.06.2014 13:48, Giuliano Colla пишет: I'd hate to steal the job to an official maintainer, mainly in those days of unemployment :-) , but the Italian translation appeared to pochecker like a battlefield, already before running localize.sh. Aside from previous and last discrepancies, there's also a high number of inconsistencies, such as Tools being translated sometimes as Tools, sometimes as Environment, just to mention the first one. They appear to be remnants of very old Lazarus versions. If you add that poedit denounces some 41% untranslated strings, it looks like the matter deserves some attention. All of that comes from just one single file: lazarusidestrconsts. I'm afraid other files aren't in a better shape! So, if the official maintainer is unable/unwilling to update the Italian translations, I can take this boring job on my shoulders, at least to provide a more complete and updated set of po files, to restart with. Please go ahead. Italian translation was last touched 3 years ago. Ok. I already posted on the bugtracker a first quick update, just meant to avoid IDE crashes. Only I happened to click the wrong place, and I posted in Lazarus "packages" instead of "patches" as I intended. After that no way to move it! I also tried to get in touch with the last translator, but no answer from him. Giuliano -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
Am 26.06.2014 15:02 schrieb "Mattias Gaertner" :
>
> On Thu, 26 Jun 2014 14:41:21 +0200
> Sven Barth wrote:
>
> >[...]
> > {$IF FPC_FULLVERSION < 20701}
> > {$MESSAGE fatal 'You need at least FPC 2.7.1'}
>
> {$ERROR 'You need at least FPC 2.7.1'}
>
> But the Lazarus code must work with 2.6.4, so there must not be an
> error.
>
At the beginning Michael sounded more like he wants to implement a new
widgetset that's only relying on TThread functionality and thus would
require 2.7.1. For the case of extending NoGui you are of course right.
Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On 06/26/2014 03:54 PM, Mattias Gaertner wrote: Application.ProcessMessages calls CheckSynchronize and calls the queued async calls. Under nogui that's all. Here the waiting and sleeping mechanism is lacking. Application.ProcessMessages supposedly calls CheckSynchronize with the Timeout set to 0. The timeout is critical for me, as it is used to implement TTimer. In my Application CheckSynchronize always is called with the Timeout set to a non zero Value. TThread.Queue in the end calls WakeMainThread() to wake the main thread (i.e. terminate the CheckSynchronize call waiting for a timeout). I did not yet find any lower level non private queue-feed functionality usable instead of TThread.Queue. Other widgetsets process the widgetsets events as well. They implement a second queue besides the one the RTL implements for TThread. A LCL program calls Application.Run, which is a loop calling Application.ProcessMessages. You can create sub loops. A common example is TForm.ShowModal, which also calls Application.ProcessMessages. Or you can do your own loop, in which case you have to call it yourself. If you call CheckSynchronize instead of Application.ProcessMessages you simply omit the widgetsets and queued async calls. Other "active" LCL Widget Types call CheckSynchronize with Timeout set to Zero and implement their own arch depending waiting mechanism, as they are greatly arch depending anyway. My tiny Application not inherently arch depending implementation just uses CheckSynchronize to do the waiting (e.g. for TTimer) and hence does not an arch depending implementation for this. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Source Editor enhancement mini-patch
On 26/06/2014 13:41, Michael Van Canneyt wrote: 'By default' also means "it can be disabled" for example by deinstalling it :) It would be just one more option in the bazillion other options already at one's disposal. By including it by default, it also gets more exposure and can be substantially improved. True, well I am not objecting it, if any one wants to do that. A custom-drawn tab (while no doubt useful on other accounts) is more limited in its possibilities, and is therefor (imho) the less preferable option... It is a different solution. "limited" can be an advantage in that case -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
Il 25/06/2014 15:16, Michael Schnell ha scritto: On 06/24/2014 09:30 AM, Giuliano Colla wrote: Widget Types are LCL related. It's the part which actually implements virtual abstract methods in the Interfaces unit. Yep. So it seems perfectly suitable to individually define the functionality of classes that share a common name. [...] Only if you implement a widgeset using the same mechanism of virtual abstact methods, and all properties and methods are identical to those supported by LCL, which isn't true in general. At least not for Kylix and FpGui. Just a trivial example: Kylix TForm has a Bitmap property to provide a background image to the form. LCL doesn't. Either you add this property to LCL, implement it in each widgetset, making unhappy the supporters of "native look", or you drop this property, and do not support a feature which is used in hundreds of applications, to provide users an easy visual feedback. LCL is but one way to go. It has pros and cons. But it's not the only one. Giuliano -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On Thu, 26 Jun 2014 15:07:22 +0200 Michael Schnell wrote: >[...] > But maybe it really is not perfectly compatible, as, > _when_called_in_the_main_thread_, TThread.Queue perhaps does a direct > call instead of a queued schedule, which might not be true with > Application.QueueAsyncCall. I need to take a look at this. > > > If your main thread does not call Application.ProcessMessages, what > > does it call to give time to the async calls? > See the my messages above in this thread: > checksynchronize() Application.ProcessMessages calls CheckSynchronize and calls the queued async calls. Under nogui that's all. Other widgetsets process the widgetsets events as well. > > Stating the obvious: > > If you implement a LCL function in the nogui widgetset, you have to > > implement it compatible. Your goals and opinions are no excuses > > for incompatibility. > > > "Events are executed without the user needing to call > Application.ProcessMessages" is how all "decent" LCL WidgetTypes work > (but supposedly not NoGUI). Hence this is perfectly "compatible". Not true. A LCL program calls Application.Run, which is a loop calling Application.ProcessMessages. You can create sub loops. A common example is TForm.ShowModal, which also calls Application.ProcessMessages. Or you can do your own loop, in which case you have to call it yourself. If you call CheckSynchronize instead of Application.ProcessMessages you simply omit the widgetsets and queued async calls. Why do you think this is a feature? > My initial intention was a new WidgetType called "ActiveNoGUI". But > here, I was presented with the suggestion to instead enhance the current > "NoGUI" WidgetType. This might or might not (for compatibility issues) > be desirable. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Probbably unused resourcestring. Can I delete it?
On Thu, 26 Jun 2014 14:48:44 +0200 Václav Valíček wrote: > Hi, > > I'm trying to do small revolution in resourcestrings. In package > codetools, I have found resourcestring, which does not occur in whole > lazarus repo. Can I delete it? > > It's ctsSourceOfUnitNotFound - it exists just in .rst file, .po files of > package and in executables with compiled codetools package inside. > > What do you think about it... I removed it. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On 06/26/2014 02:52 PM, Mattias Gaertner wrote: On Thu, 26 Jun 2014 14:06:15 +0200 Michael Schnell wrote: [...] Of course I do know this. Make up your mind. Either I'm "Not true at all" or I wrote something right. "Not true" was, that my implementation of Application.QueuAsyncCall using TThread.Queue would not perform the calls in the main thread. (This in fact already does work perfectly.) But maybe it really is not perfectly compatible, as, _when_called_in_the_main_thread_, TThread.Queue perhaps does a direct call instead of a queued schedule, which might not be true with Application.QueueAsyncCall. I need to take a look at this. If your main thread does not call Application.ProcessMessages, what does it call to give time to the async calls? See the my messages above in this thread: checksynchronize() Stating the obvious: If you implement a LCL function in the nogui widgetset, you have to implement it compatible. Your goals and opinions are no excuses for incompatibility. "Events are executed without the user needing to call Application.ProcessMessages" is how all "decent" LCL WidgetTypes work (but supposedly not NoGUI). Hence this is perfectly "compatible". My initial intention was a new WidgetType called "ActiveNoGUI". But here, I was presented with the suggestion to instead enhance the current "NoGUI" WidgetType. This might or might not (for compatibility issues) be desirable. Of course, my primary goal is compatibility, of course, secondary is low overhead. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Source Editor enhancement mini-patch
On Thu, 26 Jun 2014 12:12:04 +0200 Hans-Peter Diettrich wrote: > Giuliano Colla schrieb: > > > However there's a Delphi IDE small feature which I miss when using > > Lazarus: a quick mouse access to the Jump Back/Jump Forward function, to > > navigate history. I find keyboard shortcuts (CTRL-H and Shift-CTRL-H) > > more cumbersome. > > Just a note: Delphi shorcuts for these are Alt-Left and Alt-Right. I added them as default keys. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Lazarus project and git workflow
Hi, if two or more developers work on a project, they sometimes edit the same form. Git can't solve the changes and you have to do it by hand. Even it's better to use the form the other developer and add the changes again by hand. It's impossible to solve the conflict. What do you do when you have this problem? Thank you for you time! Petr -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On Thu, 26 Jun 2014 14:41:21 +0200
Sven Barth wrote:
>[...]
> {$IF FPC_FULLVERSION < 20701}
> {$MESSAGE fatal 'You need at least FPC 2.7.1'}
{$ERROR 'You need at least FPC 2.7.1'}
But the Lazarus code must work with 2.6.4, so there must not be an
error.
> {$ENDIF}
>[...]
> > - TThread.Queue,:
> > I use this to implement Application.QueuAsyncCall.
> > I can try to do the (supposedly minimal) code that in TThread.Queue
> forwards the procedure of object to the Event queue, native in the
> implementation of my TApplication class.
>
> A little sidenote: the current implementation immediately executes events
> queued by the main thread. This is Delphi compatible.
Then this cannot be used to implement the LCL
TApplication.QueueAsyncCall as it must execute *after* the current
event/function.
Mattias
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On 06/26/2014 02:41 PM, Sven Barth wrote: Did you even look at the interface of TThread? There's a protected instance function that calls a public class function with Self as first parameter. If you use the second one and pass Nil as first parameter it automatically uses the current thread. You are obviously right But this is not at all my Problem. If I do have TThread.Queue I will be able to use it. (Possible optimizations will be done, of course.) A little sidenote: the current implementation immediately executes events queued by the main thread. This is Delphi compatible. I see. I suppose this is not a problem. Maybe this is not fully compatible with Application.QueueAsyncCall (if same is called in the main thread), which I did implement using TThread.Queue. Do you think this is a problem ? If yes I would need to take another look. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On Thu, 26 Jun 2014 14:06:15 +0200 Michael Schnell wrote: >[...] > Of course I do know this. Make up your mind. Either I'm "Not true at all" or I wrote something right. > But my goal is that these Events are executed > without the user needing to call Application.ProcessMessages. (IMHO this > is how decent Object Pascal Applications are supposed to work.) If your main thread does not call Application.ProcessMessages, what does it call to give time to the async calls? Stating the obvious: If you implement a LCL function in the nogui widgetset, you have to implement it compatible. Your goals and opinions are no excuses for incompatibility. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Source Editor enhancement mini-patch
On Thu, 26 Jun 2014, Martin Frb wrote: On 26/06/2014 13:18, Michael Van Canneyt wrote: On Thu, 26 Jun 2014, Martin Frb wrote: On 26/06/2014 11:12, Hans-Peter Diettrich wrote: I also would like to have clickable forward/back items. They also might become part of the editor gutter? I'd rather see a custom drawn pagecontrol, that allows for such buttons... IMHO the easiest and most powerful solution is to incorporate the editortoolbar by default in the source editor. Given the way screens have evolved, I'd place it at the right or left of the source editor. I have 2 screens, and I would not want it anywhere In fact, I use the option "Hide tabs, if only one unit in window" 'By default' also means "it can be disabled" for example by deinstalling it :) It would be just one more option in the bazillion other options already at one's disposal. By including it by default, it also gets more exposure and can be substantially improved. A custom-drawn tab (while no doubt useful on other accounts) is more limited in its possibilities, and is therefor (imho) the less preferable option... Anyway, it was just a suggestion. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Probbably unused resourcestring. Can I delete it?
Hi, I'm trying to do small revolution in resourcestrings. In package codetools, I have found resourcestring, which does not occur in whole lazarus repo. Can I delete it? It's ctsSourceOfUnitNotFound - it exists just in .rst file, .po files of package and in executables with compiled codetools package inside. What do you think about it... -- Václav Valíček vac...@valicek.name -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On 06/26/2014 01:47 PM, Mattias Gaertner wrote: I can rephrase it: The LCL Application.QueueAsyncCalls can be called by any thread, and executes the calls, when the main thread calls Application.ProcessMessages. Therefore the calls are executed by the main thread. Of course I do know this. But my goal is that these Events are executed without the user needing to call Application.ProcessMessages. (IMHO this is how decent Object Pascal Applications are supposed to work.) I implemented it in My TApplication class and it does work perfectly (using the svn-version of the fpc rtl). You don't need TThread.Queue for that. To do an _active_ application you need an event queue for that purpose. The GUI based Widget Types use their own Event Queue implementations in the LCL for this. (AFAIK) NoGUI does not have an Event Queue in the LCL (and I don't want to add one). Hence it can't "automatically" (without a main loop visible to the user) do Main Thread Events (such as fired by TTimer and QueueAsyncCall(). So the only EventQueue I (want to) have in my ActiveNoGUI Application is the one provided by the fpc RTL. And same is integrated with the TThread implementation I need to (and am happy to) use same. But this is only possible since the appearance of TThread.Queue (which is compatible even to rather old Delphi versions and some time ago has been done due to my request) . -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
Am 26.06.2014 12:36 schrieb "Michael Schnell" :
>
> On 06/25/2014 09:57 PM, Sven Barth wrote:
>>
>>
>> If you rely on the new TThread functionality you'd need to at least put
in guards against compiling with a pre-2.7.1 compiler.
>
> Can I do this by a {$ifdef ... } ?
{$IF FPC_FULLVERSION < 20701}
{$MESSAGE fatal 'You need at least FPC 2.7.1'}
{$ENDIF}
Untested. I haven't used $message in quite some time...
>
>
>> Better would be to write the code in a way that it works with 2.6.x as
well.
>
>
> I can try to do this:
>
> - TThread.CurrentThread:
> This is only necessary for perfectly calling TThread.Queue, as same is
not a class functions (even though I suppose it could be)
Did you even look at the interface of TThread? There's a protected instance
function that calls a public class function with Self as first parameter.
If you use the second one and pass Nil as first parameter it automatically
uses the current thread.
>
> - TThread.Queue,:
> I use this to implement Application.QueuAsyncCall.
> I can try to do the (supposedly minimal) code that in TThread.Queue
forwards the procedure of object to the Event queue, native in the
implementation of my TApplication class.
A little sidenote: the current implementation immediately executes events
queued by the main thread. This is Delphi compatible.
Regards,
Sven
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Source Editor enhancement mini-patch
On 26/06/2014 13:18, Michael Van Canneyt wrote: On Thu, 26 Jun 2014, Martin Frb wrote: On 26/06/2014 11:12, Hans-Peter Diettrich wrote: I also would like to have clickable forward/back items. They also might become part of the editor gutter? I'd rather see a custom drawn pagecontrol, that allows for such buttons... IMHO the easiest and most powerful solution is to incorporate the editortoolbar by default in the source editor. Given the way screens have evolved, I'd place it at the right or left of the source editor. I have 2 screens, and I would not want it anywhere In fact, I use the option "Hide tabs, if only one unit in window" -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Source Editor enhancement mini-patch
On Thu, 26 Jun 2014, Martin Frb wrote: On 26/06/2014 11:12, Hans-Peter Diettrich wrote: Just a note: Delphi shorcuts for these are Alt-Left and Alt-Right. Keys can be re assigned. I too use the alt variant I also would like to have clickable forward/back items. They also might become part of the editor gutter? I'd rather see a custom drawn pagecontrol, that allows for such buttons... IMHO the easiest and most powerful solution is to incorporate the editortoolbar by default in the source editor. Given the way screens have evolved, I'd place it at the right or left of the source editor. Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Source Editor enhancement mini-patch
On 26/06/2014 11:12, Hans-Peter Diettrich wrote: Just a note: Delphi shorcuts for these are Alt-Left and Alt-Right. Keys can be re assigned. I too use the alt variant I also would like to have clickable forward/back items. They also might become part of the editor gutter? I'd rather see a custom drawn pagecontrol, that allows for such buttons... -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Source Editor enhancement mini-patch
Giuliano Colla schrieb: However there's a Delphi IDE small feature which I miss when using Lazarus: a quick mouse access to the Jump Back/Jump Forward function, to navigate history. I find keyboard shortcuts (CTRL-H and Shift-CTRL-H) more cumbersome. Just a note: Delphi shorcuts for these are Alt-Left and Alt-Right. I also would like to have clickable forward/back items. They also might become part of the editor gutter? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On Thu, 26 Jun 2014 13:12:14 +0200 Michael Schnell wrote: > On 06/26/2014 12:25 PM, Mattias Gaertner wrote: > > Ok. That's incompatible to the LCL QueueAsyncCalls, which executes the > > calls in the main thread. > Not true at all. Huh? I can rephrase it: The LCL Application.QueueAsyncCalls can be called by any thread, and executes the calls, when the main thread calls Application.ProcessMessages. Therefore the calls are executed by the main thread. You don't need TThread.Queue for that. For example lazbuild uses the nogui widgetset and uses QueueAsyncCalls. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] [fpc-pascal] fpspreadsheet 1.2 has been released
On Thu, 26 Jun 2014, Reinier Olislagers wrote: (Cross-posted to FPC & Lazarus lists) We're pleased to announce that fpspreadsheet 1.2 has been released. [snip] Bug fixes ... and bug fixes. Link to download and more information via http://wiki.lazarus.freepascal.org/FPSpreadsheet Impressive. As a long-time user of fpSpreadsheet I am very pleased to read all this :) Great job, and keep up the good work !! Michael. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On 06/26/2014 12:25 PM, Mattias Gaertner wrote: Ok. That's incompatible to the LCL QueueAsyncCalls, which executes the calls in the main thread. Not true at all. The task of TThread.Queue is scheduling a Main thread Event ! Of course I did the implementation of TApplication in a way that the Async call is queued and done in the main thread and is provided with the parameter given in QueueAsyncCalls. The problem is, that I in fact do need TThread.Queue, because I can't re-implement the code in TThread.Queue as same uses stuff that is defined as private in TThread. So I in fact do need the more recent compiler / RTL version. (There was a reason why I restarted my long sleeping project to do an ActiveNoGUI Widget type not before TThread.Queue has been implemented by the fpc team !!! ) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazreport of master-detail
> El Jueves, 26 de junio, 2014 3:08:23, Koenraad Lelong > escribió: ... > Hi, > > Since I did not find a way to backtrace in Lazarus, I did it via > gdb-commandline. This is what I get (Windows XP) : > > Program received signal SIGSEGV, Segmentation fault. > 0x004036bb in SYSTEM_FORWARDS_SSE_3 () > (gdb) bt > #0 0x004036bb in SYSTEM_FORWARDS_SSE_3 () > #1 0x005dc7a4 in > BUFDATASET_TCUSTOMBUFDATASET_$__CURRENTRECORDTOBUFFER$PCHAR > () > #2 0x0009b908 in ?? () > #3 0x00594cee in DB_TDATASET_$__GETPRIORRECORD$$BOOLEAN () > #4 0x00596fa7 in DB_TDATASET_$__RESYNC$TRESYNCMODE () > #5 0x0059692e in DB_TDATASET_$__GOTOBOOKMARK$POINTER () > #6 0x0001 in ?? () > #7 0x0007da50 in ?? () > #8 0x005c677a in RESTOREBOOKMARKS (parentfp=0x260f1e8) at lr_class.pas:7171 > #9 0x005c5ecb in TFRPAGE__FORMPAGE (this=) > at lr_class.pas:7438 ... The problem here is sqldb bookmark handling on detail datasets. In some circumstances it's broken, see bug reports http://bugs.freepascal.org/view.php?id=26132 and http://bugs.freepascal.org/view.php?id=26146 LazReport backup datasets current positions before the report is processed and then it tries to restore them when done. It does this because sometimes the datasets are linked to visual components which, in the end, would show incorrect "current" records. The implemented solution is by using a notification, when LazReport is about to backup the bookmarks, it triggers an event which on return instruct LazReport to do the backup/restore bookmark action or not. If "not backup/restore bookmarks" is (most of the time) the expected behavior, we can replace the current solution and implement a LazReport option, roDontBackupBookmarks enabled by default. So it doesnt backup/restore the bookmarks automatically. Suggestions are welcomed. Jesus Reyes A. > > Since it's not my application that's behaving bad (AFAICT) I'm going > to > try to reproduce this with a "public" database. Then I'll write a > bug-report. > > > Koenraad. > -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On Thu, 26 Jun 2014 12:13:39 +0200 Michael Schnell wrote: > On 06/26/2014 10:52 AM, Mattias Gaertner wrote: > > Application.QueueAsyncCall works in nogui if you call > > Application.ProcessMessages. > I am just doing the implementation of TApplication. And the point with > _active_ Applications is that the events are called without the user > needing to do a main loop. Ok. That's incompatible to the LCL QueueAsyncCalls, which executes the calls in the main thread. Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On 06/26/2014 09:28 AM, Michael Schnell wrote: - TThread.GetTickCount64: I can try to do the (supposedly minimal) code that in TThread.GetTickCount64 does a system call and some calculations, native in the implementation of my TApplication class. This version of the compiler even does not have "HAVECLOCKGETTIME" -> clock_gettime() and hence I need to fall back to fpgettimeofday() which is not very appropriate in this context. :-( -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On 06/26/2014 10:52 AM, Mattias Gaertner wrote: Application.QueueAsyncCall works in nogui if you call Application.ProcessMessages. I am just doing the implementation of TApplication. And the point with _active_ Applications is that the events are called without the user needing to do a main loop. Why use TThread.Queue? To implement Application.QueueAsyncCall. :-) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] fpspreadsheet 1.2 has been released
(Cross-posted to FPC & Lazarus lists) We're pleased to announce that fpspreadsheet 1.2 has been released. Changes since previous 1.1: fpSpreadsheetGrid: fpSpreadsheetGrid has been extended to display formatting of the cells and to evolve towards a spreadsheet viewer. The demo is modified to show how cell formatting can be interactively changed and how the modified spreadsheet can be saved to file. In addition to cell values, it can display the text representation of RPN formulas. biff support All biff file formats have been brought to the same level of support. Many limitations of number formats have been relaxed. Now any format can be written. Reading works for not too complex format constructions. Enhanced color and font support Color (including background color) and font support has been extended for the BIFF (Excel) file formats. The color type TsColor is no longer an enumeration now. Full font support, not just "bold". Enhanced formatting support Cell border styles: different line styles and colors for cell borders Text alignment: left/center/right alignment, top/center/bottom alignment of text within cell boundaries Wiki table output format Support for wiki table format output Support for Date/Time cells Read/write support for date/time/datetime cells in BIFF8 .xls, OpenDocument .ods. Write as text cell support for date/time/datetime cells in other formats Number/text/date/time format support in BIFF .xls and OpenDocument ods Number format parser to give access to most features of the number formats for reading and writing Formula support Support for ABS, DATE and TIME and 75 more RPN formulas added to biff format. Reading of RPN formulas from biff files. Conversion of RPN formulas to Excel-like strings Reading of string formulas from ods files Cardinal cell addressing For formats that support it, reading/writing to cells > 65536 rows/columns is now supported. Text cell size limit enforced Text cell size limits enforced for BIFF2..8 xls, xlsx and ooxml so it is no longer possible for excessively long cells to corrupt a file. Overflowing bytes are currently silently truncated. Zip64 support on FPC 2.7.1 On FPC 2.7.1, fpspreadsheet uses the FPC-supplied zip units, which provides support for large files/large number of files inside an ooxml/xlsx file. Unit tests for fpspreadsheet fpcunit unit tests have been added to fpspreadsheet that help ensure that - functionality is not changed inadvertently (regression tests) - interoperability with Excel/OpenOffice/LibreOffice files works (or does not get worse) Please add unit test cases whenever adding new functionality to fpspreadsheet (e.g. patches) Bug fixes ... and bug fixes. Link to download and more information via http://wiki.lazarus.freepascal.org/FPSpreadsheet -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On Thu, 26 Jun 2014 09:28:28 +0200 Michael Schnell wrote: >[...] > - TThread.Queue,: > I use this to implement Application.QueuAsyncCall. > I can try to do the (supposedly minimal) code that in TThread.Queue > forwards the procedure of object to the Event queue, native in the > implementation of my TApplication class. Application.QueueAsyncCall works in nogui if you call Application.ProcessMessages. Why use TThread.Queue? Mattias -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazreport of master-detail
On 26/06/2014 09:27, Koenraad Lelong wrote: > Since it's not my application that's behaving bad (AFAICT) I'm going to > try to reproduce this with a "public" database. Then I'll write a > bug-report. Ok, thanks. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On 06/25/2014 05:22 PM, Mattias Gaertner wrote: ok, then it needs ifdefs in nogui. Yep. How does such an ifdef exactly look like ? (see my answer to Sven..) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Lazreport of master-detail
op 24-06-14 12:20, Reinier Olislagers schreef: On 24/06/2014 10:29, Koenraad Lelong wrote: backtrace. Can I have a backtrace in Windows ? Yes. Use e.g. -gw2 -gl -O-1 (Lazarus: dwarf 2 format, line number, no optimization, add -O-1 in extra options or whatever it's called) when compiling. Run gdb as usual and you should get the backtrace or run it in the debugger under Lazarus to do things the GUI way ;) Hi, Since I did not find a way to backtrace in Lazarus, I did it via gdb-commandline. This is what I get (Windows XP) : Program received signal SIGSEGV, Segmentation fault. 0x004036bb in SYSTEM_FORWARDS_SSE_3 () (gdb) bt #0 0x004036bb in SYSTEM_FORWARDS_SSE_3 () #1 0x005dc7a4 in BUFDATASET_TCUSTOMBUFDATASET_$__CURRENTRECORDTOBUFFER$PCHAR () #2 0x0009b908 in ?? () #3 0x00594cee in DB_TDATASET_$__GETPRIORRECORD$$BOOLEAN () #4 0x00596fa7 in DB_TDATASET_$__RESYNC$TRESYNCMODE () #5 0x0059692e in DB_TDATASET_$__GOTOBOOKMARK$POINTER () #6 0x0001 in ?? () #7 0x0007da50 in ?? () #8 0x005c677a in RESTOREBOOKMARKS (parentfp=0x260f1e8) at lr_class.pas:7171 #9 0x005c5ecb in TFRPAGE__FORMPAGE (this=) at lr_class.pas:7438 #10 0x005cef0e in TFRREPORT__DOBUILDREPORT (this=) at lr_class.pas:9873 #11 0x005cdf8a in TFRREPORT__BUILDBEFOREMODAL (SENDER=0x9bb48, this=) at lr_class.pas:9517 #12 0x00612e5f in TFRPROGRESSFORM__DOBEFOREMODAL (DATA=0, this=) at lr_progr.pas:88 #13 0x0042309d in TAPPLICATION__PROCESSASYNCCALLQUEUE ( this=) at ./include/application.inc:1079 #14 0x0042192f in TAPPLICATION__IDLE (WAIT=true, this=) at ./include/application.inc:389 #15 0x0041d46c in TCUSTOMFORM__SHOWMODAL (this=) at ./include/customform.inc:2907 #16 0x00612db1 in TFRPROGRESSFORM__SHOW_MODAL (DOC=0x2f88228, this=) at lr_progr.pas:70 #17 0x005ce45e in TFRREPORT__DOPREPAREREPORT (this=) at lr_class.pas:9671 #18 0x005ce0eb in TFRREPORT__PREPAREREPORT (this=) at lr_class.pas:9567 #19 0x005cf151 in TFRREPORT__SHOWREPORT (this=) at lr_class.pas:9927 #20 0x00426f09 in TFORM1__BTNPREVIEWCLICK (SENDER=0x2f3fc10, this=) at modmain.pas:65 #21 0x00513068 in TCONTROL__CLICK (this=) at ./include/control.inc:2711 #22 0x0052fe6f in TBUTTONCONTROL__CLICK (this=) at ./include/buttoncontrol.inc:54 #23 0x005305c6 in TCUSTOMBUTTON__CLICK (this=) at ./include/buttons.inc:169 #24 0x00530c21 in TBUTTON__CLICK (this=) at ./include/buttons.inc:349 #25 0x0052fd7a in TBUTTONCONTROL__WMDEFAULTCLICKED (MESSAGE=..., this=) at ./include/buttoncontrol.inc:20 #26 0x0040b846 in SYSTEM_TOBJECT_$__DISPATCH$formal () #27 0x0052fd60 in TBUTTONCONTROL__ISCHECKEDSTORED ( this=) at ./include/buttoncontrol.inc:16 #28 0x00506b1f in TWINCONTROL__WNDPROC (MESSAGE=..., this=) at ./include/wincontrol.inc:5327 #29 0x0055e8db in DELIVERMESSAGE (TARGET=0x2f3fc10, AMESSAGE=void) at lclmessageglue.pas:112 #30 0x004de361 in WINDOWPROC (WINDOW=66834, MSG=273, WPARAM=64528, LPARAM=66846) at win32callback.inc:2478 #31 0x00587338 in CUSTOMFORMWNDPROC (WINDOW=66834, MSG=273, WPARAM=64528, LPARAM=66846) at win32wsforms.pp:395 #32 0x7e398734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll #33 0x00010512 in ?? () #34 0x7e398816 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll #35 0x00587230 in ADJUSTFORMBOUNDS (AFORM=0x0, SIZERECT=...) at win32wsforms.pp:316 #36 0x7e3a927b in USER32!GetParent () from C:\WINDOWS\system32\user32.dll #37 0x in ?? () (gdb) Since it's not my application that's behaving bad (AFAICT) I'm going to try to reproduce this with a "public" database. Then I'll write a bug-report. Koenraad. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On Thu, 26 Jun 2014 09:30:58 +0200
Michael Schnell wrote:
> On 06/25/2014 05:22 PM, Mattias Gaertner wrote:
> > ok, then it needs ifdefs in nogui.
>
> Yep.
>
> How does such an ifdef exactly look like ?
{$IF FPC_FULLVERSION >= 20701}
Mattias
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] nonlcl basic issue: is codetools LCL dependent?
On 06/25/2014 09:57 PM, Sven Barth wrote:
If you rely on the new TThread functionality you'd need to at least
put in guards against compiling with a pre-2.7.1 compiler.
Can I do this by a {$ifdef ... } ?
Better would be to write the code in a way that it works with 2.6.x as
well.
I can try to do this:
- TThread.CurrentThread:
This is only necessary for perfectly calling TThread.Queue, as same is
not a class functions (even though I suppose it could be)
- TThread.Queue,:
I use this to implement Application.QueuAsyncCall.
I can try to do the (supposedly minimal) code that in TThread.Queue
forwards the procedure of object to the Event queue, native in the
implementation of my TApplication class.
- TThread.GetTickCount64:
I can try to do the (supposedly minimal) code that in
TThread.GetTickCount64 does a system call and some calculations, native
in the implementation of my TApplication class.
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] IDE bug handling translations?
Added some patches for Czech translation and IDE resourcestrings. Caused some more bugs in other's translations... Report ID: #26394 Link: http://bugs.freepascal.org/view.php?id=26394 There are two main problems: 1, in Licences, I have replaced all %s with sLine break (in .po file \n) 2, conflict with updated Italian and Russian translations, but rebasing and merging IDE translations is like being in the hell. I suggested solution in bugfix. Václav Valíček vac...@valicek.name Dne 24.6.2014 19:27, Juha Manninen napsal(a): On Tue, Jun 24, 2014 at 8:05 PM, Mattias Gaertner wrote: Can you now use pochecker? Yes. It shows 173 errors in eg. lazaruside.fi.po which looks correct. Juha -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] PoChecker possible cosmetical patch
I have opened bug no. #26395 Link: http://bugs.freepascal.org/view.php?id=26395 Václav Valíček vac...@valicek.name Dne 19.6.2014 23:39, Bart napsal(a): On 6/19/14, Václav Valíček wrote: Hi, I have made improvement for PoChecker package/app for lazarus. I'm sending screenshot and asking if do you think it is usefull If yes, I'll export patches from git... If not, I'll keep it for myself. Another thing is patch to source of PoChecker, where I'm replacing raw strings with their existing resourcestring variants - whose are untranslated as origin strings at time of declaration, so the code does not lost functions... Attaching: screenshot, path for strings (apply with patch -p1 < 0001-blah-blah-blah.patch) I cannot see the image. Please open a bugreport and attach the screenshot and diff. I'll assign it to me (or someone else can assign it to me, in case I miss it). Bart -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
