Re: [Lazarus] Retina Font Rendering not working anymore in Lazarus Trunk

[zeljko]

On 06/27/2014 04:04 PM, Michael Ring wrote:

Long time since last post but I finally managed to get retina support to
work again.

I am not sure if Apple has dropped support for retina rendering in
carbon apps or if something inside of lazarus changed, right now there
are two paths to get super crisp fonts back:

Install qt4 and qt4pas, then recompile lazarus from svn trunk:

make clean all CPU_TARGET=x86_64 LCL_PLATFORM=qt
sudo rm -rf /usr/local/share/lazarus
sudo make install CPU_TARGET=x86_64 LCL_PLATFORM=qt

and perhaps:

lazbuild --build-ide= --ws=qt --cpu=x86_64 --compiler=ppcx64

other way is to recompile lazarus with LCL_PLATFORM=cocoa, but
unfortunately cocoa is not really usable at the moment, lots of crashes,
but better than the last time I checked.

it is necessary to compile in x86_64 because the packages provided by qt
only seem to include the x86_64 version of qt.

compiling for x86_64 works nearly perfect now, I needed to comment out
one function that does not seem to exist on x86_64:

Index: lcl/include/sysenvapis_mac.inc
===
--- lcl/include/sysenvapis_mac.inc(revision 45676)
+++ lcl/include/sysenvapis_mac.inc(working copy)
@@ -11,7 +11,7 @@
url := CFURLCreateWithBytes(nil, @AURL[1], Length(AURL),
kCFStringEncodingUTF8, nil);
if not Assigned(url) then
  Exit(False);
-  Result := LSOpenCFURLRef(url, nil) = 0;
+//  Result := LSOpenCFURLRef(url, nil) = 0;
CFRelease(url);
  end;

I am testing now for stability issues, so far no major problems (but I
am only using a small part of lazarus)



That's not only problem with qt-cocoa. Another problem is that sometimes 
mouse hangs (no respond to clicks) after modal from modal form is opened 
and closed. I suspect qt internal implementation 
(qapplication_enter_modal_sys (or similar name)) where private variable 
is used to check mouse down/up.


zeljko



--
___
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?

[Juha Manninen]

On Sat, Jun 28, 2014 at 1:51 AM, Giuliano Colla
 wrote:
> (I can't anchor the second Button to the first, because if the first becomes
> invisible, the second is moved from his position, which is not acceptable).

True, hiding the control ruins the plan of using anchors here.
A more standard way would be to disable it instead of hiding.


> Graeme Geldenhuys who had problems of the same sort ended up designing his
> own widgetset. I'm more modest, and I look to a design mediator.

Some sort of custom widgets could be a solution. There are component
libraries which can live side by side with LCL components.
I don't have any installed now but I remember testing some. I think I
will study them more if I need to make a fancy GUI.

Juha

--
___
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?

[Giuliano Colla]

Il 27/06/2014 23:34, Juha Manninen ha scritto:
You seem to have unusual GUIs. Still, I have a feeling you do 
something wrong when creating controls in code.

Setting the position, size or anchors at runtime work well.
Gtk2 may have some Z-order issues, QT is better.
Well, I may give you a small example. Two buttons, side by side. The 
first one has AutoSize set, to fit a text which must be determined at 
creation time. The next should go some ten pixels from the right edge of 
the first, and stay there even if the first is made invisible.


Kylix code:
Create the first button, then create the second. Set its Left property 
to Left_of_the_first+Width_of_the_first+required spacing. You're done, 
it works.


Lazarus code:
Just take Kylix code. The second button is partly over the first one.
You mumble a bit and understand that the Width you get isn't the actual 
Width of the button after AutoSizing, but just the default Button Width. 
Then you add some code, i.e. you calculate the TextExtent on the canvas 
of the first Button to evaluate the actual Width, add the few extra 
pixels for the button border, use this value, and finally it works.
(I can't anchor the second Button to the first, because if the first 
becomes invisible, the second is moved from his position, which is not 
acceptable).



I did not use a background bitmap but it should be doable, too.

Of course is doable. But how many kludges are required to ensure that at 
each repaint the Z-Order is properly respected, and that you don't have 
controls below the bitmap, or empty bitmap areas? I've done it once, and 
when I got tired of fighting there were still some detail which should 
have been adjusted.
If you ask specific questions in a new mail thread with example code 
snippets, I am sure people here will find solutions.


I don't share your confidence. Many problems are related to the way the 
widgetset send signals back: if signals are missing or wrong, there's 
little that developers can do. The intricacies of Interfaces make it 
very difficult to debug, or simply to locate the problem.


I have raised a problem quite some time ago: (as of Lazarus 1.0.8): If 
you move another window over a Group Box, not all controls are repainted 
properly when they're uncovered: the Group Box Title, Speed Buttons and 
Labels aren't repainted, or just partly repainted. Buttons and 
BitButtons are unaffected.
As of Lazarus 1.3 rev 45619 the problem is still there. I still compile 
an application where this problem is an issue because the affecting 
window is just the dropdown of a ComboBox, with a legacy Lazarus 0.9.28 
(or something around) which doesn't show the problem.


But a new similar problem which wasn't in 1.0.8 has popped up in the 
meantime: if you have a SpeedButton on a Panel, when you pass the mouse 
over it, and the control is highlighted, some surrounding controls are 
partly erased. e.g. TLabel is affected, TStaticText is not. You must add 
an OnMouseEnter and OnMouseLeave event to your SpeedButton, which 
triggers a repaint of the Panel to restore all controls.


