Re: [Lazarus] WriteLn back to the GUI

[Sven Barth]

Am 26.10.2013 02:30 schrieb "ListMember" :
>
> On 2013-10-25 14:53, Sven Barth wrote:
>
>> In my opinion that energy is better put into getting e.g. fcl-passrc up
to date and keep it that way (so that at least each release can handle code
that the compiler also accepts).
>
>
> You're, of course, right.
>
> But, never mind the question of which part of what team will maintain it
(and what triggers a maintenance request, other than a long after-the-fact
bug report), how do you make sure that --at any moment in time-- fcl-passrc
is up-to-date?
>

The main

> I mean, suppose --using fcl-passrc-- we went through all the publicly
available code (repositories of FPC, Lazarus, etc.) and it reported no
errors, would it prove/guarantee that fcl-passrc is up-to-date?
>
> If we could say that with enouh conjfidence, I'd gladly shift my focus to
fcl-passrc.
>
>
>> I already had the idea with DLLs once myself.
>>
>> As long as the interface for exchanging options (and maybe also unit
locations ;) )is kept stable or at least backwards compatible this should
work. And as long as the heaps are kept seperate unloading a compiler
library should also solve the problem with memory leaks... (maybe add a
function to the API to get the current heap state ^^)
>>
>
> Naturally  I know nothing about the importance of heap especially in
this context or probbaly in any relevant context.
>
> How hard would it be?
>
>
> --
> ___
> 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] WriteLn back to the GUI

[Sven Barth]

Sorry, pressed Send by accident... -.*

Am 26.10.2013 02:30 schrieb "ListMember" :
>
> On 2013-10-25 14:53, Sven Barth wrote:
>
>> In my opinion that energy is better put into getting e.g. fcl-passrc up
to date and keep it that way (so that at least each release can handle code
that the compiler also accepts).
>
>
> You're, of course, right.
>
> But, never mind the question of which part of what team will maintain it
(and what triggers a maintenance request, other than a long after-the-fact
bug report), how do you make sure that --at any moment in time-- fcl-passrc
is up-to-date?
>
> I mean, suppose --using fcl-passrc-- we went through all the publicly
available code (repositories of FPC, Lazarus, etc.) and it reported no
errors, would it prove/guarantee that fcl-passrc is up-to-date?
>
> If we could say that with enouh conjfidence, I'd gladly shift my focus to
fcl-passrc.
>

The main tests for what FPC supports and what not is for one compiling (or
in this context at least "parsing") the compiler's source, the RTL and the
packages. Additionally there are the tests which should either succeed or
dail to compile/run (and when a new feature is added at least one test is
added). So in my opinion the ability to correctly parse compiler, RTL and
packages sources plus correctly parsing all tests that should compile and
failing all tests that should fail would be enough in my opinion.

The main maintenance would be by the FPC team, but patches are welcome and
if someone (e.g. you) "proves worthy" he can get SVN write to the
fcl-passrc directory.

>
>> I already had the idea with DLLs once myself.
>>
>> As long as the interface for exchanging options (and maybe also unit
locations ;) )is kept stable or at least backwards compatible this should
work. And as long as the heaps are kept seperate unloading a compiler
library should also solve the problem with memory leaks... (maybe add a
function to the API to get the current heap state ^^)
>>
>
> Naturally  I know nothing about the importance of heap especially in
this context or probbaly in any relevant context.
>
> How hard would it be?

As non-shared heap is the default, this would be no problem ^^

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

Re: [Lazarus] Can't compile Lazarus on Linux Mint 15

[Ludo Brands]

On 10/25/2013 06:10 PM, Reimar Grabowski wrote:
> On Thu, 24 Oct 2013 11:26:26 -0200
> silvioprog  wrote:
> 
>> Thank guys, but, same problem:
> +1
> 
> R.
> 

According to
http://upstream-tracker.org/compat_reports/cairo/1.9.14_to_1.10.0/abi_compat_report.html
the cairo_gobject_* functions where introduced in libcairo-gobject.so
and were never in libcairo.so. The change in rev 25766 tries to find
these functions in libcairo.so. I updated
http://bugs.freepascal.org/view.php?id=25191 with the same info.