Graeme Geldenhuys who had problems of the same sort ended up designing 
his own widgetset. I'm more modest, and I look to a design mediator.


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?

[Juha Manninen]

You seem to have unusual GUIs. Still, I have a feeling you do something
wrong when creating controls in code.
Setting the position, size or anchors at runtime work well.
Gtk2 may have some Z-order issues, QT is better.
I did not use a background bitmap but it should be doable, too.

If you ask specific questions in a new mail thread with example code
snippets, I am sure people here will find solutions.

Juha

P.S. I don't have anything against your design mediator. It only requires a
lot of work.
--
___
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?

[Giuliano Colla]

Il 27/06/2014 19:16, Juha Manninen ha scritto:
On Friday, June 27, 2014, Giuliano Colla > wrote:


I did consider this possibility because we have hundreds of Kylix
projects which are still alive, and need maintenance. Kylix IDE
can only be used on old platforms/virtual machines but the
compiler and the applications still run in the most recent ones.


Can they also bind to recent QT versions? I doubt.
Why should I care about a recent Qt version? They bind to their 
libborqt.so which provides what required.
My opinion is that you are heading to a dead end. You must work hard 
before the design mediator works, and then you can support a dead 
environment.


I don't care too much about being "modern". I claim that the best 
solution is always the most appropriate, not the "newest".
Tombstones are still made of stone. It's stone age technology, but it's 
the most appropriate up to now. Only if someone comes out with something 
better they will be finally dropped.
When I'll find something more appropriate for my applications, I'll drop 
Kylix with no regrets.


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?

[Giuliano Colla]

Il 27/06/2014 19:08, Juha Manninen ha scritto:


On Friday, June 27, 2014, Giuliano Colla > wrote:


But given this possibility, I find much more interesting and
stimulating the attempt to take advantage of this feature, than
the boring task of converting hundreds of Kylix applications to LCL!


Is it a boring task? It could be relatively easy because there are not 
many 3rd party libs for Kylix and the code does not call WinAPI 
extensively.
The converter in Lazarus is tested mostly with Delphi code, I would be 
interested in your experiences with Kylix code.




My experience of migrating Kylix code to Lazarus has been quite 
frustrating. My applications aren't classical database applications, 
where once you have a working DBGrid you're done.
They provide a human interface to complex machinery, which take largely 
advantage of visual features, to provide a comfortable visual feedback, 
visibility from distance, touch screen operation etc.
You need tons of workarounds to make them work under Lazarus, and to 
comply with native widgesets features and bugs. Just to mention a few:


 *

   I must provide forms with a background image, which can't be solid
   color for better readability, and this feature is missing from LCL.
   Painting the background of a form, and keeping it updated, without
   losing a lifetime, is quite a challenge, and what works with Lazarus
   0.9.29 doesn't work anymore with Lazarus 0.9.31, because of some
   changes somewhere, which don't affect DBGrids.

 *

   Whenever you need a form to "stay on top" you never know if it'll
   work or not. For Gtk2, it did work on Lazarus 1.0.8, but it stopped
   working since Lazarus 1.1. This means that a user may lose an alarm
   which pops up, because he inadvertently touched the larger form.

 *

   A lot of components are built run-time, and this again is a sort of
   nightmare. The interaction between LCL and widgetset makes that LCL
   properties are out of synch with actual widget at creation time. If
   two components are created at run time and must have a position or a
   size relative one to the other, it's again a fight, where frequently
   you end up as a loser.

The list might go on for pages, but that's the general idea. Basically 
for each visual component I must find a work-around, and this is long, 
frustrating and boring.


All of that is not because Lazarus developers are incompetent. They pay 
attention to what the majority of users requests, and they're always 
working on quicksand, because of always changing Gtk or Qt whims, they 
can't control, but must only obey to.
As a result I can use Lazarus for some applications which aren't too 
much demanding in terms of visual features, but not for hundreds of 
Kylix applications.


Giuliano
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] Accessibility of Lazarus

[Grzegorz Zlotowicz]

Hi all.
I'm Greg from Poland, a blind computer user and programmer. Looking for 
an advanced multi-platform framework to work with FPC, the Lazarus seems 
obvious choice, but unfortunately it has some accessibility problems.

After reading the
http://wiki.freepascal.org/LCL_Accessibility
I decided to write here about it, because maybe it'll be possible to fix 
the issues.
I'm using the NVDA screen-reader (www.nvda-project.org), and working 
under Windows (currently win7, but in xp the problems were the same, as 
I tested it some time ago).

Starting from simplest thing:
I compiled the bitbutton program in the examples directory.
The radio buttons, and their group names ("kind" and "layout") are read 
perfectly well.

But the problem is the button itself.
In the source, it has a "close" caption, but it is not announced by 
screenreader, although its' role as button is correctly recognized.
After setting the properties Accessiblevalue and accessibledescription 
to 'close', nothing changes.
The same problem has all buttons in Lazarus IDE, and also programs build 
using Lazarus.
Is there some possibility of solving the problem (I mean somebody 
knowleable and willing to do it)? Knowing Pascal, I don't know where to 
start debugging this thing.
I hope, that these problems can be rather easy to fix, and if it'd 
happen, it would make world easier for many people (not only 
programmers, but also all blind users of programs written using LCL).


The treeviews aren't accessible nearly at all (all items are read by the 
screenreader at the same time without identication which one is 
selected, or which collapsed); listboxes seems to work well.

But returning to the simplest button.
the fragment of the NVDA's log says about this control:

name: u''
role: ROLE_BUTTON
states: STATE_FOCUSABLE, STATE_FOCUSED
isFocusable: True
hasFocus: True
description: None
value: None
windowHandle: 32703706
windowClassName: u'Button'
windowText: u''
displayText: u''
IAccessible event parameters: windowHandle=32703706, objectID=-4, childID=0
IAccessible accName: None
IAccessible accRole: ROLE_SYSTEM_PUSHBUTTON
IAccessible accState: STATE_SYSTEM_DEFAULT, STATE_SYSTEM_FOCUSED, 
STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (1048836)

IAccessible accDescription: None
IAccessible accValue: None

Greetings, Greg.

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] App crash at TScreen.GetCustomFormsZOrdered

[Hans-Peter Diettrich]

Petr Hlozek schrieb:


I'd like to do that and hopefuly already did but the app is quite big
and I'm not sure fo 100%. Is there any way how to find out with any
utility?


FastMM4 can do that with Delphi, dunno about an FPC version. It can 
detect references to already destroyed objects, as well as objects not 
released when the program terminates.


DoDi


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] PoChecker possible cosmetical patch

[Václav Valíček]

I probbably wrote something in missunderstanding way... I prefer 
dxGetText against resorcestrings, becose ShowMessage(_'Text to 
translate')); is better for me than creating resourcestrings (because of 
future editing). But I have choosen it during my delphi era, because it 
is good to for translating comunity software - no need to edit sources, 
compile dll or lng files... Just editing po files by other users.


There is no difference for me as for raw translator. But when I want to 
tweak something, edit some message, I have to find resourcestring (easy, 
one click), find if is used on more or one place and then just edit or 
create new one... Or edit all other occurences. While using gettext as 
known from GNU Project apps, I just change strings in code and then 
regenerate .po files. If I have to use formatted messages with Format(), 
I can use __('str %s')  instead of _().


I'm not complaining about anything in IDE, just pointing at advantages 
of gettext and giving reasons why I use it.


Václav Valíček
vac...@valicek.name

Dne 27.6.2014 15:15, Mattias Gaertner napsal(a):

On Fri, 27 Jun 2014 13:09:06 +0200
Václav Valíček  wrote:


I prefer using dxGetText in my projects, but if Lazarus uses
resourcestrings, I must use resourcestrings when translating components.
I have experience with delphi 2010 translations (probbably same as
D2009) - and I wasn't very happy that I had to attach special
translation files, I wanted something text based. I started using
dxGetText... There is no problem for me if Lazarus does not translate
consts arrays during startup.

po files are text based.
There is a binary format: mo files, which saves some bytes. But those
few KB do not matter nowadays.
Of course you can use other ways to load your resourcestrings. You
don't need to use po files.

Mattias

--
___
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] nonlcl basic issue: is codetools LCL dependent?

[Juha Manninen]

On Friday, June 27, 2014, Giuliano Colla 
wrote:

> I did consider this possibility because we have hundreds of Kylix projects
> which are still alive, and need maintenance. Kylix IDE can only be used on
> old platforms/virtual machines but the compiler and the applications still
> run in the most recent ones.
>

Can they also bind to recent QT versions? I doubt.
My opinion is that you are heading to a dead end. You must work hard before
the design mediator works, and then you can support a dead environment.

Juha
--
___
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?

[Juha Manninen]

On Friday, June 27, 2014, Giuliano Colla 
wrote:

> But given this possibility, I find much more interesting and stimulating
> the attempt to take advantage of this feature, than the boring task of
> converting hundreds of Kylix applications to LCL!
>

Is it a boring task? It could be relatively easy because there are not many
3rd party libs for Kylix and the code does not call WinAPI extensively.
The converter in Lazarus is tested mostly with Delphi code, I would be
interested in your experiences with Kylix code.

Juha
--
___
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?

[Giuliano Colla]

Il 27/06/2014 14:44, Marco van de Voort ha scritto:

On Fri, Jun 27, 2014 at 11:50:18AM +0200, Giuliano Colla wrote:

[...]

This makes it impossible to use the features of IDE Designer as it is
for a Kylix project.

True, but the incompatible threw me off, and the perspective on what
incompatible with Kylix means.

I never considered loading unmodified CLX projects a Lazarus designgoal.
More so because the last Kylix is already a decade old.
Sorry for the misunderstanding. I did consider this possibility because 
we have hundreds of Kylix projects which are still alive, and need 
maintenance. Kylix IDE can only be used on old platforms/virtual 
machines but the compiler and the applications still run in the most 
recent ones.
Until recently I wasn't aware of the possibility of extending the IDE 
designer via a Mediator. But given this possibility, I find much more 
interesting and stimulating the attempt to take advantage of this 
feature, than the boring task of converting hundreds of Kylix 
applications to LCL!


Giuliano


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Retina Font Rendering not working anymore in Lazarus Trunk

[Michael Ring]

Long time since last post but I finally managed to get retina support to 
work again.


I am not sure if Apple has dropped support for retina rendering in 
carbon apps or if something inside of lazarus changed, right now there 
are two paths to get super crisp fonts back:


Install qt4 and qt4pas, then recompile lazarus from svn trunk:

make clean all CPU_TARGET=x86_64 LCL_PLATFORM=qt
sudo rm -rf /usr/local/share/lazarus
sudo make install CPU_TARGET=x86_64 LCL_PLATFORM=qt

and perhaps:

lazbuild --build-ide= --ws=qt --cpu=x86_64 --compiler=ppcx64

other way is to recompile lazarus with LCL_PLATFORM=cocoa, but 
unfortunately cocoa is not really usable at the moment, lots of crashes, 
but better than the last time I checked.