Ludo

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

Re: [Lazarus] WriteLn back to the GUI

[ListMember]

On 2013-10-26 11:45, Sven Barth wrote:
> If we could say that with enouh conjfidence, I'd gladly shift my 
focus to fcl-passrc.


The main tests for what FPC supports and what not is for one compiling 
(or in this context at least "parsing") the compiler's source, the RTL 
and the packages. Additionally there are the tests which should either 
succeed or dail to compile/run (and when a new feature is added at 
least one test is added). So in my opinion the ability to correctly 
parse compiler, RTL and packages sources plus correctly parsing all 
tests that should compile and failing all tests that should fail would 
be enough in my opinion.




OK, then. I'll take a look at that one. Thanks.

> Naturally  I know nothing about the importance of heap especially 
in this context or probbaly in any relevant context.


> How hard would it be?

As non-shared heap is the default, this would be no problem ^^



I am having difficulty interpreting '^^'.
What is it meant to mean?

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

Re: [Lazarus] Designer aligment tool

[FreeMan]

Hello,
"Align..." and other menu items is disable on TDatamodule. My idea maybe 
"Scale" and "Size" can disable. I put to many non visual components on 
TDatamodule, but not orginized. On object inspecter has no left and top 
properties ,this is normal(In lfm file has it). for orginize component's 
icon view, user have to move via mouse one by one.  Aligment and other 
tool can do this.

Thank you

08-10-2013 12:06 tarihinde, Mattias Gaertner yazdı:

On Mon, 07 Oct 2013 13:47:12 +0300
FreeMan  wrote:


Hello,
Kubuntu x64 13.04
last svn fpc & lazarus.

Select 2(or more) visual component on form, via shift + Left click or
while clicking move mouse and select.  Showing Square dots for selected
components. Rigth click and popup menu open, click "align", open
Aligment window then select "Left sides" from "Horizontal" group, then
click ok. All component's left set to selected square's left position.
this is wrong, 'cos I wanna set selected components position to what I
selected "first" component's position. "right sides" etc. as well

That would be confusing with rectangle selection. So, it should check
if the user selected the first components separately.

  

And my  other suggesstion on slection, first (mean master) components
dot colors be Red, so I can easly see master components are.

+1

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] Graeme would love this, or not, I think

[Marco van de Voort]

On Sun, Oct 20, 2013 at 12:22:50PM +0200, Hans-Peter Diettrich wrote:
> > Either your students were different, or that is very optimistic :)
> 
> Yes, I was thinking of IT students. Sorry for that :-(

Sadly enough they were, though not the highest level (aimed for bachelor as
end-diploma).  But since it was their first weeks at the school, one could
consider them secondary school students still. Extremely playful, and
interested in anything but work.

 
> > In this class, all this simply ate too much time, and even after students
> > were ackward with it. And it was only 9 x 1.5 hr, then an hour is still too
> > much.
> 
> Then a good ole homecomputer (C64 emulator...) would be more useful ;-)

Same problem as with an Dos emulator for TP. Concepts too alien, install
troubles etc.

I was actually flabbergasted by how little pre existing knowledge/experience
the avg student understood of the console concept. And that was in 2005-7,
now it will be even less.

> > Delphi on the other hand invited too much play.
> 
> This energy could be used in extra (voluntary) courses, where the 
> interested can learn more about using Delphi.

This energy does not exist outside mandatory classes :-)
 
> > The ideal usage IMHO would be a stripped lazarus/Delphi without designer,
> > and some skeleton application under "new" that instantiates a skeleton GUI
> > app (delivered in .ppu), and the students can use procedures from their
> > programs to use the skeleton units.
> 
> In your timeframe (9*1.5 hrs) I wouldn't address GUI programs at all.

I don't, that is exactly the point. But I would have wanted something the
students recognized as an IDE (read GUI app) that is hardwired to generate a
visual app, without iniviting students to do things beyond their assignment.