it is necessary to compile in x86_64 because the packages provided by qt 
only seem to include the x86_64 version of qt.


compiling for x86_64 works nearly perfect now, I needed to comment out 
one function that does not seem to exist on x86_64:


Index: lcl/include/sysenvapis_mac.inc
===
--- lcl/include/sysenvapis_mac.inc(revision 45676)
+++ lcl/include/sysenvapis_mac.inc(working copy)
@@ -11,7 +11,7 @@
   url := CFURLCreateWithBytes(nil, @AURL[1], Length(AURL), 
kCFStringEncodingUTF8, nil);

   if not Assigned(url) then
 Exit(False);
-  Result := LSOpenCFURLRef(url, nil) = 0;
+//  Result := LSOpenCFURLRef(url, nil) = 0;
   CFRelease(url);
 end;

I am testing now for stability issues, so far no major problems (but I 
am only using a small part of lazarus)


Am 18.04.14 16:30, schrieb Michael Ring:
Yes, it worked like a charm, super crisp fonts, now the fonts look 
pretty ugly, they are still anti-aliased but resolution is not as high 
as before.


Will create a bug for this, thank you for your answer.

Michael

Am 17.04.14 17:23, schrieb Joost van der Sluis:

On 09/04/14 10:00, Michael Ring wrote:

I realized a few weeks ago that fonts inside of lazarus started to look
ugly again on my Macbook Pro Retina, it seems that even though the App
has the retina flag set the fonts are rendered in 1920x1080 (My screen
resolution) and do not look smooth anymore.


But it did work in the past? Maybe you can confirm that by 
re-installing an older version again.


And if no-one here answers, the best thing to do is to open a 
bug-report. So that this will not be forgotten.


Joost.


--
___
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




--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] App crash at TScreen.GetCustomFormsZOrdered

[Petr Hlozek]

>> I added to all autocreated and used form into OnDestroy what you've
>> writen to me, in Project -> Option -> Debugging checked the -gh
>> option, Run -> Ru parameters in Environment tab added  HEAPTRC
>> variable.
>>
>> After the crash, the callstack window shows
>>
>> #0 HEAPTRC_TRACEFREEMEMSIZE$POINTER$QWORD$$QWORD at :0
>
> This could mean that you double free an object/record.
> Make sure all references become nil when an object is freed.

I'd like to do that and hopefuly already did but the app is quite big
and I'm not sure fo 100%. Is there any way how to find out with any
utility?