Later, when they are properly potty-trained they can still graduate 

 Even if that is only an
inmutable skeleton with a memo for input and output.

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

Re: [Lazarus] WriteLn back to the GUI

[Sven Barth]

Am 26.10.2013 11:48 schrieb "ListMember" :
>> > Naturally  I know nothing about the importance of heap especially
in this context or probbaly in any relevant context.
>>
>> > How hard would it be?
>>
>> As non-shared heap is the default, this would be no problem ^^
>>
>
> I am having difficulty interpreting '^^'.
> What is it meant to mean?

It's a Japanese emoticon for ":)". They do it vertically instead of
horizontally and often I prefer those ;)
See also: http://en.m.wikipedia.org/wiki/Kaomoji

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

Re: [Lazarus] WriteLn back to the GUI

[Sven Barth]

Am 26.10.2013 11:48 schrieb "ListMember" :
>
> On 2013-10-26 11:45, Sven Barth wrote:
>>
>> > If we could say that with enouh conjfidence, I'd gladly shift my focus
to fcl-passrc.
>>
>> The main tests for what FPC supports and what not is for one compiling
(or in this context at least "parsing") the compiler's source, the RTL and
the packages. Additionally there are the tests which should either succeed
or dail to compile/run (and when a new feature is added at least one test
is added). So in my opinion the ability to correctly parse compiler, RTL
and packages sources plus correctly parsing all tests that should compile
and failing all tests that should fail would be enough in my opinion.
>>
>
> OK, then. I'll take a look at that one. Thanks.

And of course additional tests can be added and maybe we'll also need to
mark some tests as "parses, but fails to compile" (e.g. to test linker
errors, semantic errors or whatever).
Additionally one could try to make fcl-passrc a fragmentary parser so that
it could be used for an IDE like Lazarus as well (code depublication) or
for a Pascal script engine (I know there are already DWScript and
PascalScript).

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

Re: [Lazarus] WriteLn back to the GUI

[ListMember]

On 2013-10-26 14:43, Sven Barth wrote:


> I am having difficulty interpreting '^^'.
> What is it meant to mean?

It's a Japanese emoticon for ":)". They do it vertically instead of 
horizontally and often I prefer those ;)

See also: http://en.m.wikipedia.org/wiki/Kaomoji



Not in a million years would I have guessed it right.

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

Re: [Lazarus] Can't compile Lazarus on Linux Mint 15

[Junior]

I use libcairo-gobject2  version: 1.10.2-6.1

Always worked perfect.

Lazarus trunk and FPC 2.6.2


Em 26-10-2013 05:57, Ludo Brands escreveu:

On 10/25/2013 06:10 PM, Reimar Grabowski wrote:

On Thu, 24 Oct 2013 11:26:26 -0200
silvioprog  wrote:


Thank guys, but, same problem:

+1

R.


According to
http://upstream-tracker.org/compat_reports/cairo/1.9.14_to_1.10.0/abi_compat_report.html
the cairo_gobject_* functions where introduced in libcairo-gobject.so
and were never in libcairo.so. The change in rev 25766 tries to find
these functions in libcairo.so. I updated
http://bugs.freepascal.org/view.php?id=25191 with the same info.

Ludo

--
___
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] Graeme would love this, or not, I think

[Hans-Peter Diettrich]

Marco van de Voort schrieb:


In this class, all this simply ate too much time, and even after students
were ackward with it. And it was only 9 x 1.5 hr, then an hour is still too
much.

Then a good ole homecomputer (C64 emulator...) would be more useful ;-)


Same problem as with an Dos emulator for TP. Concepts too alien, install
troubles etc.


Problems are quite different. A full DOS emulator includes a lot of low 
level stuff (running real-mode programs, disk formatting, 
networking...), that is not required for program development. A C64 or 
similar emulator can use virtual devices instead, interprets also the 
programs to run, and screen output is simple with a (fixed size) paintbox.