>> When I click to View source, it jumps to the top of the heaptrc unit.
> If there are other lines (not #0, but #1, #2, ...) click on them.

There is only #1 line with this:
#1 ?? at :0

Nothing more.

>> When I run the app from terminal with environment variable set, I got this:
>>
>> An unhandled exception occurred at $0044139A :
>> EAccessViolation :
>>   $0044139A
>>   $005DDD29
>>
>> The same like before :(
>
> Something destroys your heap.
> Have you tried gdb?
>
> Heaptrc has some more options.

I trid also gdb but I'm not so keen with it. When I tried bt after it
crashed, I got this:

Program received signal SIGSEGV, Segmentation fault.
0x0044139a in HEAPTRC_TRACEFREEMEMSIZE$POINTER$QWORD$$QWORD ()
(gdb) bt
#0  0x0044139a in HEAPTRC_TRACEFREEMEMSIZE$POINTER$QWORD$$QWORD ()
#1  0x in ?? ()
(gdb)

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?

[Michael Schnell]

On 06/27/2014 03:07 PM, Mattias Gaertner wrote:


... or simply do it without TThread.Queue, which is not complicated,
is LCL compatible and works with fpc 2.6.2+.
Only argument: You fear it is more overhead. The only overhead I see is
an extra critical section, which is negligible when your granularity
is milliseconds.

As I already pointed out this would include creating an second event 
queue and take care of OS-based waiting and waking the main thread for 
both queues, as with this I can't use the timeout parameter of 
ChechSynchronize().


-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] App crash at TScreen.GetCustomFormsZOrdered

[Mattias Gaertner]

On Fri, 27 Jun 2014 14:48:31 +0200
Petr Hlozek  wrote:

> Thank you for the help!
> 
> I added to all autocreated and used form into OnDestroy what you've
> writen to me, in Project -> Option -> Debugging checked the -gh
> option, Run -> Ru parameters in Environment tab added  HEAPTRC
> variable.
> 
> After the crash, the callstack window shows
> 
> #0 HEAPTRC_TRACEFREEMEMSIZE$POINTER$QWORD$$QWORD at :0

This could mean that you double free an object/record.
Make sure all references become nil when an object is freed.

 
> When I click to View source, it jumps to the top of the heaptrc unit.

If there are other lines (not #0, but #1, #2, ...) click on them.

 
> When I run the app from terminal with environment variable set, I got this:
> 
> An unhandled exception occurred at $0044139A :
> EAccessViolation :
>   $0044139A
>   $005DDD29
> 
> The same like before :(

Something destroys your heap.
Have you tried gdb?

Heaptrc has some more options.

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] PoChecker possible cosmetical patch

[Mattias Gaertner]

On Fri, 27 Jun 2014 13:09:06 +0200
Václav Valíček  wrote:

> I prefer using dxGetText in my projects, but if Lazarus uses 
> resourcestrings, I must use resourcestrings when translating components. 
> I have experience with delphi 2010 translations (probbably same as 
> D2009) - and I wasn't very happy that I had to attach special 
> translation files, I wanted something text based. I started using 
> dxGetText... There is no problem for me if Lazarus does not translate 
> consts arrays during startup.

po files are text based.
There is a binary format: mo files, which saves some bytes. But those
few KB do not matter nowadays. 
Of course you can use other ways to load your resourcestrings. You
don't need to use po files.

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?

[Mattias Gaertner]

On Fri, 27 Jun 2014 12:24:02 +0200
Michael Schnell  wrote:

>[...]
>   - we can't create full compatibility to how Application.QueuAsnyCall 
> works with other Widget Types, as TThread.Queue, when called from the 
> main Thread, does not queue the call but preforms the call right away.
> 
> Unfortunately this is even true if you do TThread.Queue with a fake self 
> pointer, as it internally checks using GetCurrentThread.
> 
> Hence we would need a modification to the RTL for full compatibility.

... or simply do it without TThread.Queue, which is not complicated,
is LCL compatible and works with fpc 2.6.2+.
Only argument: You fear it is more overhead. The only overhead I see is
an extra critical section, which is negligible when your granularity
is milliseconds.

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] App crash at TScreen.GetCustomFormsZOrdered

[Petr Hlozek]

Thank you for the help!

I added to all autocreated and used form into OnDestroy what you've
writen to me, in Project -> Option -> Debugging checked the -gh
option, Run -> Ru parameters in Environment tab added  HEAPTRC
variable.

After the crash, the callstack window shows

#0 HEAPTRC_TRACEFREEMEMSIZE$POINTER$QWORD$$QWORD at :0

When I click to View source, it jumps to the top of the heaptrc unit.

When I run the app from terminal with environment variable set, I got this:

An unhandled exception occurred at $0044139A :
EAccessViolation :
  $0044139A
  $005DDD29

The same like before :(

Petr


2014-06-27 11:55 GMT+02:00 Mattias Gaertner :
> On Fri, 27 Jun 2014 11:33:53 +0200
> Petr Hlozek  wrote:
>
>> Hi,
>>
>> I have an Linux app, it has over 76k lines of code, 78 Forms and uses 
>> threads.
>> After I close the app, it always crashes in
>>
>> function TScreen.GetCustomFormsZOrdered(Index: Integer): TCustomForm;
>> begin
>>   Result := TCustomForm(FCustomFormsZOrdered[Index]);
>> end;
>>
>> The index variable value is something like 42325 or so.
>>
>> I tried to debug and here is what I found out:
>>
>> It goes through all FormCloseQuesry, FormDestroy and
>> DatamoduleDestory, then it goes to
>> TApplication.DoBeforeFinalization and then into
>> TScreen..GetCustomFormsZOrdered where it fails.
>> I spent days trying to find out where could be the problem but didn't
>> find anything. I'm lost. Do you have any idea where could be a
>> problem, please? Thanks a lot!
>
> Maybe some event uses an already freed object.
> Set all references to nil, when freeing objects. For example in
> TForm1.FormDestroy add Form1:=nil;
>
> And compile with -gh.
>
> Then you can run your program with environment variable
> HEAPTRC=keepreleased
>
>
> Mattias
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus



-- 
http://HamQTH.com/ok2cqr
http://ok2cqr.com
http://cqrlog.com
http://cqrtest.com

--
___
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?

[Marco van de Voort]

On Fri, Jun 27, 2014 at 11:50:18AM +0200, Giuliano Colla wrote:
> >> This is not compatible with other implementations, such as Kylix and
> >> fgGui, just to mention two.
> > It is compatible with Kylix, since in CLX QT is hardcoded too afaik?!!?
> 
> You're right, in Kylix CLX Qt is hardcoded. Therefore it's different 
> from LCL scheme virtual/abstract - interface.

It's the same in the fact that you can't reappropiate the designer to non
built-in  CL(X) libraries.

You can only use the designer with the built-in library, at best with a
different backend wacked under it.

But it is clear, this is about customized designer support. The "widget"
stuff talk put me of course (I actually realised a bit later)

> This makes it impossible to use the features of IDE Designer as it is 
> for a Kylix project.

True, but the incompatible threw me off, and the perspective on what
incompatible with Kylix means.

I never considered loading unmodified CLX projects a Lazarus designgoal.
More so because the last Kylix is already a decade old.

OTOH I have nothing against it. (I'm a bit careful with dragging fpgui in
it, since contrary to CLX, its persistence mechanisms and principles might
be different)

> If, with some kludges, you manage to use the IDE designer as it is, for 
> a Kylix project, it will only be aware of LCL methods and properties, 
> and you'll end up both with Kylix unsupported methods and properties, 
> and with Kylix required methods and properties dropped because 
> unsupported by LCL.

True.
 
> This sums up in being incompatible.

That is IMHO an unfortunate choice of words. It is not a general purpose
designer. It is not incompatible because it never strove to be. 

Anyway, all is clear now. At least it made me realize you meant reusing the
current designer for CLX and not add a different one. That might indeed be
doable since CLX inherits many of VCL/LCL's traits.


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] PoChecker possible cosmetical patch

[Václav Valíček]

I prefer using dxGetText in my projects, but if Lazarus uses 
resourcestrings, I must use resourcestrings when translating components. 
I have experience with delphi 2010 translations (probbably same as 
D2009) - and I wasn't very happy that I had to attach special 
translation files, I wanted something text based. I started using 
dxGetText... There is no problem for me if Lazarus does not translate 
consts arrays during startup.


Václav Valíček
vac...@valicek.name

Dne 27.6.2014 11:07, Marco van de Voort napsal(a):

On Fri, Jun 20, 2014 at 06:52:53AM +0200, Sven Barth wrote:

+  sCheckMissingIdentifiers,
+  sCheckForMismatchesInUntranslatedStrings,
+  sCheckForDuplicateUntranslatedValues,
+  sCheckStatistics,
+  sFindAllTranslatedPoFiles
  );