My experience with development systems also suggests an installation in 
a virtual machine. VM software installation is extremely simple, 
compared to an FPC/Lazarus installation and configuration, and a single 
VM can contain a fully installed and configured development system, 
ready for educational use. When somebody succeeded in breaking his 
system, a simple restore of the initial VM state allows to proceed 
normally within seconds (sandbox).


At the same time the students can learn about virtual machines 
(optional), which later also should be used in professional software 
development. A VM is insensitive to hardware replacement/upgrade, and 
allows continued use of a specific compiler version. See the persistent 
trouble with RadStudio installations, caused by upgrades of either 
Delphi or Windows - currently Win8.1 causes such trouble, and on Linux 
it will be ongoing GUI (gtk...) upgrades.


Plus a VM can be isolated perfectly from the real world, unreachable by 
NSA and other exploits and attacks (Merkel... ;-)




I was actually flabbergasted by how little pre existing knowledge/experience
the avg student understood of the console concept. And that was in 2005-7,
now it will be even less.


Nowadays cloud experience is more important than DOS experience. How 
many jobs will you find later, wich require DOS experience and coding, 
compared to the many jobs for writing (mobile) GUI and cloud applications?




Delphi on the other hand invited too much play.
This energy could be used in extra (voluntary) courses, where the 
interested can learn more about using Delphi.


This energy does not exist outside mandatory classes :-)


It exists, it's only a matter of motivation. Let the students suggest 
projects of *their* interest, then teach them the useful techniques for 
their projects - learning by doing can be mere fun :-)


DoDi


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

Re: [Lazarus] Graeme would love this, or not, I think

[Reinier Olislagers]

On 26/10/2013 16:52, Hans-Peter Diettrich wrote:
> Marco van de Voort schrieb:
> 
 In this class, all this simply ate too much time, and even after
 students
 were ackward with it. And it was only 9 x 1.5 hr, then an hour is
 still too
 much.
>>> Then a good ole homecomputer (C64 emulator...) would be more useful ;-)
>>
>> Same problem as with an Dos emulator for TP. Concepts too alien, install
>> troubles etc.
> 
> Problems are quite different. A full DOS emulator includes a lot of low
> level stuff (running real-mode programs, disk formatting,
> networking...), that is not required for program development. A C64 or
> similar emulator can use virtual devices instead, interprets also the
> programs to run, and screen output is simple with a (fixed size) paintbox.
> 
> My experience with development systems also suggests an installation in
> a virtual machine. VM software installation is extremely simple,
> compared to an FPC/Lazarus installation and configuration, and a single
> VM can contain a fully installed and configured development system,
> ready for educational use. When somebody succeeded in breaking his
> system, a simple restore of the initial VM state allows to proceed
> normally within seconds (sandbox).
> 
> At the same time the students can learn about virtual machines
> (optional), which later also should be used in professional software
> development. A VM is insensitive to hardware replacement/upgrade, and
> allows continued use of a specific compiler version. See the persistent
> trouble with RadStudio installations, caused by upgrades of either
> Delphi or Windows - currently Win8.1 causes such trouble, and on Linux
> it will be ongoing GUI (gtk...) upgrades.
> 
> Plus a VM can be isolated perfectly from the real world, unreachable by
> NSA and other exploits and attacks (Merkel... ;-)
> 
> 
>> I was actually flabbergasted by how little pre existing
>> knowledge/experience
>> the avg student understood of the console concept. And that was in
>> 2005-7,
>> now it will be even less.
> 
> Nowadays cloud experience is more important than DOS experience. How
> many jobs will you find later, wich require DOS experience and coding,
> compared to the many jobs for writing (mobile) GUI and cloud applications?
> 
> 
 Delphi on the other hand invited too much play.
>>> This energy could be used in extra (voluntary) courses, where the
>>> interested can learn more about using Delphi.
>>
>> This energy does not exist outside mandatory classes :-)
> 
> It exists, it's only a matter of motivation. Let the students suggest
> projects of *their* interest, then teach them the useful techniques for
> their projects - learning by doing can be mere fun :-)
> 
> DoDi
> 
> 
> -- 
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
> 


42

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

Re: [Lazarus] WriteLn back to the GUI

[ListMember]

On 2013-10-26 15:19, Sven Barth wrote:
And of course additional tests can be added and maybe we'll also need 
to mark some tests as "parses, but fails to compile" (e.g. to test 
linker errors, semantic errors or whatever).


Additionally one could try to make fcl-passrc a fragmentary parser so 
that it could be used for an IDE like Lazarus as well (code 
depublication) or for a Pascal script engine (I know there are already 
DWScript and PascalScript).




One of my main hope is to come up with a fast enough code formatter with 
the options that I need.


Reason is, I am self-destructively (time and/or productivity-wise) 
pedantic about the way code is formatted. And, I sometimes find myself 
manually formatting stuff irrespective of how large the units are.


The other one is removal of 'with'. I find it one of the worst blocks 
imepeding refactoring. I have also been to known to spend days removing 
'with's from units (e.g VirtualTrees.pas). And, even though I did write 
a special utility just to help me with that, I still managed to 
introduce subtle bugs that I cannot get rid of for the life of me.


To do it right, I need a parser thats smart enough to identify which 
variable/property/etc. belong to which object (in the case of derived 
objects, it needs to be able to go all the way back to TObject, if 
necessary) and rewrite the relevant portion of code.


I have started looking at fcl-passrc and it looks usable so far. But, I 
need to reformat it all :) And, then get it to work under D7.


Actually, I did get it to compile under D7 but that does not, of course, 
mean I have digested any of it yet.


If I may go back to the topic of 'compiler as dll' and use you as a 
sounding board for a moment:


What I had in mind was that the dll would have no access to disk/storage 
at all.


It would, instead, request and receive any unit it needs through streams 
--similarly, it would also output its binary through the same mechanism 
back to the owner application.


This would keep any changes from the user: I.e. the main application (as 
far as the user is concerned) would be the same compiler executable in 
text mode.


This would open up other uses, such as (with a suitably produced main 
application) remote development.


I think this would be especially useful for platforms that have limited 
storage; or conversely, the when the compiler's platform is stronger 
(more memory, faster cpu etc.) than the one the developer is using 
(laptop, tablet etc.)


Personally, I would love something mostly because I like (I am a lot 
more accustomed to) Windows better than other platforms for all sorts of 
things, and Lazarus appears to be more solid on Windows. Plus, I find 
using stuff like VNC or even RDP to be confusing to track where the 
cursonr/keyboard actioans will apply.


But, of course, if this were possible for Windows, it would also be 
possible for other platforms that Lazarus (or other IDEs) can be run.


Do you think this would be as useful as I am portraying it to be?

Or, if so, can it be done with reasonable effort --for someone better 
than I, I presume.



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

[Lazarus] code formating [wan: Re: WriteLn back to the GUI]

[Martin]

On 26/10/2013 17:12, ListMember wrote:


One of my main hope is to come up with a fast enough code formatter 
with the options that I need.

Have you looked at jedi? (Install package JCF).

It has plenty of options. BUt it fails parsing some newer code. But if 
you anyway are going to spent time, why not spending it o fixing jcf?





The other one is removal of 'with'. 
Codetool has an option. (Refactor menu / pop.up). You can assign it to a 
keyboard shortcut.




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

Re: [Lazarus] code formating [wan: Re: WriteLn back to the GUI]

[ListMember]

On 2013-10-26 19:19, Martin wrote:

On 26/10/2013 17:12, ListMember wrote:


One of my main hope is to come up with a fast enough code formatter 
with the options that I need.

Have you looked at jedi? (Install package JCF).

It has plenty of options. BUt it fails parsing some newer code. But if 
you anyway are going to spent time, why not spending it o fixing jcf?


I looked at it again some 3-4 years ago, I have issues with its 
internal/structural design: It uses indexed access in a very inelegant 
way that makes it also slow. I did try to refactor it to use 
trees/linklists internally, but I ran out of patience/stamina. As a 
result of all that, I won't touch JCF again. Sorry.