ok. That's reduces some redudancy. They are not translated though. You
must replace the array with a function for that.

There was a bug report some time ago that Delphi *does* indeed translate
such strings. AFAIK that was fixed, but I'll need to check that and in
which version.

I can confirm that D2009+ translates resourcestrings in aggregate CONST 
structures
using its own (ITE, resource DLL) translation systems.  I ran into this when
I switched to dxgettext, and I had to add this manually.

I've no experience with translations in pre D2009. (one of the reasons to
upgrade our D7 was that we needed to start with translation, with non Latin
scripts a possibility oto)

--
___
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] nonlcl basic issue: is codetools LCL dependent?

[Michael Schnell]

On 06/27/2014 11:56 AM, Hans-Peter Diettrich wrote:


Any time source is applicable with this model. The ticks (or even 
longer intervals) can be deliverd by callbacks, messages...


We have multiple TTimers that need to be driven by a singe Time source. 
Hence the necessary userspace / syrtemspace are not equidistant in time.


-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?

[Michael Schnell]

On 06/27/2014 10:35 AM, Michael Schnell wrote:



For doing a "Patch" to the LCL, some more prerequisites are needed:
 - do we want something at all if it is not usable with the "released" 
version of fpc (see discussion in fpc-devel)

...


Addition:
 - we can't create full compatibility to how Application.QueuAsnyCall 
works with other Widget Types, as TThread.Queue, when called from the 
main Thread, does not queue the call but preforms the call right away.


Unfortunately this is even true if you do TThread.Queue with a fake self 
pointer, as it internally checks using GetCurrentThread.


Hence we would need a modification to the RTL for full compatibility.

-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?

[Michael Schnell]

On 06/26/2014 02:54 PM, Michael Schnell wrote:



Maybe this is not fully compatible with Application.QueueAsyncCall (if 
same is called in the main thread), which I did implement using 
TThread.Queue.
I checked the code of TThread.Queue and in fact it does not queue the 
call if TThread.Queue is executed from the main thread, but performs the 
call right away.


This supposedly is not compatible with how Application.QueueAsyncCall 
works in other WidgetTypes.


Unfortunately the svn-version of the rtl does not provide a means to 
prevent this (queer, Delphi compatible) behavior.


So for full compatibility we would need an enhancement in the fpc-rtl.

(I'm going to post this in fpc-develop, as well.)

-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?

[Hans-Peter Diettrich]

Michael Schnell schrieb:

On 06/27/2014 03:19 AM, Hans-Peter Diettrich wrote:
 Every clock tick increments the internal clock, and triggers all 
events...


This is exactly what I want to avoid.


Any time source is applicable with this model. The ticks (or even longer 
intervals) can be deliverd by callbacks, messages...


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?

[Michael Schnell]

On 06/27/2014 11:35 AM, Mattias Gaertner wrote:

In case of nogui there is no library, so you have the full control.
I need to do a system call to have the program wait and do another 
system call to wake it. I understand that this is "library dependent".

Not quiet.


OK. Not _necessarily_. But this is a decent use of it.

Have you actual numbers of the overhead that you fear so much? 

In any case, it's better to avoid if, if possible.


Same for the other widgetsets. Except for nogui.


In fact the GUI enabled, non-Windows Widget Types do implement an event 
Queue in pascal code.AFAIK, this is necessary because the external 
Widget Sets do callbacks that need to be queued until the program is 
able to handle them (while in Windows the messages are queued anyway).


Hence there it would be "nice" (and IMHO possible) not to have a dual 
queue (one in the RTL, one in the LCL), but a central one..


But of course I do not really vote for taking the huge effort to modify 
the current status quo.


-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] App crash at TScreen.GetCustomFormsZOrdered

[Mattias Gaertner]

On Fri, 27 Jun 2014 11:33:53 +0200
Petr Hlozek  wrote:

> Hi,
> 
> I have an Linux app, it has over 76k lines of code, 78 Forms and uses threads.
> After I close the app, it always crashes in
> 
> function TScreen.GetCustomFormsZOrdered(Index: Integer): TCustomForm;
> begin
>   Result := TCustomForm(FCustomFormsZOrdered[Index]);
> end;
> 
> The index variable value is something like 42325 or so.
>
> I tried to debug and here is what I found out:
> 
> It goes through all FormCloseQuesry, FormDestroy and
> DatamoduleDestory, then it goes to
> TApplication.DoBeforeFinalization and then into
> TScreen..GetCustomFormsZOrdered where it fails.
> I spent days trying to find out where could be the problem but didn't
> find anything. I'm lost. Do you have any idea where could be a
> problem, please? Thanks a lot!

Maybe some event uses an already freed object.
Set all references to nil, when freeing objects. For example in
TForm1.FormDestroy add Form1:=nil;

And compile with -gh.

Then you can run your program with environment variable
HEAPTRC=keepreleased


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?

[Giuliano Colla]

Il 27/06/2014 11:09, Marco van de Voort ha scritto:

On Mon, Jun 23, 2014 at 11:48:53AM +0200, Giuliano Colla wrote:

implementation part is demanded to some third party Widgetset (such as
gtk, qt, Windows, etc.), via an Interfaces unit.
This is not compatible with other implementations, such as Kylix and
fgGui, just to mention two.

It is compatible with Kylix, since in CLX QT is hardcoded too afaik?!!?


You're right, in Kylix CLX Qt is hardcoded. Therefore it's different 
from LCL scheme virtual/abstract - interface.
This makes it impossible to use the features of IDE Designer as it is 
for a Kylix project.
LCL scheme makes it possible to use different widgetsets at design time 
and at run time, but requires that all of them follow the same rule of 
virtual/abstract+Interface. Moreover IDE designer defaults to LCL 
classes properties and methods, and doesn't allow duplicates.If a Kylix 
class has the same name of an LCL class, you'll be unable to design. 
TForm is the first one!


If, with some kludges, you manage to use the IDE designer as it is, for 
a Kylix project, it will only be aware of LCL methods and properties, 
and you'll end up both with Kylix unsupported methods and properties, 
and with Kylix required methods and properties dropped because 
unsupported by LCL.


This sums up in being incompatible.

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?

[Mattias Gaertner]

On Fri, 27 Jun 2014 11:09:41 +0200
Marco van de Voort  wrote:

> On Mon, Jun 23, 2014 at 11:48:53AM +0200, Giuliano Colla wrote:
> > implementation part is demanded to some third party Widgetset (such as 
> > gtk, qt, Windows, etc.), via an Interfaces unit.
> > This is not compatible with other implementations, such as Kylix and 
> > fgGui, just to mention two.
> 
> It is compatible with Kylix, since in CLX QT is hardcoded too afaik?!!?

He meant, you cannot use CLX and LCL in an application at the same
time. Same with fpgui.

You can either port your CLX application to the LCL or you can extend
the IDE designer to support CLX applications. And when the IDE can
support CLX, then it is a small step to support fpgui as well.
Maybe msegui too, but that uses a different FCL, so maybe that needs
some more support.

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?

[Mattias Gaertner]

On Fri, 27 Jun 2014 10:35:28 +0200
Michael Schnell  wrote:

>[...]
> > So? Program a queue.
> 
> IMHO this is not appropriate.
> 
> There already is a queue in the RTL that needs to be handled, as same is 
> fed by TThread.Synchonize (and TThread.Queue) user accessible functions.
> Hence an additional queue would need merging the queue outputs and 
> handling the waiting and waking for both Queues simultaneously. This 
> (waiting and waking regarding the additional queue) needs arch depending 
> code (as done in the GUI based Widget Types).

That's not arch dependent, but library dependent.
In case of nogui there is no library, so you have the full control.


> But the NoGUI Widget Type 
> is done for small embedded projects. 

Not quiet. The nogui widgettype is for LCL applications running without
GUI. This can be a daemon or console tool.
Because the LCLBase is not optimized for smart linking it pulls in a lot
of stuff and it is not good for small embedded projects.


> here arch-independence, low latency and low processor demand is critical.

Have you actual numbers of the overhead that you fear so much?

 
> >> They implement a second queue besides the one the RTL implements for
> >> TThread.
> > Probably they have several.
> 
> IMHO it is not a very nice concept to merge queue outputs. This of 
> course has historical reasons with the existing GUI based widgets sets.
> 
> IMHO it would be better top merge the queue inputs and hence waiting and 
> waking is central.
> 
> (A concept to do this would be a central Event Queue implementation in 
> the RTL that always is used by the LCL Widget sets. Of course with the 
> Windows widget set this technically can't be done, as you need to use 
> the OS Message Queue.

Same for the other widgetsets. Except for nogui.


Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] App crash at TScreen.GetCustomFormsZOrdered

[Petr Hlozek]

Hi,

I have an Linux app, it has over 76k lines of code, 78 Forms and uses threads.
After I close the app, it always crashes in

function TScreen.GetCustomFormsZOrdered(Index: Integer): TCustomForm;
begin
  Result := TCustomForm(FCustomFormsZOrdered[Index]);
end;

The index variable value is something like 42325 or so.
I tried to debug and here is what I found out:

It goes through all FormCloseQuesry, FormDestroy and
DatamoduleDestory, then it goes to
TApplication.DoBeforeFinalization and then into
TScreen..GetCustomFormsZOrdered where it fails.
I spent days trying to find out where could be the problem but didn't
find anything. I'm lost. Do you have any idea where could be a
problem, please? Thanks a lot!

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?

[Michael Schnell]

On 06/27/2014 11:08 AM, Mattias Gaertner wrote:


Yes, please.

I'll do some cleaning up and send you the source code.

-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?

[Marco van de Voort]

On Wed, Jun 25, 2014 at 04:46:08PM +0200, Mattias Gaertner wrote:
> > Thanks for the Clarification.
> > 
> > I seem to remember that with Delphi the Term RuntimPackage had been used 
> > the way I did and was not aware that with Lazarus this is different.
> 
> Both Delphi designtime and runtime packages are dynamic libs.

Well, the only reason to deliver the runtime stuff in package form is 
if you really support building the end application with packages. (which is
sometimes further complicated by letting the designtime package depend on
the runtime one) Otherwise DCU's are simply put in the path.