The other one is removal of 'with'. 
Codetool has an option. (Refactor menu / pop.up). You can assign it to 
a keyboard shortcut.




This is interesting.

I didn't know that. Thank you for pointing it out?

Have you used it --i.e. is it any good?

Do you know whether it uses JCF or something else as the parser?

BTW, I've got Lazarus v1.0.12 here and I don't see anything in any 
popups that sound anything like 'remove with'; could you be a little 
more descriptive on the steps to wake up that beeast.


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

Re: [Lazarus] WriteLn back to the GUI

[Sven Barth]

Am 26.10.2013 18:12 schrieb "ListMember" :
> I have started looking at fcl-passrc and it looks usable so far. But, I
need to reformat it all :) And, then get it to work under D7.

Please note that patches that change the formatting just for the sake of
adjusting it to ones own taste are likely to be rejected.
(just to avoid surprised reactions)

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

Re: [Lazarus] code formating [wan: Re: WriteLn back to the GUI]

[Martin]

On 26/10/2013 18:08, ListMember wrote:

On 2013-10-26 19:19, Martin wrote:




The other one is removal of 'with'. 
Codetool has an option. (Refactor menu / pop.up). You can assign it 
to a keyboard shortcut.




This is interesting.

I didn't know that. Thank you for pointing it out?

Have you used it --i.e. is it any good?

Not used it... Not needed to use it yet



Do you know whether it uses JCF or something else as the parser?

Codetool has its own parser



BTW, I've got Lazarus v1.0.12 here and I don't see anything in any 
popups that sound anything like 'remove with'; could you be a little 
more descriptive on the steps to wake up that beeast.


Probably need to install package "Cody"



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

Re: [Lazarus] WriteLn back to the GUI

[ListMember]

On 2013-10-26 20:11, Sven Barth wrote:


Am 26.10.2013 18:12 schrieb "ListMember" >:
> I have started looking at fcl-passrc and it looks usable so far. 
But, I need to reformat it all :) And, then get it to work under D7.


Please note that patches that change the formatting just for the sake 
of adjusting it to ones own taste are likely to be rejected.

(just to avoid surprised reactions)



I am ware of that.

But, formatting back to the style already used shouldn't be too hard: 
basically everything lowercase coupled with such economy of spaces that 
falls just a tad short of obfuscation ;)


[BTW, this isn't a comment on anyones formatting taste --just how it 
feels here.]
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] visual component form guidelines

[BTree Computing Services]

In the Lazarus GUI, when components are placed on a form, vertical and
horizontal design guidelines are drawn to assist in aligning the
component relative to other components.  These lines are like 'laser
lines' that shoot out from the edges.  Does anyone know how that
technique is done or the source code so that I can implement a similar
technique in my app?

Thanks




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

Re: [Lazarus] code formating [wan: Re: WriteLn back to the GUI]

[Juha Manninen]

On Sat, Oct 26, 2013 at 8:13 PM, Martin  wrote:
> Probably need to install package "Cody"

Yes, it is in Cody package mainly because the user interface is not as
polished as it should be (according to Mattias). Cody has "advanced"
features.
I have used the "Explode a With block" feature and it works very well.

Juha

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

Re: [Lazarus] visual component form guidelines

[Sven Barth]

On 26.10.2013 21:44, BTree Computing Services wrote:

In the Lazarus GUI, when components are placed on a form, vertical and
horizontal design guidelines are drawn to assist in aligning the
component relative to other components.  These lines are like 'laser
lines' that shoot out from the edges.  Does anyone know how that
technique is done or the source code so that I can implement a similar
technique in my app?


Please do not ask a new question as an answer to an existing thread. You 
might not receive any answers then, because people that could answer 
you, might ignore the thread.


So when asking a new question always write directly to (in this case) 
lazarus@lists.lazarus.freepascal.org instead of using "answer to list".


Regards,
Sven


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