Strictly speaking a Delphi package is not always dynamic (.dcp, see
http://wiki.freepascal.org/packages). Comparable with a .a and an archive of
.ppu's for FPC I guess.



--
___
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?

[Marco van de Voort]

On Mon, Jun 23, 2014 at 11:48:53AM +0200, Giuliano Colla wrote:
> implementation part is demanded to some third party Widgetset (such as 
> gtk, qt, Windows, etc.), via an Interfaces unit.
> This is not compatible with other implementations, such as Kylix and 
> fgGui, just to mention two.

It is compatible with Kylix, since in CLX QT is hardcoded too afaik?!!?

--
___
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?

[Mattias Gaertner]

On Fri, 27 Jun 2014 10:35:28 +0200
Michael Schnell  wrote:

> On 06/26/2014 07:38 PM, Mattias Gaertner wrote:
> >
> > If you mean for TTimer: Yes, I'm waiting for your patch.
> Meaning what ?
> 
> I can send you a testing application (that does nit use the LCL but just 
> fpc) if you just want to see it working.

Yes, please.

 
> For doing a "Patch" to the LCL, some more prerequisites are needed:
>   - do we want something at all if it is not usable with the "released" 
> version of fpc (see discussion in fpc-devel)

Yes. Many features started with $IFs. You just have to document the
requirements. For example on the wiki page for the nogui widgetset.


>   - can we do an extension to the current "noGUI" Widget Type
> .  - here: do we want to add a "sub-WidgetType) similar to 
> "fpGUIPlatform") to allow for selecting old and the new behavior so that 
> no incompatibility problems can come up.
>   -  or do we need a completely new Widget Type "AciveNoGUI", preventing 
> any incompatibility problems for current noGUI users.

Small differences are done with IFDEF EnableSomeFeature or IFNDEF
DisableSomeFeature.


> .  - here the IDE somehow needs to know about this I have no Idea how to 
> implement this.

It is possible to register flags, but normally we only document them
and programmers use them when needed. Most flags are for special cases,
which would confuse the majority of users.

Mattias

--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] PoChecker possible cosmetical patch

[Marco van de Voort]

On Fri, Jun 20, 2014 at 06:52:53AM +0200, Sven Barth wrote:
> > > +  sCheckMissingIdentifiers,
> > > +  sCheckForMismatchesInUntranslatedStrings,
> > > +  sCheckForDuplicateUntranslatedValues,
> > > +  sCheckStatistics,
> > > +  sFindAllTranslatedPoFiles
> > >  );
> >
> > ok. That's reduces some redudancy. They are not translated though. You
> > must replace the array with a function for that.
> 
> There was a bug report some time ago that Delphi *does* indeed translate
> such strings. AFAIK that was fixed, but I'll need to check that and in
> which version.

I can confirm that D2009+ translates resourcestrings in aggregate CONST 
structures
using its own (ITE, resource DLL) translation systems.  I ran into this when
I switched to dxgettext, and I had to add this manually.

I've no experience with translations in pre D2009. (one of the reasons to
upgrade our D7 was that we needed to start with translation, with non Latin
scripts a possibility oto)

--
___
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?

[Michael Schnell]

On 06/26/2014 05:16 PM, Sven Barth wrote:


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.



Yep.

As discussed in fpc-devel, I could use $IFs that just switch of the 
functionality (and issue some kind of error indicator) when compiled 
against an older fpc rtl.


-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?

[Michael Schnell]

On 06/27/2014 03:19 AM, Hans-Peter Diettrich wrote:
 Every clock tick increments the internal clock, and triggers all 
events...


This is exactly what I want to avoid.

Each active clock tick needs a system-mode / user-mode and back 
transition. But the NoGUI Widget Type is done for small embedded 
projects. here arch-independence, low latency and low processor demand 
is critical. Hence I want to avoid any unnecessary system calls (that do 
not result in calling any user-code event).


-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?

[Michael Schnell]

On 06/26/2014 07:38 PM, Mattias Gaertner wrote:


If you mean for TTimer: Yes, I'm waiting for your patch.

Meaning what ?

I can send you a testing application (that does nit use the LCL but just 
fpc) if you just want to see it working.


For doing a "Patch" to the LCL, some more prerequisites are needed:
 - do we want something at all if it is not usable with the "released" 
version of fpc (see discussion in fpc-devel)

 - can we do an extension to the current "noGUI" Widget Type
.  - here: do we want to add a "sub-WidgetType) similar to 
"fpGUIPlatform") to allow for selecting old and the new behavior so that 
no incompatibility problems can come up.
 -  or do we need a completely new Widget Type "AciveNoGUI", preventing 
any incompatibility problems for current noGUI users.
.  - here the IDE somehow needs to know about this I have no Idea how to 
implement this.



So? Program a queue.


IMHO this is not appropriate.

There already is a queue in the RTL that needs to be handled, as same is 
fed by TThread.Synchonize (and TThread.Queue) user accessible functions.
Hence an additional queue would need merging the queue outputs and 
handling the waiting and waking for both Queues simultaneously. This 
(waiting and waking regarding the additional queue) needs arch depending 
code (as done in the GUI based Widget Types). But the NoGUI Widget Type 
is done for small embedded projects. here arch-independence, low latency 
and low processor demand is critical.



They implement a second queue besides the one the RTL implements for
TThread.

Probably they have several.


IMHO it is not a very nice concept to merge queue outputs. This of 
course has historical reasons with the existing GUI based widgets sets.


IMHO it would be better top merge the queue inputs and hence waiting and 
waking is central.


(A concept to do this would be a central Event Queue implementation in 
the RTL that always is used by the LCL Widget sets. Of course with the 
Windows widget set this technically can't be done, as you need to use 
the OS Message Queue. To provide for this, the RTL's Queue would need to 
allow for overriding the appropriate input and output functions to allow 
for using a (single) external queue such as the Windows message queue.


Ok. You have the tools, you have a proof of concept, now program it 
and create a patch.


Of course I am happily up to do that :-) .

-Michael


--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus