Re: [Lazarus] Lazarus make clean fails...

[Sven Barth via lazarus]

Giuliano Colla via lazarus  schrieb am So.,
3. Dez. 2023, 11:42:

> I’m not familiar with your environment, but I’ve never seen a lazarus
> directory which is not named “lazarus”. Therefore I’d cd one step further:
> cd ~/devtools/lazarus/2.2.6/lazarus
>

I extract all sources into a directory with only the version number, so,
no, it doesn't have to be called "lazarus". Thus your suggestion won't
work. If that were case the error message would be that no Makefile has
been found anyway.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] LclVLC usage questions for switching from PasLibVLC

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am Mo., 20.
Nov. 2023, 15:09:

> On Sun, 19 Nov 2023 14:50:34 +0100, Bo Berglund via lazarus
>  wrote:
>
> >Lazarus contains LibVLC as a standard package available to be installed
> in the
> >GUI using Package/Install-remove packages! No download needed from
> external
> >sources!
>
> >Anyway, I have been experimenting with the example inside the package
> code and
> >also read Michael's document "Displaying video files using Free Pascal and
> >Lazarus".
> >
> >I think I can switch out PasLibVLC and replace it with the LclVLC player
> instead
> >but I need some help in implementation.
> >
> >There are some functions I would like to get hints on how to implement:
> >
> >1) Progressbar update
> >-
> THIS IS NOW SOLVED!
> 
> I added a TThread.Create... statement as I found in the document, without
> really
> understanding how it can help. Seems to me like creating a thread that
> immediately exits. What can that do?
>

It ensures that the RTL is multi threading aware, cause as long as no
Pascal thread is started (which is the case for many programs) some
shortcuts are taken by not using locks and such. However if you use an
external library that starts non-Pascal threads that then call into the
Pascal code things might go wrong due to this. Thus creating an empty
thread will ensure that all locks are properly in place.

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] [fpc-devel] Unicode RTL

[Sven Barth via lazarus]

Sergey Bodrov via lazarus  schrieb am Fr.,
28. Juli 2023, 18:52:

> And UnicodeString is just alias for WideString
>

On Windows UnicodeString is *not* an alias to WideString. There they are
two completely different types that happen to both handle string with a
element width of 2 and UTF-16 encoding.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus trunk version number

[Sven Barth via lazarus]

Maxim Ganetsky via lazarus  schrieb am Fr.,
30. Juni 2023, 15:48:

> 30.06.2023 16:44, Maxim Ganetsky via lazarus пишет:
> > 30.06.2023 14:27, Martin Frb via lazarus пишет:
> >> On 30/06/2023 12:51, Michael Van Canneyt via lazarus wrote:
> >>>
> >>>
> >>> On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote:
> >>>
>  On Friday, June 30, 2023, John Landmesser via lazarus <
>  lazarus@lists.lazarus-ide.org> wrote:
> 
> > perhaps that should have become 3.00 ?
> >
> > Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2
> > x86_64-linux-gtk2
> >
> > You are looking at trunk, the development version. See :
>  https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer
> >>>
> >>> You might want to add some explanation for this new versioning
> >>> scheme to that page.
> >>
> >> Added.
> >
> > I made some improvements, hope it is even more clear now.
> >
> >>> The graph does not help.
> >>>
> >>> From what is currently there, I don't understand neither the logic
> >>> nor the need of this change.
> >> "Need"... Well, in terms of "because it solved the issue xyz" => then
> >> there is no need.
> >
> > Basically, version numbering is all about "marketing". By always
> > increasing major version we tell to the general audience that major
> > release indeed contains major changes (which is always the case).
> >
> > So we solve/improve "marketing" issues.
> >
> BTW, in my opinion FPC has similar issues and will benefit from such
> approach to versioning too.
>

In FPC the major number *has* a meaning, namely that there have been
significant changes in the code generator. Towards the 2.x series it was
the rewrite of the different backends and for the 3.x series it was the
introduction of the high level code generator.
The minor number is then to signify a new release with many new features on
top of the same base architecture and the release number is then to
differentiate between development and stable.

We don't follow "marketing".

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Simple ipc server fatal error on start - 0xc000007b

[Sven Barth via lazarus]

Wayne Sherman via lazarus  schrieb am So.,
2. Apr. 2023, 02:45:

> On Fri, Mar 31, 2023 at 9:38 AM Bo Berglund wrote:
> > What I want to do is...use the D7 app to read a hardware device on
> command
> > and send the data to the Lazarus app.
>
> You probably don't need the extra complication of IPC, sockets, COM,
> or OLE automation.  Instead of creating a D7 app, build a D7 DLL which
> exports the function(s) you need.  Import the DLL function(s) to your
> Lazarus app and call them directly.
>

Since the Delphi code in question is 32-bit that will restrict the FPC code
to i386-win32.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] animated splash screen for lengthy operation, works with windows, doesn't with linux

[Sven Barth via lazarus]

Luca Olivetti via lazarus  schrieb am Mo.,
27. März 2023, 10:34:

> El 27/3/23 a les 10:13, Jean SUZINEAU via lazarus ha escrit:
> >
> > Le 27/03/2023 à 09:46, Luca Olivetti via lazarus a écrit :
> >> procedure TUpdateThread.Execute;
> >> begin
> >>   while not Terminated do
> >>   begin
> >> FWaitForm.ShowProgress;
> >> Sleep(30);
> >>   end;
> >> end;
> >
> > Usually I use TThread.Synchronize to ensure that the graphic code is run
> > by the main thread.
> >
> > But it won't work if your main thread is blocking.
>
> Exactly
>
> >
> > May be you should do the inverse move the lengthy operation to a
> > separate thread and keep the main thread for the splash screen ?
>
> Yes, I usually do that, but in this case it's not possible (the lengthy
> operation is just a  TSQLQuery.open that I cannot delegate to a
> different thread).
>

You need to find a way then, because the GUI handling *must* be done in the
main thread.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus fails to build

[Sven Barth via lazarus]

Martin Frb via lazarus  schrieb am So., 19.
März 2023, 20:57:

> On 19/03/2023 19:53, Sven Barth via lazarus wrote:
> >  If it *would* work however you could simply do {$if not
> > declared(name_of_the_unit)}, because the unit name is also a valid
> > symbol.
>
> ooohh nooo. That would be like C header files Don't wont that. ;)
>

It's you who brought out the ifdef idea and I simply pointed out a more
correct solution than picking some random symbol in the unit.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus fails to build

[Sven Barth via lazarus]

Am 19.03.2023 um 09:36 schrieb Martin Frb via lazarus:

On 19/03/2023 00:00, Michael Van Canneyt via lazarus wrote:


On Sat, 18 Mar 2023, Mattias Gaertner via lazarus wrote:



As this happens seldom there is no detection built in (yet) to handle
this automatically.


If possible, might be a good idea.


Afaik there are 2 scenarios.

1) The duplicate.
The user has the package installed, that now became a base package. So 
units are used twice.


For this there may be a very simple solution.
- staticpackes is used by lazarus.pp
- So we could add new core-packackage-units to a different unit's use 
clause. Then they don't appear twice in the same uses clause.
E.g. we could add a unit LazCorePackages, and that just contains a 
uses clause.  It would be used first in the uses of lazarus.pp.


It may also be able to do some trickery with IFDEF.
If core packages are in the lazarus.pp uses clause, appearing only 
after staticpackages, then there could be {$IF not 
defined(symbol_from_new_core_unit)}.

Haven't tested that, don't know if it would actually work.


It would not, because FPC loads the units only at the of the uses clause 
and not once for every unit it finds. This is an incompatibility with 
Delphi, but currently there's no real desire to change that as it only 
affects such uses-clause trickery. If it *would* work however you could 
simply do {$if not declared(name_of_the_unit)}, because the unit name is 
also a valid symbol.


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] version `GLIBC_2.34' not found error when running app on different PC

[Sven Barth via lazarus]

Mehmet Erol Sanliturk via lazarus  schrieb
am Fr., 17. März 2023, 12:58:

>
>
> On Fri, Mar 17, 2023 at 10:07 AM Bo Berglund via lazarus <
> lazarus@lists.lazarus-ide.org> wrote:
>
>> On Fri, 17 Mar 2023 08:53:01 +0300, Mehmet Erol Sanliturk via lazarus
>>  wrote:
>>
>> >Some portability is obtained if the libraries are linked as "static" .
>> >If "dynamic" linking is selected , during execution of the program ,
>> >the "same" library should be in the executing computer .
>> >
>>
>> How is this accomplished in Lazarus?
>>
>> Does this change happen randomly or is it connected to the major Ubuntu
>> releases
>> like going from 20.04 to 22.04 rather than just keeping 20.04 up-to-date?
>>
>> It implies having to build applications on as old a system as ever
>> possible,
>> maybe using 16.04 or earlier just for making apps that can run on all
>> systems,
>> is that really true?
>>
>> It makes no sense to me...
>>
>>
>
> Please study fpc.cfg file structure , and Lazarus IDE linking options .
> On my computer , neither FPC nor Lazarus are installed .
>
>
> There is an option to specify either dynamic linking or static linking of
> libraries .
>
> When static linking is selected , it is necessary to have  static linkable
> libraries ( *.a )
> of used parts , i.e. , dynamic linkable libraries ( *.so.* ) can not be
> used for
> static linking .
>
>
>
> https://www.google.com/search?q=lazarus+static+linking+of+libraries=AJOqlzXTPuAEwc2JkAaon6mLwAvBM-kn5A%3A1679053415469=Z1IUZL2NHP-Qxc8PqvqOuAM=0ahUKEwj93Iyz8eL9AhV_SPEDHSq9AzcQ4dUDCA4=5=lazarus+static+linking+of+libraries_lcp=Cgxnd3Mtd2l6LXNlcnAQAzIFCCEQoAE6BwgAEB4QsAM6BAgjECc6BggAEBYQHjoICAAQFhAeEAo6CAgAEBYQHhAPOgUIABCRAjoFCAAQgAQ6BwguEIAEEAo6BwgAEIAEEAo6CgguEIAEENQCEAo6CAgAEIAEEMsBOgsILhCABBDUAhDLAToICC4QgAQQywE6BQguEIAEOgsILhCABBDHARCvAToKCAAQgAQQFBCHAjoHCAAQDRCABDoICAAQBRAeEA06BAghEBU6BwghEKABEApKBAhBGAFQpBdYi8IBYIHJAWgDcAB4AIABxwGIAcYikgEEMC4zNpgBAKABAcgBAsABAQ=gws-wiz-serp
>
> lazarus static linking of libraries
>
> Comparison of Linux and Windows is not a fruitful action , because they do
> not have much similarity
> other than being operating systems .
>

Depending on the used units static linking is simply not an option. E.g.
the database units load the database libraries dynamically and thus the C
library must not be linked statically then.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] version `GLIBC_2.34' not found error when running app on different PC

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am Fr., 17.
März 2023, 13:54:

> On Fri, 17 Mar 2023 08:43:55 +0100 (CET), Michael Van Canneyt via lazarus
>  wrote:
>
> >FPC has not changed. It still works the same.
> >Everything that is under control of FPC is linked statically.
> >
> >But a complex GUI system like the LCL uses GTK/GDK/Qt and other
> libraries,
> >and those are dynamic, external libraries over which FPC or lazarus has
> no control.
>
> This aplication is a console (i.e NO GUI) application and it only uses
> these
> units:
>
> videosplitcmb.lpr:
>
> uses
>   {$IFDEF UNIX}
> cthreads,
>   {$ENDIF}
>   Classes,
>   { you can add units after this }
>   sysutils,
>   utils,
>   runthread;
>
> and
>
> utils.pas:
>
> uses
>   Classes,
>   SysUtils,
>   Process;
>
> What is complex here?
>

Your code uses threads and on *nix systems that requires the C library.

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Debugging the unicode RTL

[Sven Barth via lazarus]

Michael Van Canneyt via lazarus  schrieb am
Do., 12. Jan. 2023, 10:42:

> 1/ Should the compiler provide some symbol in - say - the system unit to
> deterine
> whether the RTL is compiled in unicode mode, or is another mechanism
> preferred to do this ?
>

"Char" already is such a symbol that the debugger can and must use to
determine this. And if no debug information for aliases is created then
*that* needs to be fixed instead.
But the debugger also needs to be able to determine Unicode vs. ANSI if no
debug information for the System unit is available thus it needs to rely on
CodeTools then and what *that* provides for Char.

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TListView: Column Header Captions and Column Sorting

[Sven Barth via lazarus]

Aruna Hewapathirane via lazarus  schrieb am
Do., 17. Nov. 2022, 12:31:

> I managed to get the TListView to work after studying the example Sven
> sent. You can see a screenshot here:
> https://pasteboard.co/inCtdrOWwAvV.png
>

You sure you don't mean Werner instead of me? ;)

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Creating a library

[Sven Barth via lazarus]

Am 15.11.2022 um 20:31 schrieb Aruna Hewapathirane:


On Tue, Nov 15, 2022 at 2:28 PM Sven Barth via lazarus 
 wrote:


Am 15.11.2022 um 20:11 schrieb Aruna Hewapathirane via lazarus:
> Hello Everyone,
>
> I was wondering if it is possible for me to create a library
with my
> own set of code snippets I use on a regular basis . Is there any
> example code I can possibly look at how this is done?
>
> Or a small single function example if someone is willing would help
> immensely.

Do you really mean a library in the sense of a DLL or SO which
requires
you to pay a bit more attention to how you code it due to the
crossing
of the module boundaries or do you mean a Lazarus package which is a
collection of units that Lazarus will compile for you if necessary
and
that you can use freely?

Regards,
Sven


Hi Sven, my apologies I should have been more specific and yes it is 
the linux SO
I am specifically interested in but certainly also interested in how 
to create the DLL

for Windows.Thanks!

Then please take a look here: 
https://www.freepascal.org/docs-html/prog/progch12.html#x262-27800012


But also pay attention to these articles on the Wiki which raise a few 
issues you need to be aware of:

- https://wiki.freepascal.org/Lazarus/FPC_Libraries
- https://wiki.freepascal.org/shared_library

Important points of these to keep in mind:
- don't allocate memory in the module and release in the program (or 
vice versa) - unless you use a common memory manager between them like 
ShareMem or cmem - this also includes strings and arrays

- don't pass classes between module and program
- don't propagate exceptions from the module to the program (or vice versa)

Regards,
Sven-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Creating a library

[Sven Barth via lazarus]

Am 15.11.2022 um 20:11 schrieb Aruna Hewapathirane via lazarus:

Hello Everyone,

I was wondering if it is possible for me to create a library with my 
own set of code snippets I use on a regular basis . Is there any 
example code I can possibly look at how this is done?


Or a small single function example if someone is willing would help 
immensely.


Do you really mean a library in the sense of a DLL or SO which requires 
you to pay a bit more attention to how you code it due to the crossing 
of the module boundaries or do you mean a Lazarus package which is a 
collection of units that Lazarus will compile for you if necessary and 
that you can use freely?


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Type Library Viewer, Importer, and Editor?

[Sven Barth via lazarus]

Marco van de Voort via lazarus  schrieb am
So., 26. Juni 2022, 15:06:

>
> On 26-6-2022 14:37, Anthony Walter via lazarus wrote:
> > Does Lazarus have a type library viewer for previewing all the type
> > libraries on your computer in the form of converted pascal source code?
>
>
> Afaik there is only a typelib importer (importtl) that generates pascal.
>

And it allows listing of all installed type libraries. You can check it out
in the IDE by installing the LazActiveX package.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Component palette enhancements

[Sven Barth via lazarus]

Marco van de Voort via lazarus  schrieb am
Fr., 8. Apr. 2022, 11:58:

>
> IOW in which cases is disambiguation in the class registration of the
> generated app needed?
>
>
> Sure, the IDE is also a FPC/Lazarus app, but it has more leeway for
> solutions that doesn't require changes to the way EVERY APP streams its
> forms.
>

The use case that Michael has in mind is that inside an app you have a
StdCtrls.TButton and a MyControls.TButton. Right now one *must* rename ones
own even though the full name including unit name is unique.

Solving this would at the same time allow the IDE to have a TButton for
both the LCL and e.g. Web Components Library. Right now they need to be
named differently like WebCtrls.TWButton.

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Component palette enhancements

[Sven Barth via lazarus]

Michael Van Canneyt via lazarus  schrieb am
Mi., 6. Apr. 2022, 14:47:

>
>
> On Wed, 6 Apr 2022, Sven Barth via lazarus wrote:
>
> > Michael Van Canneyt via lazarus  schrieb
> am
> > Mi., 6. Apr. 2022, 12:56:
> >
> >>
> >> 1. Currently a component is identified by its class name.
> >>
> >> This should be enhanced: a component must be identified with
> >> UnitName.Name.
> >> a unit name is a "namespace" and so MyControls.TButton <>
> >> StdCtrls.TButton.
> >>
> >> Currently there are several component name clashes in the pas2js and
> >> FPC class trees.
> >>
> >
> > The streaming system can't differentiate by unit name, so this simply
> isn't
> > possible.
>
> I know that.
>
> We simply need to adapt the streaming system so it can,
> I already studied that, it's fairly trivial:
>
> * When writing: write UnitName.ComponentName instead of ComponentName.
>A trivial change, which can be done in a backward compatible manner.
>
> * When reading, there are 2 lines that must be changed:
>One in GetClass and one in TReader.FindComponentClass.
>
> * To handle the text format, 2 lines need changing.
>
> So this is not exactly lots of work.
>

But then this needs to be in FPC first and there it will only be officially
available once 3.4.0 is released. And since Lazarus supports the last two
releases it would need to be handled in a way that allows the user to cater
to older FPC versions as well.



> > 3. Please add a search edit in the component palette, as delphi has it:
> >> typing in that edit should reduce the visible tabs to show only tabs
> >> that have a
> >> component with the typed text in the classname, just like the one on
> >> the component window...
> >> (the component window is IMO not really usable if you are not using
> a
> >> docked IDE)
> >>
> >
> > Why don't you use the component list instead of the palette then? This
> > already provides a search.
>
> If you read my message correctly, you'll see that I know this.
> Additionally my last sentence tells you why I don't use it...
>

Gotta admit that I had only skimmed the last sentence ^^'

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Component palette enhancements

[Sven Barth via lazarus]

Michael Van Canneyt via lazarus  schrieb am
Mi., 6. Apr. 2022, 12:56:

>
> 1. Currently a component is identified by its class name.
>
> This should be enhanced: a component must be identified with
> UnitName.Name.
> a unit name is a "namespace" and so MyControls.TButton <>
> StdCtrls.TButton.
>
> Currently there are several component name clashes in the pas2js and
> FPC class trees.
>

The streaming system can't differentiate by unit name, so this simply isn't
possible.

3. Please add a search edit in the component palette, as delphi has it:
> typing in that edit should reduce the visible tabs to show only tabs
> that have a
> component with the typed text in the classname, just like the one on
> the component window...
> (the component window is IMO not really usable if you are not using a
> docked IDE)
>

Why don't you use the component list instead of the palette then? This
already provides a search.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Gtk 1.2 fixes (again)

[Sven Barth via lazarus]

Am 13.02.2022 um 23:22 schrieb Kostas Michalopoulos via lazarus:
Beyond that, as i wrote in the merge request, MUI is even more 
"ancient" and yet Lazarus added support for it recently. I do not see 
why it being called obsolete by its original developers means that one 
couldn't work on it if they want, it is open source after all, the 
entire point is having the freedom to do things like that.


While MUI might be ancient it's still actively used by current operating 
systems, namely MorphOS and AROS (and of course Amiga operating systems 
themselves, but they aren't actively developed anymore).


Note: I'm not critizing your effort, in fact I'm welcoming it as myself 
want to find the time to make sure that current Lazarus works correctly 
on PowerPC Mac with Carbon again.


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Gtk 1.2 fixes (again)

[Sven Barth via lazarus]

Am 13.02.2022 um 22:58 schrieb Kostas Michalopoulos via lazarus:

On 2/13/22 21:33, Sven Barth via lazarus wrote:

Bart means the internal, private Lazarus developer list.


I see, but then why tell me? :-P


To explain to you that your request is looked at and why there might be 
delays in deciding about it.


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Gtk 1.2 fixes (again)

[Sven Barth via lazarus]

Kostas Michalopoulos via lazarus  schrieb am
So., 13. Feb. 2022, 18:31:

> On 2/13/22 16:49, Bart via lazarus wrote:
> > On Sat, Feb 12, 2022 at 6:25 PM Kostas Michalopoulos via lazarus
> >  wrote:
> >
> > This is currently being discussed on the devel ML.
> >
>
> Isn't this the development mailing list? Most of the discussion seems to
> be about Lazarus' development and can't find any other list mentioned in
> https://lists.lazarus-ide.org/


Bart means the internal, private Lazarus developer list.

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Making fpdebug more cross-platform friendly

[Sven Barth via lazarus]

Martin Frb via lazarus  schrieb am Do., 16.
Dez. 2021, 23:27:

> Only, question is, if we need the ABI?
> - Do win64 and linux64 share the same ABI? (or win32 <> linux32)?
>Afaik SEH is win specific (and probably would be best of in the ABI?).
>But there could still be a base class that is shared between Win/Linux.
>

Yes, SEH is Windows specific. The ABI is mostly CPU specific however. E.g.
all the i386 calling conventions can be used on all OSes. On the x86_64
systems one usually uses either the SysV or the Win64 ABI, but both FPC and
Clang allow the use of the other calling convention as well. On the other
hand the register usage on m68k for example differs between Amiga and
non-Amiga (the stack pointer is a different register and the stack
alignment is 2 instead of 4 Byte) and this can't be changed.
So in my opinion the design should allow for as much code sharing/reuse as
possible, e.g. with a general x86_64 ABI with OS specifics (e.g. SEH) on
top.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TMask revisited

[Sven Barth via lazarus]

Juha Manninen via lazarus  schrieb am Fr.,
15. Okt. 2021, 14:03:

> This may be a dummy question but what does "static" do for a class
> procedure?
> José's mask code has for example:
>
>   class procedure Exception_IncompleteMask(); static;
>
> I thought class procedures are kind of static anyways, meaning they don't
> have a Self pointer.
>

Non-static class methods *do* have a Self parameter, but it's the class
type and not the class instance. They can also be virtual, which is a
really great feature of the Object Pascal language (I often miss that at
work where I use C++). They are also assignment compatible to method
variables ("of object").

Static methods on the other hand don't have a Self parameter, can't be
virtual and are assignment compatible to normal procedure variables.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] trying to read an EXE

[Sven Barth via lazarus]

duilio foschi via lazarus  schrieb am Fr.,
3. Sep. 2021, 23:08:

>
> Looking for string 'peppe', I can easily spot the part that contains
> the code of interest.
>

In addition to what Bart wrote: the string will be located in a different
section (usually .rdata) than where it will be used (in this case .text)
which will only be a reference.

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus for writing 3D Desktop Environment/Window manager for Linux?

[Sven Barth via lazarus]

Chavoux Luyt via lazarus  schrieb am Do.,
24. Juni 2021, 14:53:

> (although it would have been nice if Lazarus could add packages like
> Delphi without needing to recompile the whole IDE - compile the package to
> a .dll or .so and simply link into it from the IDE?).
>

Simply using ordinary libraries would fall spectacularly short of what you
desire. The package system as known from Delphi allows the metadata of
types to be shared between binary modules, something that you *can't* do
with libraries. If it would be that easy it would have been done already.

Instead that functionality requires intensive support by both the compiler
and the RTL. We are on our way there, but we aren't there yet. Sooner or
later that will come in Lazarus as well.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Fwd: Registering a TFrame to component palette

[Sven Barth via lazarus]

Juha Manninen via lazarus  schrieb am So.,
13. Juni 2021, 18:45:

> It went to Sven Barth only, forwarding here.
> I clicked the reply button as always. I don't know what happened.
>

Probably because I used "Reply to all" and your e-mail client then picked
up my address instead of the list's.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Registering a TFrame to component palette

[Sven Barth via lazarus]

Michael Van Canneyt  schrieb am So., 13. Juni 2021,
13:53:

>
>
> On Sun, 13 Jun 2021, Sven Barth via lazarus wrote:
>
> > Am 11.06.2021 um 23:48 schrieb Juha Manninen via lazarus:
> >> Regarding issue : https://bugs.freepascal.org/view.php?id=28450
> >> <https://bugs.freepascal.org/view.php?id=28450>
> >>
> >> The parameter passed to function RegisterComponents() is
> TComponentClass
> >> which means "class of TComponent". It is only type information and does
> not
> >> carry information about sub-components.
> >> Could somebody please explain how it works in Delphi. Does this really
> work
> >> :
> >>   RegisterComponents('Sample', [TMyFrame]);
> >
> > Yes, it does work this way. I don't know what you mean with "information
> > about sub-components". The VMT vFieldTable entry contains all published
> > fields of the class and thus all the sub controls that are visible
> through
> > the RTTI and thus for the designer. If the IDE does not use that yet,
> then it
> > definitly should.
> >
> >> I added a comment to the report but it is old and the reporter may not
> read
> >> it.
> >> Maybe there should be a new function RegisterFrame() or similar?
> >
> > There is no need to add anything, because the necessary information is
> > already there. It's just that the IDE doesn't use it yet.
>
> In Delphi, the above also does not work, you need special handling for
> frames, just as for forms.
>

You think I didn't test it before writing? I created a frame, added it to a
package, added a Register procedure, installed the package, started a new
VCL application and added that frame to the form from the component
palette. I had added a button and a combo box and both were visible in the
designer.

Or did I miss something here?

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Registering a TFrame to component palette

[Sven Barth via lazarus]

Am 11.06.2021 um 23:48 schrieb Juha Manninen via lazarus:
Regarding issue : https://bugs.freepascal.org/view.php?id=28450 



The parameter passed to function RegisterComponents() is 
TComponentClass which means "class of TComponent". It is only type 
information and does not carry information about sub-components.
Could somebody please explain how it works in Delphi. Does this really 
work :

  RegisterComponents('Sample', [TMyFrame]);


Yes, it does work this way. I don't know what you mean with "information 
about sub-components". The VMT vFieldTable entry contains all published 
fields of the class and thus all the sub controls that are visible 
through the RTTI and thus for the designer. If the IDE does not use that 
yet, then it definitly should.


I added a comment to the report but it is old and the reporter may not 
read it.

Maybe there should be a new function RegisterFrame() or similar?


There is no need to add anything, because the necessary information is 
already there. It's just that the IDE doesn't use it yet.


Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Fwd: using a weird DLL

[Sven Barth via lazarus]

duilio foschi via lazarus  schrieb am Mo.,
1. Feb. 2021, 11:22:

>
> On Mon, Feb 1, 2021 at 10:08 AM duilio foschi 
> wrote:
>
>> I am corrected. The DLL is written in c#. It seems that Bitmap and
>> Rectangle are common predefined/usable objects in C#.
>>
>
You can't trivially use a C# (or .NET in general) library in native code.
(It essentially involves hosting the CLR and then invoking the code)

RemObjects for example provides bridges for the managed and unmanaged code,
but I don't know whether it supports Lazarus and it isn't free (as in beer)
anyway. ( https://hydra.remobjects.com/hydra/default.aspx )

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] using a weird DLL

[Sven Barth via lazarus]

duilio foschi via lazarus  schrieb am So.,
31. Jan. 2021, 23:23:

> I would like to use a function exported from a DLL. The DLL was written in
> C++ (Visual Studio 2015).
>
> Inside the original code the function is declared as
>
> public bool GetSkinFeatures(Bitmap Input_Bitmap, Rectangle
> ROI_Rect, double[] ExtractedFeatures)
>
> Anybody knows how to use it from Lazarus?
>

Can you also show the declarations of Bitmap and Rectangle? Is the function
declared inside an "extern "C"" block?

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Update to help documentation

[Sven Barth via lazarus]

Rolf Wetjen via lazarus  schrieb am Fr., 8.
Jan. 2021, 09:58:

> I've a small update for the help files masks.xml and maskedit.xml.
>
> How can I share it to the project?
>

Best provide patches in a bug report on https://bugs.freepascal.org/ for
the Lazarus project.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Tooltip shows value of some but not all const items....

[Sven Barth via lazarus]

Am 02.01.2021 um 23:29 schrieb Bo Berglund via lazarus:

On Sat, 2 Jan 2021 12:36:06 +0100, Sven Barth via lazarus
 wrote:


Am 02.01.2021 um 12:09 schrieb Bo Berglund via lazarus:

Another question:
-
Is there a difference between the two types of declarations?
I think that the # specifier of the value also declares the const as a
char in the first place, or not?

The first is a "untyped constant". It takes its type implicitely from
the right side and not everything can be a constant (e.g. you can't use
records). So in your case, yet's it's a Char due to the right side being
a character constant.

The second is a so called "typed constant". They are essentially
variables that might be readonly (they are readonly if {$J-} is set
which is *not* the default). They were originally introduced in Turbo
Pascal to allow for static variables inside functions (cause that is how
they behave).

The main difference is that an untyped constant can be used inside
constant expressions (e.g. to declare a static array with certain
bounds) while a typed constant can not. On the other hand you can take
the address of a typed constant (as it's essentially a variable with
readonly data) while you can't do that for untyped constants.

And yes, it behaves this way in Delphi, too.

Since I see no difference in the usage of these constants typed or
not, I might as well remove the type declaration.
After all I do not want thes to change like a variable can...
The value is a char thanks to the #$ part, I guess.
Or a byte, which is really what it is used as, they are command
identifiers in a packet sent by RS232 to the equipment.
For most cases the two can indeed be considered equal, thus it doesn't 
matter which one you use.


Your untyped constant will have type Char due to the # prefix.

Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Tooltip shows value of some but not all const items....

[Sven Barth via lazarus]

Am 02.01.2021 um 12:09 schrieb Bo Berglund via lazarus:

Is there some Lazarus setting that will enable always showing the
value?


You would probably need to do a feature request for that.


Another question:
-
Is there a difference between the two types of declarations?
I think that the # specifier of the value also declares the const as a
char in the first place, or not?


The first is a "untyped constant". It takes its type implicitely from 
the right side and not everything can be a constant (e.g. you can't use 
records). So in your case, yet's it's a Char due to the right side being 
a character constant.


The second is a so called "typed constant". They are essentially 
variables that might be readonly (they are readonly if {$J-} is set 
which is *not* the default). They were originally introduced in Turbo 
Pascal to allow for static variables inside functions (cause that is how 
they behave).


The main difference is that an untyped constant can be used inside 
constant expressions (e.g. to declare a static array with certain 
bounds) while a typed constant can not. On the other hand you can take 
the address of a typed constant (as it's essentially a variable with 
readonly data) while you can't do that for untyped constants.


And yes, it behaves this way in Delphi, too.

Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Issues getting sources from the repository

[Sven Barth via lazarus]

Leyba Bronstain via lazarus  schrieb am Sa.,
26. Dez. 2020, 01:49:

> Hi guys.
>
> When I try to get the fpc/lazarus source code from the repository using
> the svn-client, the server drops the connection. These cases are observed
> several times during the process. I have to run the svn client several
> times. It looks something like this
>
> C:\Users\leyba>md c:\test
> C:\Users\leyba>cd c:\test
> C:\test>svn co https://svn.freepascal.org/svn/fpc/trunk fpc_trunk
> Afpc_trunk\compiler
> 
> svn: E120108: Error running context: The server unexpectedly closed the
> connection.
> C:\test>svn cleanup fpc_trunk
> C:\test>svn co https://svn.freepascal.org/svn/fpc/trunk fpc_trunk
>
> etc.
>
> Somebody tell me pls, what happened?
>

Instead of cleanup and another checkout simply change into the directory
and do a "svn update" which will continue the checkout. Repeat until done.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] CDDB access

[Sven Barth via lazarus]

Michael Van Canneyt via lazarus  schrieb am
Mi., 2. Dez. 2020, 08:02:

>
>
> On Wed, 2 Dec 2020, Teresa Williams via lazarus wrote:
>
> > Hi
> >
> > I need to access CDDB (and also MusicBrainz would be nice) on Linux.  I
> found https://wiki.freepascal.org/CDDB but as that page suggests, the
> download link is defunct.
> >
> > Are there any other such?  In the past I have done this by spawning two
> bash scripts which use CDDB and write text files.  Ugly. Slw. Error-prone
> (the format of the results is a bit variable).
> >
> > I'm not too proud to do that again, but is there a more elegant way?
>
> FPC comes with such units since ages:
>
> https://www.freepascal.org/daily/packages/cdrom/index.html


I have added a note to the wiki article that suggests the FPC unit as well
as your article about this.

Additionally I've added a note about FreeDB being down.

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus totally destroyed... :(

[Sven Barth via lazarus]

Juha Manninen via lazarus  schrieb am Fr.,
20. Nov. 2020, 12:24:

> On Fri, Nov 20, 2020 at 12:32 PM Michael Van Canneyt via lazarus <
> lazarus@lists.lazarus-ide.org> wrote:
>
>> - Updated Lazarus from SVN.
>> - Lazarus no longer compiles (FPC 3.2)
>>
>> - Managed to fix that:
>>
>> home:~/lazarus> svn diff ide/ideoptionsdlg.pas
>> Index: ide/ideoptionsdlg.pas
>> ===
>> --- ide/ideoptionsdlg.pas   (revision 64150)
>> +++ ide/ideoptionsdlg.pas   (working copy)
>> @@ -36,7 +36,7 @@
>> ExtCtrls, StdCtrls, Dialogs,
>> // LazControls
>> TreeFilterEdit,
>> -  LazControlDsgn, // move this to lazarus.lpr
>> +   // LazControlDsgn, // move this to lazarus.lpr
>> // IdeIntf
>> IDEWindowIntf, IDEOptionsIntf, IDEOptEditorIntf, IDECommands,
>> IDEHelpIntf,
>> ProjectIntf, IDEImagesIntf,
>>
>
> I remember that LazControlDsgn required some tweaking but it was a long
> time ago.
> No recent changes have affected it.
> I just today built Lazarus without problems. I don't know what is causing
> your errors.
>

Last week I had to do a complete clean of Lazarus 2.1 as well, cause it got
stuck at startup with 100% CPU usage on one core. I completely cleaned the
SVN directory, built from the Makefile and used a new configuration and
everything was fine again...

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Project Group error ?

[Sven Barth via lazarus]

Am 14.11.2020 um 17:17 schrieb Juha Manninen via lazarus:

Regarding issue :
https://bugs.freepascal.org/view.php?id=38011 

People with easy access to Windows, please check if you can reproduce 
the problem?



I've replied in the bug report.

Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] AutoCommit

[Sven Barth via lazarus]

Michael Van Canneyt via lazarus  schrieb am
Fr., 13. Nov. 2020, 22:37:

>
>
> On Fri, 13 Nov 2020, Ondrej Pokorny via lazarus wrote:
>
> > Usually we try to use the "default" feature of the newly added
> properties so
> > that they are streamed only when really set and used. When they are not
> used,
> > the LFM can still be loaded in a legacy version of Lazarus because the
> new
> > properties are not streamed.
>
> I set defaults on all boolean properties of sqlscript, rev. 47412
>
> Strange, I thought that boolean properties were not streamed if they had
> value 'false'.
>

No, cause their intended default value could be True. Thus no special
handling for them.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] FindWindow return sequence (Windows 10)?

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am Mo., 2.
Nov. 2020, 08:07:

> I thought that GetWindow(hWndTemp, GW_HWNDNEXT); would return the next
> larger handle following hWndTemp, but it seems like this is not the
> case. Is the result random or is there some known sequence when using
> the flag GW_HWNDNEXT??
>


The documentation about GW_HWNDNEXT on MSDN says this:

=== MSDN begin ===

The retrieved handle identifies the window below the specified window in
the Z order.
If the specified window is a topmost window, the handle identifies a
topmost window. If the specified window is a top-level window, the handle
identifies a top-level window. If the specified window is a child window,
the handle identifies a sibling window.

=== MSDN end ===

So nowhere does it guarantee that the handles values themselves are ordered
only that the resulting windows are ordered in some way.

In general you should not rely on the order of Handle values, because from
the perspective of the application they are to be considered as random.

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] I use the Windows procedure WinExec() (...)

[Sven Barth via lazarus]

Bart via lazarus  schrieb am Mo., 26. Okt.
2020, 12:00:

> On Mon, Oct 26, 2020 at 10:34 AM larrydalton71 via lazarus
>  wrote:
>
> Is there anything wrong with TOpenDialog or TSelectDirectoryDialog?
> And what exactly does "open a file" mean in your situation (open it in
> your application, let windows open it in the default associated
> application, something else)?
>
> Oh, and please don't use such a big font, it is the equivalent of
> shouting...
>

The problem is not the font, the problem is that the user's message is
completely contained inside the Subject instead of the body...  (and at
least in the Android GMail app the Subject of the first mail of a thread is
rendered with a larger font)

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] -dWINDOWS_LIGATURE [[Re: Font ligatures support]]

[Sven Barth via lazarus]

Am 04.10.2020 um 18:05 schrieb Martin Frb via lazarus:

On 04/10/2020 10:14, Mr Bee wrote:
If it does work, would you please submit it as a patch for the next 
release? At least, add a note that the font ligatures feature only 
supports monospaced fonts and only works on Windows. It's better than 
nothing.



revision 63951

Windows only, compile with -dWINDOWS_LIGATURE
Tested with Cascadia.

If someone wants to add an option "show ligatures" ($IFDEF WINDOWS} to 
the IDE options (Editor > Display / like the anti aliasing option), 
then the feature can depend on that, and no longer needs the define.


I've tested it (with Cascadia Code) and while it shows the one or other 
ligature, Visual Studio shows more.


Take the following sequence:

-> => >= <= *** .. ... <> >< >> << >>> <<< == !=

Visual Studio shows all as ligatures except the first one and the 
symmetric difference (I think it doesn't have one)


Lazarus however only shows >=, <=, <>  and .. as ligatures and for the 
three points it displays them as ".. .", so the first two are presented 
by their ligature, but the third dot is done separately (unlike in 
Visual Studio).


Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] -dWINDOWS_LIGATURE [[Re: Font ligatures support]]

[Sven Barth via lazarus]

Martin Frb via lazarus  schrieb am So., 4.
Okt. 2020, 18:05:

> On 04/10/2020 10:14, Mr Bee wrote:
>
> If it does work, would you please submit it as a patch for the next
> release? At least, add a note that the font ligatures feature only supports
> monospaced fonts and only works on Windows. It's better than nothing.
>
> revision 63951
>
> Windows only, compile with -dWINDOWS_LIGATURE
> Tested with Cascadia.
>
> If someone wants to add an option "show ligatures" ($IFDEF WINDOWS} to the
> IDE options (Editor > Display / like the anti aliasing option), then the
> feature can depend on that, and no longer needs the define.
>

Thank you! Will test when I find the time. :)


>
> On 02/10/2020 22:48, Sven Barth via lazarus wrote:
>
>  I'm using Microsoft's Cascadia Code
>
>
> According to my tests (libre office) Cascadia Mono does not do ligatures,
> but normal Cascadia works.
>

Yes, Cascadia Mono is without ligatures, Cascadia Code is with them.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Support for dark mode (on Windows 10)

[Sven Barth via lazarus]

Mr Bee via lazarus  schrieb am So., 4. Okt.
2020, 10:24:

> Is there any setting somewhere to make Lazarus follows the system color
> scheme (either dark or light mode)? Or does not Lazarus support dark mode
> yet?
>

The API for the dark mode is not officially documented and also changes
slightly between Windows 10 versions.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Font ligatures support

[Sven Barth via lazarus]

Am 02.10.2020 um 15:19 schrieb Martin Frb via lazarus:

On 02/10/2020 05:54, Mr Bee via lazarus wrote:

Hi,

It seems Lazarus’ source editor still doesn’t support font ligatures. 
I’d love to use them in Lazarus to increase the code readability as 
I’ve used them in many other code editors (using other languages too).


Some popular fonts for that are Fira Code and JetBrains Mono. I’ve 
tried both of them with Lazarus editor but the ligatures don’t work.


Is there any plan to support font ligatures in the near future? Or is 
there any special setting to enable it?




Are they strictly monospaced?


Is there something that needs to be enabled to get ligatures working on 
Windows? I'm using Microsoft's Cascadia Code for example in VS 2019 
where ligatures work correctly, but in Lazarus nothing happens. The 
ligatures have the same widths as the equal N characters (so the 
ligature for <> has the same width as both characters together).


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] How to find out why a unit is used in a project?

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am Do., 24.
Sep. 2020, 15:22:

> On Thu, 24 Sep 2020 14:22:13 +0200, Sven Barth via lazarus
>  wrote:
>
> >Well, Bo could always split the data type declarations into a separate
> >unit.
>
> But I cannot wrap my head around this (constructed example):
>
> interface
>
> type
>  TMyRecord = packed record
>Item1: word;
>Item2: Cardinal;
>   end;
>
>
> TMyController = class
>   private
> FGPIO_driver: TIoDriver;
> FGpF: TIoPort;
> function CheckValidRelay(Relay: byte): boolean;
>   public
> constructor Create;
> destructor Destroy; override;
> procedure ClearRelays;
> function PulseRelay(Relay: byte; PulseTime: LongWord): boolean;
> function RelayOff(Relay: byte): boolean;
> function RelayOn(Relay: byte): boolean;
> function RelayState(Relay: byte): boolean;
> procedure Delay(T: LongWord);
>   end;
>
> implementation
>   ...All of the methods here...
>
> AFAIK the records could be declared elsewhere but the objects not
> since their methods, constructor, destructor etc reside in the same
> file below implementation, right?
>

Would your code require the hypothetical TMyController or only the
TMyRecord? If it only requires the later then you could indeed solve this
by moving the record into a separate unit. If your code requires
TMyController as well, then it can't be left out anyway (though the
compiler will leave out any non-virtual method of that class which isn't
used).


> Just specifying a uses file with everything above the implementation
> will not cut it, right?
>

No, that will not help.

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] How to find out why a unit is used in a project?

[Sven Barth via lazarus]

R.Smith via lazarus  schrieb am Do., 24.
Sep. 2020, 12:19:

>
> On 2020/09/24 11:04, Sven Barth via lazarus wrote:
>
> Bo Berglund via lazarus  schrieb am Do.,
> 24. Sep. 2020, 08:08:
>
>>
>> >If course there is. That's how the unit system is supposed to work after
>> >all.
>> >
>> Yes, I realize that now.
>>
>> It means that the client even though it will not interface to the
>> hardware will have all of the code used to do that included in the
>> app, right?
>>
>
> The compiler (and linker) only includes code that is used. Thus as long as
> you don't call the hardware functions anywhere in your program (this
> includes indirectly or through initialization/finalization sections) then
> the code won't be in the final binary either.
>
> Regards,
> Sven
>
>
> Sven, I believe Bo's problem is that even though he won't need the Code
> (which the linker/compiler will surely cleverly disregard), he also do not
> even wish to "need" the physical Unit files to be in view of the compiler -
> at least not the secondary-dependency units - when he references a unit
> file in which he only needs a few declarations visible.
>

Well, Bo could always split the data type declarations into a separate
unit.

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] How to find out why a unit is used in a project?

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am Do., 24.
Sep. 2020, 08:08:

> On Thu, 24 Sep 2020 07:53:24 +0200, Sven Barth via lazarus
>  wrote:
>
> >Bo Berglund via lazarus  schrieb am Mi.,
> 23.
> >Sep. 2020, 21:13:
> >
> >> So there seems to be a chain reaction concerning units involved in the
> >> application
> >>
> >
> >If course there is. That's how the unit system is supposed to work after
> >all.
> >
> Yes, I realize that now.
>
> It means that the client even though it will not interface to the
> hardware will have all of the code used to do that included in the
> app, right?
>

The compiler (and linker) only includes code that is used. Thus as long as
you don't call the hardware functions anywhere in your program (this
includes indirectly or through initialization/finalization sections) then
the code won't be in the final binary either.

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] How to find out why a unit is used in a project?

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am Mi., 23.
Sep. 2020, 21:13:

> So there seems to be a chain reaction concerning units involved in the
> application
>

If course there is. That's how the unit system is supposed to work after
all.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] fpcres now supports compilation of RC files

[Sven Barth via lazarus]

Hello together!

Thanks to the work of Martok the fpcres utility is now able to compile 
RC files into RES files.


To compile an RC file to a RES file you need to pass the "-of res" 
argument as otherwise the RC reader won't be used (it's a "catch all" 
TResourceReader descendant and thus not registered by default). You can 
specify include paths for the preprocessor using "--include " and 
defines can be declared using "-D sym" (including defines with values 
using "-D sym=val").


The Free Pascal compiler is capable of using fpcres for resource 
compilation as well, but due to bootstrapping issues that currently 
needs to be enabled using a new option "-FF". Once a FPC release with a 
fpcres supporting RC files is released we'll make that option the 
default and deprecate windres/gorc (I currently plan to merge this into 
3.2.1, thus 3.2.2 would support this and future 3.3.1 (and thus 3.4) 
would then use fpcres by default).


Please test this with your applications and report your problems as this 
is the biggest change regarding resource compilation since their 
introduction.


Compatibility note: due to build dependencies the FileInfo unit was 
moved from fcl-base to fcl-extra, so please keep a look out for stale 
PPU files.


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TCheckLisBox and SelCount

[Sven Barth via lazarus]

frans via lazarus  schrieb am Di., 4. Aug.
2020, 09:36:

> Hi,
>
> The inherited SelCount function of a TCheckListBox counts the selected
> items, not the checked items which are the whole purpose of this
> component. And there is no other function available. Is this overlooked
> or judged as not necessary?
>

Items can still be selected independent of their checked state (e.g. If the
user want to (de)check multiple items at once).

There currently is no CheckedCount or something like that, you need to
manually count the elements for which Checked returns True. (Or create a
helper to simplify this)

Though you could also file a feature request for such a property to be
added.

Regards,
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Proposal: Allow Umlaute and Accented Characters in Identifiers

[Sven Barth via lazarus]

Graeme Geldenhuys via lazarus  schrieb am
So., 5. Juli 2020, 01:38:

> On 04/07/2020 9:48 pm, Sven Barth via lazarus wrote:
> > I've just tested: Delphi does not support Emojis.
>
> I've just tested with Java. They allow Unicode, but only what is
> considered "spoken language" characters. So things like Emojis, Math
> Symbols, Arrows etc are not allowed as part of the text making up
> the identifier's name.
>

They probably follow the same standard.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Proposal: Allow Umlaute and Accented Characters in Identifiers

[Sven Barth via lazarus]

Am 04.07.2020 um 22:56 schrieb Marco van de Voort via lazarus:


Op 2020-07-04 om 22:48 schreef Sven Barth via lazarus:

Am 04.07.2020 um 20:13 schrieb Graeme Geldenhuys via lazarus:

On 04/07/2020 7:11 pm, Graeme Geldenhuys via lazarus wrote:

var
    : Integer;
begin
    for  := 0 to 10 do
  writeln();
end.


And exception variables could be 濫  (nauseated face).


I've just tested: Delphi does not support Emojis. According to their 
documentation ( 
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Identifiers ) they 
adhere to ISO/IEC TR 10176:2003 ( 
https://www.iso.org/standard/37765.html ). Sadly this standard isn't 
freely available to check what is allowed and what not :/


Seems C++ (23) committee has that problem too 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1949r0.html 
they refer to the relevant annex that seems to be available 
https://unicode.org/reports/tr31/


The Unicode Standard I had linked yesterday evening already, cause I 
knew that one existed, but I didn't know about the ISO/IEC one...


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Proposal: Allow Umlaute and Accented Characters in Identifiers

[Sven Barth via lazarus]

Am 04.07.2020 um 20:13 schrieb Graeme Geldenhuys via lazarus:

On 04/07/2020 7:11 pm, Graeme Geldenhuys via lazarus wrote:

var
: Integer;
begin
for  := 0 to 10 do
  writeln();
end.


And exception variables could be 濫  (nauseated face).


I've just tested: Delphi does not support Emojis. According to their 
documentation ( 
http://docwiki.embarcadero.com/RADStudio/Sydney/en/Identifiers ) they 
adhere to ISO/IEC TR 10176:2003 ( 
https://www.iso.org/standard/37765.html ). Sadly this standard isn't 
freely available to check what is allowed and what not :/


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Proposal: Allow Umlaute and Accented Characters in Identifiers

[Sven Barth via lazarus]

Martin Frb via lazarus  schrieb am Fr., 3.
Juli 2020, 17:02:

> On 03/07/2020 16:37, Michael Van Canneyt via lazarus wrote:
> >
> >
> > On Fri, 3 Jul 2020, Martin Frb via lazarus wrote:
> >
> >> On 03/07/2020 16:21, Péter Gábor via lazarus wrote:
> >>> Hi!
> >>>
> >>> I hope that you did not misread my words/sentences.
> >>> Your example if perfect to illustrate the reason why I don't want
> >>> international characters in the language itself (and identifiers).
> >> Yes, that was my understanding.
> >>
> >> You gave reasons why it would be a bad idea. I added a reason, that I
> >> think would make the idea even worse.
> >> In other words, I supported the current a-z0-1_ set.
> >
> > I did a quick test in Delphi:
> >
> >
> > [dcc32 Error] doti.dpr(9): E2003 Undeclared identifier: 'ß'
> >
> > So indeed, case-insensitivity is lost. Even in German.
>
> And that, despite the German ß is not locale dependent. It has exactly
> one uppercase version.
> Were as "i" has 2. (But not within any one locale)
>
> I would guess that if you copy and paste, and some of your umlauts/chars
> are composed, some decomposed, that will likely not work either.
> And for composed chars with more than one combining codepoint, if the
> order of the combining codepoints does not matter, the problem will
> likely be the same.
>
> Then there are full width codepoint for some chars. (They could be
> argued to be ignored, but readability would be gone...)
> https://en.wikipedia.org/wiki/Halfwidth_and_Fullwidth_Forms_(Unicode_block)
> So "A" and "Ａ" should also be the same.
> And full width digits should be allowed in numbers.
>
> I do wonder, if Delphi accepts any of the Utf8 spaces for separating
> identifiers.
> https://www.compart.com/en/unicode/category/Zs
> and https://en.wikipedia.org/wiki/Word_divider
> Especially the zero width space
>
> And the soft hyphen? Will it be ignored, so the same identifier in
> different locations of the source can have it, or not have it?
> https://en.wikipedia.org/wiki/Soft_hyphen


It could very well be that Delphi (and other languages) follows the Unicode
Standard Annex #31 which is about Unicode Identifiers in programming
languages and also deals with case insensitive identifiers (
https://unicode.org/reports/tr31/ ).

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Laz next release- Cocoa WS

[Sven Barth via lazarus]

Alexey Tor. via lazarus  schrieb am Fr., 3.
Juli 2020, 14:07:

> IMO it's good to make Cocoa the default WS! Why? macOS is now all-64bit,
> so Carbon (old WS)+32bit apps cannot run (or run with a warning).
>

For 64-bit it already is the default now, cause otherwise 64-bit wouldn't
work as it's required for newer macOS versions.
32-bit probably stays with Carbon by default, because it doesn't matter for
older applications.

Regards
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] WinCE widgetset implementation of TCustomListbox.SelectRange: testers needed.

[Sven Barth via lazarus]

Am 11.06.2020 um 12:59 schrieb Bart via lazarus:

On Thu, Jun 11, 2020 at 12:25 PM Sven Barth via lazarus
 wrote:


Had to dust off my old Windows Mobile phone for this and get Windows
Mobile Device Center working on Windows 10, but yes, it works as on
Windows. :) (boy, that took me back ^^')

Thanks for testing and reporting back.
AFAIK we don't have an official WinCE maintainer for Lazarus ATM.


We don't have an official one for WinCE on the FPC side either, but I *do* look 
out for it, because back then ('06) it was the reason for me to switch from 
Delphi to FPC and Lazarus, so I kinda have a soft spot for it. :)

Regards,
Sven

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] WinCE widgetset implementation of TCustomListbox.SelectRange: testers needed.

[Sven Barth via lazarus]

Am 10.06.2020 um 12:12 schrieb Bart via lazarus:

Hi,

Can somebody please test the changes I made to the widgetset
implementation of TCustomListBox.SelectRange for the WinCE widgetset
in r63339.
.
It compiles and in theory it should work, but I cannot test this.

Methods to test:
TCustomListBox.SelectAll
TCustomListBox.SelectRange, with ALow and AHigh set to values other
than zero and Count-1.

Thanks in advance.


Had to dust off my old Windows Mobile phone for this and get Windows 
Mobile Device Center working on Windows 10, but yes, it works as on 
Windows. :) (boy, that took me back ^^')


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] fpWeb and server-sent events

[Sven Barth via lazarus]

Luca Olivetti via lazarus  schrieb am Do.,
4. Juni 2020, 15:51:

> El 4/6/20 a les 15:37, Michael Van Canneyt via lazarus ha escrit:
> >
> >
> > On Thu, 4 Jun 2020, Luca Olivetti via lazarus wrote:
> >
> >>>  FServer.Port:=8080;
> >>>  FServer.Threaded:=true;
> >>>  FServer.Run;
> >>>except
> >>>  on E:Exception do
> >>>  begin
> >>>writeln(E.Message);
> >>>sleep(1000);
> >>>FServer.Free;
> >>>  end;
> >>>end;
> >>
> >> Oh, and I had to do some more overriding so that the response could
> >> have a reference to the calling thread (needed if I want to use
> >> synchronize).
> >
> > That seems a bit strange, since you can do synchronize without needing
> > access to the thread object using a class method of TThread ?
>
> TThread.Synchronize needs a TThread as the first parameter.
> This is my work in progress
>

The thread parameter can be Nil. TThread will then use the CurrentThread
threadvar and failing that it can also work without any thread object.

In fact it is safer not to pass a thread.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Cannot compile LCL for Win-aarch64

[Sven Barth via lazarus]

Alexey Tor. via lazarus  schrieb am Mi., 27.
Mai 2020, 22:20:

> Win-aarch64 (arm64) is used in real hardware on Win10.
>
> installed FPC trunk with Laz trunk with Linux-x64->Win-ARM64 cross.
>

As long as the compiler can't compile itself on Windows on ARM64 I wouldn't
try anything as complicated as the LCL. I've done a testsuite run a few
days ago and there are some problems that definitely need to be addressed
first.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Where to define conditionals for FPC

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am Fr., 8.
Mai 2020, 18:03:

> Maybe I can just enclose the ifdef's in an outer layer ifdef DELPHI?
> Does the converter skip such sections during the conversion?
> Like:
>
> {$IFDEF DELPHI}
>   {$IFDEF USE_SUPERPRO}
> Sentinel,
>   {$ENDIF}
> {$ENDIF}
>
> Then Sentinel will only ever be used if built by Delphi and only if
> SUPERPRO is set, right?
>

I don't know how the converter works, so I can't tell whether any of this
will help.

However Delphi does not define a DELPHI define, so you'll have to use a
negated check for FPC instead. In your example:

{$IFNDEF FPC}
  {$IFDEF USE_SUPERPRO}
Sentinel,
  {$ENDIF}
{$ENDIF}

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Where to define conditionals for FPC

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am Fr., 8.
Mai 2020, 16:54:

> On Fri, 8 May 2020 16:34:49 +0200, Gabor Boros via lazarus
>  wrote:
>
> >2020. 05. 08. 14:07 keltezéssel, Bo Berglund via lazarus írta:
> >> I know that you can define "custom options" in Lazarus
> >> Project/Options/CompilerOptions/CustomOptions/Defines
> >>
> >> These can then be used in constructs like this example:
> >>
> >> {$IFDEF USE_LAZSERIAL}
> >> //Code pertaining to LazSerial
> >> {$ELSE}
> >> //Code pertaining to AsyncPro
> >> {$ENDIF}
> >>
> >> But if I do not want to use Lazarus, how do I set the conditionals I
> >> want to use?
> >
> >
> >Compile with "fpc ... -dUSE_LAZSERIAL".
> >
>
> I am trying to find a way to mmake the code build both in Delphi 2007
> and Lazarus and since I have used conditionals to adapt the code to
> different components and environments I need to handle these in a
> consistent manner.
> I know that I can use the Delphi and Lazarus GUI to set these
> conditional variables, but in the end I need the Delphi code (I have
> still not reached FPC/Lazarus for the complete project) to be accepted
> by the Lazarus Delphi Conversion function and then everything I think
> is read from the project sources.
> In this case since Delphi 2007 stores the settings in the dproj file
> and since the Converter does not read that file I am trying to find a
> way to set the conditionals directly in the code...
>
> Maybe in an include file, but where should that be included?


Such an include file would need to be included in all units where a define
might be needed.

Alternatively if you always use LazSerial for FPC/Lazarus you could simply
check with "$ifdef FPC" instead.

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Can't build fpc trunk x64 win32/64

[Sven Barth via lazarus]

Am 03.05.2020 um 00:53 schrieb leyba bronstain:

03.05.2020 0:05, Sven Barth пишет:
Would you please provide a directory listing (using "dir" should be 
enough) of the fpc_stable_x32\bin\i386-win32 and 
fpc_stable_x64\bin\x86_64-win64 directories? I have the feeling that 
something in there leads to this difference as that is the only thing 
you add to PATH.


Regards,
Sven


Do I understand correctly that the ppcx64 files and other files of the 
stable release of the x64 compiler are built from the stable release 
of the x32 compiler and other utilities of the binw64 folder?


Maybe you will tell me the right way, how can I build stable binutils 
x64 using stable binutils x32?


FPC only provides a 32-bit -> 64-bit cross compiler as installer and 
that is indeed made using the 32-bit compiler. Lazarus however ships 
with a native 64-bit compiler.


I don't know how you created your fpc_stable_x64\bin\x86_64-win64 
directory, but maybe that some utilities have different versions than 
the ones in the fpc_stable_x32\bin\i386-win32 directory might explain 
the problems you experience.


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Can't build fpc trunk x64 win32/64

[Sven Barth via lazarus]

Am 02.05.2020 um 23:51 schrieb leyba bronstain:


03.05.2020 0:05, Sven Barth пишет:
Would you please provide a directory listing (using "dir" should be 
enough) of the fpc_stable_x32\bin\i386-win32 and 
fpc_stable_x64\bin\x86_64-win64 directories? I have the feeling that 
something in there leads to this difference as that is the only thing 
you add to PATH.


Regards,
Sven


Hi Sven.

I have attached the result in two files, so that it is convenient for 
you to compare.


From what I can see you should be able to simply use the 
fpc_stable_x32\bin\i386-win32 directory for building the 64-bit trunk 
version as it contains a ppcrossx64.exe and the binutils (though they 
aren't used by FPC on Windows anyway).


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Can't build fpc trunk x64 win32/64

[Sven Barth via lazarus]

Am 02.05.2020 um 22:05 schrieb leyba bronstain via lazarus:


for x32

d:\Archive\development\fpc_331_r45227_x32\compiler>path=d:\Archive\development\fpc_stable_x32\bin\i386-win32;%path% 


d:\Archive\development\fpc_331_r45227_x32\compiler>echo %path%
d:\Archive\development\fpc_stable_x32\bin\i386-win32;c:\;d:\;C:\Program 
Files\Pandoc\;C:\Users\Public\Documents\Embarcadero\Studio\20.0\Bpl;c:\Program 
Files\TortoiseSVN\bin;c:\Windows\System32\;c:\Program Files\Git\bin\


[snip]


for x64

d:\Archive\development\fpc_331_r45227_x64\compiler>path=d:\Archive\development\fpc_stable_x64\bin\x86_64-win64;%path% 



d:\Archive\development\fpc_331_r45227_x64\compiler>echo %path%
d:\Archive\development\fpc_stable_x64\bin\x86_64-win64;c:\;d:\;C:\Program 
Files\Pandoc\;C:\Users\Public\Documents\Embarcadero\Studio\20.0\Bpl;c:\Program 
Files\TortoiseSVN\bin;c:\Windows\System32\;c:\Program Files\Git\bin\


Would you please provide a directory listing (using "dir" should be 
enough) of the fpc_stable_x32\bin\i386-win32 and 
fpc_stable_x64\bin\x86_64-win64 directories? I have the feeling that 
something in there leads to this difference as that is the only thing 
you add to PATH.


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Can't build fpc trunk x64 win32/64

[Sven Barth via lazarus]

Am 01.05.2020 um 01:30 schrieb leyba bronstain via lazarus:

01.05.2020 1:45, Martin Frb via lazarus пишет:

in your svn checkout dir, is a sub-directory called /compiler
It has the sources for the compiler.

And you should run that particular make command in that dir.


OMG! I thank you for the detailed explanation. Forgive me my 
misunderstanding. I don't really distinguish the subtleties of English 
¯\_(ツ)_/¯


Sorry for being unclear here...



So:

C:\Users\leyba>set 
path=d:\Archive\development\fpc_stable_x64\bin\x86_64-win64;%path%

C:\Users\leyba>cd /d d:\Archive\development\fpc_331_r45198\compiler
d:\Archive\development\fpc_331_r45198\compiler>make echotime
process_begin: CreateProcess((null), echo Start 02:10:01 now 02:10:01, 
...) failed.
make (e=2): Не удается найти указанный файл. (eng: can't find the file 
specified)

make: *** [echotime] Error 2

I start compiler building like this

make clean all install INSTALL_PREFIX=%FPC_source% 
PP=%FPC_stable_binutils%\ppcx64.exe 
DATA2INC=%FPC_source%\utils\data2inc.exe


Probably the build options should be different. I looked at the 
command line fpcupdeluxe. It applies the patch for Makefile 
(fpcpatch_all_makesearchpath_stable_3_0_4.patch)  and the command line 
options look something like this:


[2020-05-01 01:42:30.296 Info] FPCNativeInstaller (CleanModule: FPC): 
Execute: C:\fpcup\fpcbootstrap\make.exe. Params: 
--jobs=1,FPC=C:\fpcup\fpcbootstrap\ppcx64.exe,--directory=C:\fpcup\fpcsrc,FPCMAKE=C:\fpcup\fpc\bin\x86_64-win64\fpcmake.exe,PPUMOVE=C:\fpcup\fpc\bin\x86_64-win64\ppumove.exe,FPCDIR=C:\fpcup\fpcsrc,PREFIX=C:\fpcup\fpc,INSTALL_PREFIX=C:\fpcup\fpc,UPXPROG=echo,COPYTREE=echo,CPU_SOURCE=x86_64,OS_SOURCE=win64,CPU_TARGET=x86_64,OS_TARGET=win64,distclean


I might experiment with command line options.



Can you please try to execute "make echotime" (in the 
"fpc_331_r45198\compiler" directory ;) ) without any changes to the PATH 
variable?


You also said that when compiling for i386 this worked correctly. Would 
you please "echo %PATH%" before executing "make" in the directory with 
the source for both variants (i386 and x86_64)?


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Can't build fpc trunk x64 win32/64

[Sven Barth via lazarus]

Am 30.04.2020 um 23:40 schrieb leyba bronstain via lazarus:


01.05.2020 0:25, Sven Barth via lazarus пишет:

You did read the part where I said "go to the compiler directory"? ;)

Regards,
Sven



Hi Sven.

In a previous post, I went to the root directory of the compiler 
trunk(d:\Archive\development\fpc_331_r45198) and called "make 
echotime". Perhaps I misinterpreted your words :)


OK. Now I went to the root directory of the stable version of the x64 
compiler (d:\Archive\development\fpc_stable_x64\bin\x86_64-win64) and 
got the same error:


C:\Users\leyba>cd /d 
d:\Archive\development\fpc_stable_x64\bin\x86_64-win64


d:\Archive\development\fpc_stable_x64\bin\x86_64-win64>make echotime
make: *** No rule to make target `echotime'.  Stop.


I'm sorry, again, something I misunderstood?



I meant the literal "compiler" directory.

Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Can't build fpc trunk x64 win32/64

[Sven Barth via lazarus]

leyba bronstain via lazarus  schrieb am Do.,
30. Apr. 2020, 23:22:

> 30.04.2020 8:30, Sven Barth via lazarus пишет:
> > As I have written on the forum there seems to be some problem with
> > "echo" as this is the line the makefile intends to execute:
> >
> > echotime:
> > @echo Start $(STARTTIME) now $(ENDTIME)
> >
> > Would you please go to the compiler directory and manually execute
> > "make echotime" to see whether this works in principle?
> >
> > Regards,
> > Sven
>
> Hi Sven.
>
> Thank U for te answer.
>
> I tried using your advice. Here's what I got (the compiler revision
> number is specified in the paths)
>
> d:\Archive\development\fpc_331_r45198>set path= file>;%path%
>
> d:\Archive\development\fpc_331_r45198>@echo Start $(STARTTIME) now
> $(ENDTIME)
> Start $(STARTTIME) now $(ENDTIME)
>
> d:\Archive\development\fpc_331_r45198>make echotime
> make: *** No rule to make target `echotime'.  Stop.
>

You did read the part where I said "go to the compiler directory"? ;)

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Can't build fpc trunk x64 win32/64

[Sven Barth via lazarus]

Am 20.04.2020 um 22:56 schrieb leyba bronstain via lazarus:

Hi guys. I need your help.

I try build trunk compiler x64 for windows. I was extract stable 
release fpc_x64 form lazarus-2.0.8-fpc-3.0.4-win64.exe installer and 
put it to separate folder fpc_stable_x64. Also I put into 
fpc_stable_x64 folder bingw64 folder and fixed the file fpc.cfg as 
follows:


--- code --
    # searchpath for tools
-FDD:\Archive\development\fpc_stable_x64/bin/$FPCTARGET

    # it's doesn't work!
    -FDD:\Archive\development\fpc_stable_x64/binw64/
--- code ---

Then I run the bat-file as follows:

--- code ---
    set FPC_source={}
    set FPC_binutils={}\bin\x86_64-win64
    set FPC_stable_binutils={fpc_stable_x64 root directory 
path}\bin\x86_64-win64


    :: so it works!
    set binw64_path={fpc_stable_x64 root directory path}/binw64
    set path=;%path%

    ...
    cd /d %FPC_source%
    make clean all install INSTALL_PREFIX=%FPC_source% 
PP=%FPC_stable_binutils%\ppcx64.exe 
DATA2INC=%FPC_source%\utils\data2inc.exe

    ...
--- code ---

During compilation I get an error:

--- code ---
    ...
d:/Archive/development/fpc_stable_x64/bin/x86_64-win64/mv.exe -f 
x86_64/bin/x86_64-win64/pp.exe ppcx64.exe
    make[5]: Leaving directory 
`d:/Archive/development/fpc_331_r44725_x64/compiler'

    make echotime
    make[5]: Entering directory 
`d:/Archive/development/fpc_331_r44725_x64/compiler'
    process_begin: CreateProcess((null), echo Start now 19:52:42, ...) 
failed.
    make (e=2): Не удается найти указанный файл. The system cannot find the file specified>

    make[5]: *** [echotime] Error 2
    make[5]: Leaving directory 
`d:/Archive/development/fpc_331_r44725_x64/compiler'

    make[4]: *** [next] Error 2
    make[4]: Leaving directory 
`d:/Archive/development/fpc_331_r44725_x64/compiler'

    make[3]: *** [ppc1.exe] Error 2
    make[3]: Leaving directory 
`d:/Archive/development/fpc_331_r44725_x64/compiler'

    make[2]: *** [cycle] Error 2
    make[2]: Leaving directory 
`d:/Archive/development/fpc_331_r44725_x64/compiler'

    make[1]: *** [compiler_cycle] Error 2
    make[1]: Leaving directory 
`d:/Archive/development/fpc_331_r44725_x64'

    make: *** [build-stamp.x86_64-win64] Error 2
    ...
--- code ---


What am I doing wrong?  Can someone tell me a link to a detailed manual?



As I have written on the forum there seems to be some problem with 
"echo" as this is the line the makefile intends to execute:


echotime:
    @echo Start $(STARTTIME) now $(ENDTIME)

Would you please go to the compiler directory and manually execute "make 
echotime" to see whether this works in principle?


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Completely solve the GTK trouble

[Sven Barth via lazarus]

jiaxing ruan  schrieb am Di., 14. Apr. 2020,
15:03:

> We have no control over GTK, too. IUP is better in this regard as it
> doesn't change as much as GTK. IUP is much smaller than GTK, too. Creating
> binding for IUP I only have to use h2pas. I don't think h2pas is able to
> create binding for the whole GTK stuffs, which also include GDK, ATK,
> GObject, GLib... I know about gir2pascal, but if it good enough why our GTK
> binding is too bad?
>

Adding another level of abstraction between the LCL and the underlying
toolkit will result in more problems. What if we need something for the LCL
that is available in GTK, but not in IUP?


> @Sven Barth  I tried with Lazarus trunk +
> FPC trunk from Fpcupdeluxe, built using Win64 interface but after that I
> configured to rebuild it with GTK3 inferface and it failed immediately. So
> I don't know how could I help testing Lazarus GTK3 as even build it is
> impossible. I installed GTK3 runtime and MinGW 8.1, both properly added to
> PATH. Does a Linux machine absolutely needed? I only do Windows stuffs so I
> afraid I can't help with that.
>

I have never tested GTK on Windows, so I can't comment here. My suggestion
is indeed to use a Linux. Though if you have a Windows 10 you could also
use Windows Subsystem for Linux with a X server on the Windows side.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Completely solve the GTK trouble

[Sven Barth via lazarus]

jiaxing ruan via lazarus  schrieb am Di.,
14. Apr. 2020, 05:59:

> GTK changes too fast and our GTK3 binding is not updated. We don't have to
> resource to catch up GTK. I suggest we abandon the GTK3 and any later GTK
> version interface and instead create an IUP interface. IUP uses GTK
> underlying, so we don't miss anything. Our apps will look just like when
> they use the GTK widgetset. IUP focuses more on compatibility than GTK.
> Even software written for IUP 3.15 could easily compiled and run with IUP
> 3.27. IUP also has a permissive license. As far as I know IUP is as
> portable as Lazarus is, so we don't have to care about portability, too.
>
> Let me see what's your thoughts.
>
> With my ability I can only leave suggestion. I don't have the skill to do
> it myself nor the finance to hire someone else to do. But I think this is
> the most reasonable move for us.
>

We don't need to run after the latest GTK version. Even other applications
like GIMP or desktop environments like XFCE switch to GTK3 only now,
because it has become stable. So in fact this is the right point to get
GTK3 fully running and there has already been work put into the last
months. What's missing is people testing it, reporting bugs and maybe also
people who are willing to dig into it to fix those bugs.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Online Package Manager errors ?

[Sven Barth via lazarus]

Balázs Székely via lazarus  schrieb am Mo.,
13. Apr. 2020, 20:08:

>
> I have a naive suggestion for OPM. Some components depends on external
>> libraries/binaries (libffi, openssl, libsagui etc.), so it would be nice
>> any field like "Libraries", or "Dependencies", or even "External files"
>> inside the "Package info", providing previous information that the package
>> needs external libraries/files to work properly. (sorry if it is already
>> implemented, I'm using Lazarus 2.0.6)
>>
> Thanks for the suggestion. In my opinion the external libraries should be
> shipped with the package(if possible). Adding a new entry in the package
> tree it's not a problem, it can be done in 15-20 minutes, however the list
> already has a "Christmas tree" feeling to it. Any extra info should be
> added to the "package description"  or "community description" entries,
> which can be opened in a separate form.
>

I don't agree. Especially on Linux (and the BSDs probably as well) that is
part of the OS' package manager, even for macOS there is an open source one
that one can install to handle such things. So a list of required
dependencies would be enough.

This list would also be useful for deployment of the final application
however so that one can either set up an installer / package correctly or
report to the user in a Readme or so what libraries are required.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] RFC: Selection Editors to extend handling of object inspector selections

[Sven Barth via lazarus]

Juha Manninen via lazarus  schrieb am Di.,
31. März 2020, 13:40:

> On Sun, Nov 10, 2019 at 11:26 PM Sven Barth via lazarus <
> lazarus@lists.lazarus-ide.org> wrote:
>
>> I've got a RFC for a feature that allows to extend the IDE. It's based
>> on something that Delphi supports as well: Selection Editors.
>>
>
> I finally took a proper look at this. First remark without testing is that
> unit SelEdits should be in LCL instead of IdeIntf.
> It says
>  Abstract:
>This unit contains selection editors for various LCL components.
>
> Thus it is not needed by external IDE plugin packages which use IdeIntf.
> I will test the patches later.
>

Thank you for taking a first look.

The problem is that selection editors derive from TBaseSelectionEditor
which in turn depends on IdeIntf functionality.

Also they are only really required inside the IDE (for third party
components they'd be part of a design time package), not during runtime of
the application.

In that sense they are similar to component editors which are in IdeIntf as
well (e.g. TFlowPanelComponentEditor in unit ComponentEditors).

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] The Problem with the Linux Desktop

[Sven Barth via lazarus]

leledumbo via lazarus  schrieb am So., 29.
März 2020, 05:48:

> > The model to download applications and install on a random distro+version
> simply doesn't exist on Linux.
>
> Snap, AppImage, Flatpak are purposely targeting this. It's partially
> successful, but as with many things in Linux, they're competing instead of
> working together.
>

And if there's a security problem in one of the used libraries you need to
update all these containers instead of just updating the library - if the
provider of the container even provides an updated container. Yay. Not. -.-

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] GTK3 widgets on macOS?

[Sven Barth via lazarus]

Ryan Joseph via lazarus  schrieb am Mo., 25.
Nov. 2019, 20:19:

>
>
> > On Nov 25, 2019, at 2:07 PM, Sven Barth via lazarus <
> lazarus@lists.lazarus-ide.org> wrote:
> >
> > You'll likely expect wrong considering that GTK is rather Unix centric
> and doesn't like to deal with the platformisms of other platforms (both
> Windows and macOS).
> > You'll likely have to look for a libgtk.3.dylib or so and you'll need to
> adjust the import library names in the GTK3 units.
> >
>
> I see in LazGdk3.pas there is a $LINKLIB line which is wrong. On my system
> at /usr/local/Cellar/gtk+3/3.24.5/lib there is a libgtk-3.dylib which I can
> link to. I changde these to this:
>
> {$LINKLIB libgtk-3.dylib}
> {$LINKLIB libgdk-3.dylib}
>
> I then added -Fl/usr/local/Cellar/gtk+3/3.24.5/lib to the command line but
> I still get a linker error "Error: ld: library not found for -lgtk-3"
>
> For proof:
>
> ls /usr/local/Cellar/gtk+3/3.24.5/lib
> girepository-1.0  libgailutil-3.dylib   libgtk-3.0.dylib
> gtk-3.0   libgdk-3.0.dylib  libgtk-3.dylib
> libgailutil-3.0.dylib libgdk-3.dylibpkgconfig
>
> Is that not correct?
>

Should be. 樂

Would you please compile with -sh option which will generate a ppas.sh file
(I think) in the output directory (I think as well) which will contain the
command line the linker will be called with and check that? Maybe you can
then pass some verbosity switch to the linker to find out what goes
wrong...

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] GTK3 widgets on macOS?

[Sven Barth via lazarus]

Ryan Joseph via lazarus  schrieb am Mo., 25.
Nov. 2019, 19:37:

> Is it possible to build projects using the GTK3 widget set while on Mac? I
> know GTK3 is cross platform itself so it should be possible to use this
> instead of the Cocoa widgets right?
>
> I try to build and I get pretty far until there is a linker error looking
> for a .so file:
>
> Error: ld: library not found for -lgtk-3.so.0
>
> On macOS I would expect this to be a framework, not a .so file. Any ideas?
>

You'll likely expect wrong considering that GTK is rather Unix centric and
doesn't like to deal with the platformisms of other platforms (both Windows
and macOS).
You'll likely have to look for a libgtk.3.dylib or so and you'll need to
adjust the import library names in the GTK3 units.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Cross-compile for Linux strange behaviour with floating point constants

[Sven Barth via lazarus]

Am 20.11.2019 um 19:19 schrieb R Smith via lazarus:
Is there something I can check on my side? Does this work for others? 
Might this be a cross-compile bug of sorts?  Is this some FPC, FPU or 
Linux peculiarity I'm not aware of?
Win64 is essentially the only x86 platform that does *not* support and 
use the Extended type. Thus a cross compiler from x86_64-win64 to any 
other i8086, i386 or x86_64 target will result in strange or undefined 
behavior due to it not providing the Extended constants correctly. To 
solve this you need to compile your code on a Linux system (you can use 
WSL without any problems) or make sure that you only use Double (you 
also need to cast floating point constants to Double in that case as 
otherwise FPC tries to use Extended nevertheless, which is why the 
variable in your example works, but the constant does not).


There is the plan to add software floating point support for Extended to 
the compiler for platforms like Win64, but it's not a trivial endeavour. 
Please note that cross compiling from any other platform that does not 
support Extended to x86 will have the same problem (except when cross 
compiling to Win64).


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] RFC: Selection Editors to extend handling of object inspector selections

[Sven Barth via lazarus]

Am 10.11.2019 um 22:26 schrieb Sven Barth:

Hello together!

I've got a RFC for a feature that allows to extend the IDE. It's based 
on something that Delphi supports as well: Selection Editors.
Unlike Component Editors these are supposed to be used to interact 
with a specific selection in the designer and (in Delphi) allow the 
following extensions:
- adding menu items for the context menu for the selection (like 
component editors)
- add additional units when the component is dropped onto the form 
(though I wonder why that isn't part of component editors)

- add or remove properties to/from the object inspector for the selection

My current RFC only implements the last one and also a bit different 
than Delphi does cause they added that functionality only later (see 
below).


Due to their dependencies Selection Editors live in the PropEdits unit 
and like component and property editors they are registered at an 
approbriate location (be it some Register function or a unit 
initialization). When the object inspector requests the properties it 
also checks all selection editors involved in the selection (included 
the parent classes) and calls the selection editor's FilterProperties 
method if GetAttributes contains seaFilterProperties (Delphi does not 
provide a GetAttributes method, instead it provides FilterProperties 
through an interface that needs to be implemented by a selection editor).
FilterProperties receives both the current selection of the object 
inspector as well as the list of property editors. It is then free to 
add or remove property editors as it sees fit.
The behavior when collecting the property editors is such that 
multiple FilterProperties methods might be called on the same 
selection, thus it might received an already filtered property editor 
list.


I've attached a patch that implements selection editors 
(selection-editors.patch) as well as an example implementation for a 
component that Lazarus already supports and Delphi provides a 
selection editor for: TFlowPanel (tflowpanel-seledit.patch). For that 
component for each child control a virtual ControlIndex property is 
exposed which allows to easily change the order of the components in 
the object inspector instead of going through some collection editor. 
Also the Top and Left properties are removed as they aren't useful for 
such components. Delphi behaves the same here.


Another example use would be TGridPanel which we don't have yet: it 
allows to implement the Row- and ColumnSpan properties on each child 
control of the panel.


To work correctly I also had to adjust the object inspector a little 
bit (respect-parevertable.patch), cause it is not using only the 
virtual functions provided by TPropertyEditor: namely to respect the 
paRevertable attribute and only initialize and use the undo values if 
the property is deemed revertable. For demonstration purposes I've 
disabled the paRevertable attribute for the ControlIndex property 
editor, cause otherwise there'd be an exception when the object 
inspector tries to read the original value. It would be better if the 
object inspector would only call virtual methods of TPropertyEditor 
however or ones that can be easily faked (like I did by faking a 
TPropInfo entry, though that does not feel really nice either).


Suggestions and criticism are welcome though I can't tell how much 
time I currently can and want to invest to improve this further. It 
might also need some step-by-step improvement of the existing 
TPropertyEditor interface to function smoothly.


Really? No further interest here? I don't want to put it on Mantis yet, 
because I'm not yet sure whether everything is alright and Mantis is not 
a discussion platform...


Regards,
Sven
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Why is there a define switch UseCThreads?

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am Mo., 11.
Nov. 2019, 08:38:

> On Mon, 11 Nov 2019 00:20:59 +0100, Sven Barth via lazarus
>  wrote:
>
> >Bo Berglund via lazarus  schrieb am So.,
> 10.
> >Nov. 2019, 23:29:
> >
> >> I have ported a console application from Windows to Linux (Raspbian
> >> Buster) and I got to wonder about the check for a defined symbol
> >> appearing in the beginning of the code as produced by the Lazarus
> >> template:
> >>
> >> uses
> >>   {$IFDEF UNIX}{$IFDEF UseCThreads}
> >>   cthreads,
> >>   {$ENDIF}{$ENDIF}
> >>
> >> Would it not be enough to use this instead:
> >> uses
> >>   {$IFDEF UNIX}
> >>   cthreads,
> >>   {$ENDIF}
> >>
> >> Is there a heavy hit on perfortmance or such if the conditional is not
> >> used but instead just checking if we are on UNIX?
> >>
> >> What happens if one does not use threads in ones code but removes the
> >> conditional UseCThreads as shown above?
> >>
> >> For example if I am using Indy10 objects they are threaded so in that
> >> case I assume I need to use cthreads. But in any other case, how can I
> >> know that some used package might rely on threads and so needs this
> >> uses clause?
> >>
> >> Basically:
> >> What damage does it do if cthreads are in the uses clause but no
> >> thread appears in the program code (yet)?
> >>
> >
> >The "damage" is that your application will link against the C library.
> >Sometimes that's not desirable and quite some FPC code can be used without
> >that (e.g. the compiler itself does not need to link against the C library
> >and thus the binary is usable on various Linux distributions and
> versions).
> >
>
> So if one does not enable use of cthreads there are still threads
> available also on Linux?
> I interpreted the existence of this switch as "if you want to use
> threads on Linux you need to enable UseCThreads"...
>
> If I do not have cthreads as a uses item but still want to use for
> example Indy10, will it still work?
>

You asked what the damage is if one does not use threads.

If you use threads then you *must* use the cthreads unit on Unix platforms.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Why is there a define switch UseCThreads?

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am So., 10.
Nov. 2019, 23:29:

> I have ported a console application from Windows to Linux (Raspbian
> Buster) and I got to wonder about the check for a defined symbol
> appearing in the beginning of the code as produced by the Lazarus
> template:
>
> uses
>   {$IFDEF UNIX}{$IFDEF UseCThreads}
>   cthreads,
>   {$ENDIF}{$ENDIF}
>
> Would it not be enough to use this instead:
> uses
>   {$IFDEF UNIX}
>   cthreads,
>   {$ENDIF}
>
> Is there a heavy hit on perfortmance or such if the conditional is not
> used but instead just checking if we are on UNIX?
>
> What happens if one does not use threads in ones code but removes the
> conditional UseCThreads as shown above?
>
> For example if I am using Indy10 objects they are threaded so in that
> case I assume I need to use cthreads. But in any other case, how can I
> know that some used package might rely on threads and so needs this
> uses clause?
>
> Basically:
> What damage does it do if cthreads are in the uses clause but no
> thread appears in the program code (yet)?
>

The "damage" is that your application will link against the C library.
Sometimes that's not desirable and quite some FPC code can be used without
that (e.g. the compiler itself does not need to link against the C library
and thus the binary is usable on various Linux distributions and versions).

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] RFC: Selection Editors to extend handling of object inspector selections

[Sven Barth via lazarus]

Hello together!

I've got a RFC for a feature that allows to extend the IDE. It's based 
on something that Delphi supports as well: Selection Editors.
Unlike Component Editors these are supposed to be used to interact with 
a specific selection in the designer and (in Delphi) allow the following 
extensions:
- adding menu items for the context menu for the selection (like 
component editors)
- add additional units when the component is dropped onto the form 
(though I wonder why that isn't part of component editors)

- add or remove properties to/from the object inspector for the selection

My current RFC only implements the last one and also a bit different 
than Delphi does cause they added that functionality only later (see below).


Due to their dependencies Selection Editors live in the PropEdits unit 
and like component and property editors they are registered at an 
approbriate location (be it some Register function or a unit 
initialization). When the object inspector requests the properties it 
also checks all selection editors involved in the selection (included 
the parent classes) and calls the selection editor's FilterProperties 
method if GetAttributes contains seaFilterProperties (Delphi does not 
provide a GetAttributes method, instead it provides FilterProperties 
through an interface that needs to be implemented by a selection editor).
FilterProperties receives both the current selection of the object 
inspector as well as the list of property editors. It is then free to 
add or remove property editors as it sees fit.
The behavior when collecting the property editors is such that multiple 
FilterProperties methods might be called on the same selection, thus it 
might received an already filtered property editor list.


I've attached a patch that implements selection editors 
(selection-editors.patch) as well as an example implementation for a 
component that Lazarus already supports and Delphi provides a selection 
editor for: TFlowPanel (tflowpanel-seledit.patch). For that component 
for each child control a virtual ControlIndex property is exposed which 
allows to easily change the order of the components in the object 
inspector instead of going through some collection editor. Also the Top 
and Left properties are removed as they aren't useful for such 
components. Delphi behaves the same here.


Another example use would be TGridPanel which we don't have yet: it 
allows to implement the Row- and ColumnSpan properties on each child 
control of the panel.


To work correctly I also had to adjust the object inspector a little bit 
(respect-parevertable.patch), cause it is not using only the virtual 
functions provided by TPropertyEditor: namely to respect the 
paRevertable attribute and only initialize and use the undo values if 
the property is deemed revertable. For demonstration purposes I've 
disabled the paRevertable attribute for the ControlIndex property 
editor, cause otherwise there'd be an exception when the object 
inspector tries to read the original value. It would be better if the 
object inspector would only call virtual methods of TPropertyEditor 
however or ones that can be easily faked (like I did by faking a 
TPropInfo entry, though that does not feel really nice either).


Suggestions and criticism are welcome though I can't tell how much time 
I currently can and want to invest to improve this further. It might 
also need some step-by-step improvement of the existing TPropertyEditor 
interface to function smoothly.


Regards,
Sven
Index: components/ideintf/propedits.pp
===
--- components/ideintf/propedits.pp (revision 62212)
+++ components/ideintf/propedits.pp (working copy)
@@ -23,7 +23,7 @@
 
 uses
   // RTL / FCL
-  Classes, TypInfo, SysUtils, types, RtlConsts, variants, Contnrs, strutils,
+  Classes, TypInfo, SysUtils, types, RtlConsts, variants, Contnrs, strutils, 
FGL,
   // LCL
   LCLType, LCLIntf, LCLProc, Forms, Controls, GraphType, ButtonPanel, Graphics,
   StdCtrls, Buttons, Menus, ExtCtrls, ComCtrls, Dialogs, EditBtn, Grids, 
ValEdit,
@@ -416,7 +416,9 @@
   end;
 
   TPropertyEditorClass=class of TPropertyEditor;
-  
+
+  TPropertyEditorList = specialize TFPGObjectList;
+
 { THiddenPropertyEditor
   A property editor, to hide a published property. If you can't unpublish it,
   hide it. }
@@ -1180,6 +1182,39 @@
   TDateTimeProperty =   TDateTimePropertyEditor;
 
 
+type
+  TSelectionEditorAttribute = (
+seaFilterProperties
+  );
+  TSelectionEditorAttributes = set of TSelectionEditorAttribute;
+
+  { TBaseSelectionEditor }
+
+  TBaseSelectionEditor = class
+constructor Create({%H-}ADesigner: TIDesigner; {%H-}AHook: 
TPropertyEditorHook); virtual;
+function GetAttributes: TSelectionEditorAttributes; virtual; abstract;
+procedure FilterProperties(ASelection: TPersistentSelectionList; 
AProperties: TPropertyEditorList); virtual; abstract;
+  end;
+
+  

Re: [Lazarus] Annoying code completion failure

[Sven Barth via lazarus]

Ondrej Pokorny via lazarus  schrieb am So.,
3. Nov. 2019, 23:15:

>
> On 03.11.2019 17:49, Sven Barth via lazarus wrote:
>
> Ondrej Pokorny via lazarus  schrieb am
> So., 3. Nov. 2019, 11:21:
>
>> On 02.11.2019 11:23, Michael Van Canneyt via lazarus wrote:
>> > TStrings has a property
>> >
>> > property Values[const Name: string]: string read GetValue write
>> > SetValue;
>> >
>> > The setter is defined as:
>> >
>> > procedure SetValue(const Name, Value: string);
>> >
>> > Note that both arguments are 'const'
>> >
>> > When adding a new property, and pressing 'CTRL-C', the IDE adds the new
>> > property, but also insists on adding a new SetValue:
>> >
>> > procedure SetValue(const Name: string; AValue: string);
>> >
>> > Note the missing const on the second parameter.
>> >
>> > It does this of course not only for TStrings, but for all such
>> properties.
>>
>> The problem is not the const - Lazarus can ignore it. The problem is
>> that the parameters are joined - that is what Lazarus cannot handle.
>>
>> Replace
>>  procedure SetValue(const Name, Value: string);
>> with
>>  procedure SetValue(const Name: string; const Value: string);
>>
>> then Lazarus won't add it every time you do class completion. I know -
>> it's not what you currently have in the interface, but the difference is
>> just cosmetic. I usually let Lazarus do its job and don't care that the
>> parameters are separated.
>>
>
> This is not what one wants to hear.
>
> Well, I just explained the current state. It doesn't mean it cannot be
> improved.
>
>
> Lazarus really likes to mess with existing code and it's one of the main
> reasons I'm *not* using class completion inside the compiler, cause
> otherwise I can be sure that the whole remaining class is changed as well
> -.-
>
> To be honest, the compiler code style is very quirky :)
>

Pressed "Send" too soon -.-

I won't argue that point. Nevertheless the IDE should not generate more
work :P

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Annoying code completion failure

[Sven Barth via lazarus]

Ondrej Pokorny via lazarus  schrieb am So.,
3. Nov. 2019, 23:15:

>
> On 03.11.2019 17:49, Sven Barth via lazarus wrote:
>
> Ondrej Pokorny via lazarus  schrieb am
> So., 3. Nov. 2019, 11:21:
>
>> On 02.11.2019 11:23, Michael Van Canneyt via lazarus wrote:
>> > TStrings has a property
>> >
>> > property Values[const Name: string]: string read GetValue write
>> > SetValue;
>> >
>> > The setter is defined as:
>> >
>> > procedure SetValue(const Name, Value: string);
>> >
>> > Note that both arguments are 'const'
>> >
>> > When adding a new property, and pressing 'CTRL-C', the IDE adds the new
>> > property, but also insists on adding a new SetValue:
>> >
>> > procedure SetValue(const Name: string; AValue: string);
>> >
>> > Note the missing const on the second parameter.
>> >
>> > It does this of course not only for TStrings, but for all such
>> properties.
>>
>> The problem is not the const - Lazarus can ignore it. The problem is
>> that the parameters are joined - that is what Lazarus cannot handle.
>>
>> Replace
>>  procedure SetValue(const Name, Value: string);
>> with
>>  procedure SetValue(const Name: string; const Value: string);
>>
>> then Lazarus won't add it every time you do class completion. I know -
>> it's not what you currently have in the interface, but the difference is
>> just cosmetic. I usually let Lazarus do its job and don't care that the
>> parameters are separated.
>>
>
> This is not what one wants to hear.
>
> Well, I just explained the current state. It doesn't mean it cannot be
> improved.
>

Maybe Michael should file a bug report then... (and I should collect my
annoyances as well :P)

>
> Lazarus really likes to mess with existing code and it's one of the main
> reasons I'm *not* using class completion inside the compiler, cause
> otherwise I can be sure that the whole remaining class is changed as well
> -.-
>
> To be honest, the compiler code style is very quirky :)
>
> Ondrej
> --
> ___
> lazarus mailing list
> lazarus@lists.lazarus-ide.org
> https://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Annoying code completion failure

[Sven Barth via lazarus]

Ondrej Pokorny via lazarus  schrieb am So.,
3. Nov. 2019, 11:21:

> On 02.11.2019 11:23, Michael Van Canneyt via lazarus wrote:
> > TStrings has a property
> >
> > property Values[const Name: string]: string read GetValue write
> > SetValue;
> >
> > The setter is defined as:
> >
> > procedure SetValue(const Name, Value: string);
> >
> > Note that both arguments are 'const'
> >
> > When adding a new property, and pressing 'CTRL-C', the IDE adds the new
> > property, but also insists on adding a new SetValue:
> >
> > procedure SetValue(const Name: string; AValue: string);
> >
> > Note the missing const on the second parameter.
> >
> > It does this of course not only for TStrings, but for all such
> properties.
>
> The problem is not the const - Lazarus can ignore it. The problem is
> that the parameters are joined - that is what Lazarus cannot handle.
>
> Replace
>  procedure SetValue(const Name, Value: string);
> with
>  procedure SetValue(const Name: string; const Value: string);
>
> then Lazarus won't add it every time you do class completion. I know -
> it's not what you currently have in the interface, but the difference is
> just cosmetic. I usually let Lazarus do its job and don't care that the
> parameters are separated.
>

This is not what one wants to hear. Lazarus really likes to mess with
existing code and it's one of the main reasons I'm *not* using class
completion inside the compiler, cause otherwise I can be sure that the
whole remaining class is changed as well -.-

Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus code editor improvement?

[Sven Barth via lazarus]

Martin Frb via lazarus  schrieb am Sa., 2.
Nov. 2019, 16:29:

> You mention using  RealVNC in another mail.
>
> IIRC there were some very strange key effects reported with vnc in the
> past (no idea if that applies to RealVNC).
>  From distant memory, vnc sends control keys with a timestamp that does
> not match the interpretation that I would have from the doc of this
> field That said I have no idea if vnc is right or not.
> There is an argument that it works with other apps, but that is void,
> because other apps may not use this (timestamp) field at all, and then
> if it was wrong they would ignore that. Not sure what happened with
> regards to this entire story.
>

I myself had reported something similar with VNC, so it's indeed likely to
be the culprit.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus code editor improvement?

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am Sa., 2.
Nov. 2019, 14:59:

> On Sat, 02 Nov 2019 11:10:32 +0100, Bo Berglund via lazarus
>  wrote:
>
> I just found another strange IDE "feature":
>
> If I am in a tab to the right (not the left-most tab) with the cursor
> anywhere in the code and I want to add say a { character, I need to
> press AltGr (the right hand Alt key) and the 7 key. This normally
> results in a { character being output at the cursor.
>
> But in Lazarus the focus immediately shifts to a different tab when
> AltGr is pressed!!
> How did that happen? All European languages to my knowledge uses the
> AltGr key to compose special chars like {[]}\|~
> Why is Lazarus stealing the AltGr key?
>

Check the key mappings in Lazarus' options.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Separation of source code and compiled units

[Sven Barth via lazarus]

Karl-Michael Schindler via lazarus  schrieb
am Sa., 2. Nov. 2019, 11:27:

> Hi
>
> I am working on the package description for lazarus for MacPorts and are
> struggling with the following: $PREFIX/share/lazarus contains the source
> code as well as the compiled units. In case lazarus is recompiled the
> directory $PREFIX/share/lazarus needs to be writable by all users. At least
> this is as far as I got. Is there a way to keep the source files readonly
> and place the compiled files somewhere separate? How has this been dealt
> with for linux?
>

If I remember correctly then Lazarus recompiles itself into a directory in
the user's home directory if the original isn't writable.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus code editor improvement?

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am Sa., 2.
Nov. 2019, 11:10:

> Is this possible already (but hidden in the standard config of
> Lazarus) or is it a new feature noone has requested before?
>

Tools -> Options -> Codetools -> General -> Jump directly to method body

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Multi-platform console application, how to handle file paths?

[Sven Barth via lazarus]

Graeme Geldenhuys via lazarus  schrieb am
Di., 29. Okt. 2019, 21:08:

> On 29/10/2019 12:07 pm, Bo Berglund via lazarus wrote:
> > I have been around too long so I
> > remember the old days...
>
> Same. Windows should get with the times and switch to Unix. ;-)
>
> On a side note:
> After all, Windows still start the drive letters with C: and considering
> that no PC is the last decade or two has shipped with floppy drives,
> maybe they could start from A: instead. Most of the people I work with
> have NO idea why Windows starts with C: as the boot drive instead of A: :-P
>

There is still enough software out there that assumes A: and B: are floppy
drives and thus either ignores them or handles them especially (I fixed
such a relic in our own software just two weeks ago, because a customer had
his optical drives as A: and B:, otherwise we wouldn't have noticed that...
).

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Code explorer implementation

[Sven Barth via lazarus]

Ryan Joseph via lazarus  schrieb am Sa., 14.
Sep. 2019, 20:18:

>
>
> > On Sep 14, 2019, at 2:07 PM, Michael Van Canneyt via lazarus <
> lazarus@lists.lazarus-ide.org> wrote:
> >
> > By default, FPC also does not allow C style operators.
> >
> > You need to provide the -Sc command-line flag to the parser or set the
> appropriate flag manually on the parser object.
>
> I tried using -Mobjfpc because I know c style operators are a mode switch
> but that didn’t work. I guess modes are not supported in the parser and we
> need to use all the various -S flags?
>

As I already wrote some time ago C-style operators are *not* enabled by
default in any of the modes. Also they aren't a modeswitch either. They are
simply switched on inside the default fpc.cfg using the -Sc option. Thus,
as Michael wrote, you need to pass that parameter as well or explicitly set
the corresponding flag of the parser object.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] [fpc-pascal] Tests results of several pascal based JSON parsers

[Sven Barth via lazarus]

Am 31.08.2019 um 11:08 schrieb Sven Barth:

Am 31.08.2019 um 09:45 schrieb Michael Van Canneyt via lazarus:
Codepages & strings require careful setup. Contrary to popular 
belief, it does not 'just work'.


All this is documented:

https://www.freepascal.org/docs-html/current/ref/refsu9.html#x32-390003.2.4 



Many people tend to ignore this, because Lazarus does a lot behind 
the scenes (which is a good thing).
Looking at the text of the "Code page conversions" section: what do 
these mean: (CODE_CP ¡¿ CP_ACP) ? Or should it have been (CODE_CP <> 
CP_ACP)?
And there's another one in the section "UTF8String" at the bottom: 
(ordinal value ¡128) Should this have been (ordinal value < 128)?


Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] [fpc-pascal] Tests results of several pascal based JSON parsers

[Sven Barth via lazarus]

Am 31.08.2019 um 09:45 schrieb Michael Van Canneyt via lazarus:
Codepages & strings require careful setup. Contrary to popular belief, 
it does not 'just work'.


All this is documented:

https://www.freepascal.org/docs-html/current/ref/refsu9.html#x32-390003.2.4 



Many people tend to ignore this, because Lazarus does a lot behind the 
scenes (which is a good thing).
Looking at the text of the "Code page conversions" section: what do 
these mean: (CODE_CP ¡¿ CP_ACP) ? Or should it have been (CODE_CP <> 
CP_ACP)?


Regards,
Sven
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TProgressbar moves slowly, is there a hidden setting for faster response?

[Sven Barth via lazarus]

Bo Berglund via lazarus  schrieb am Mi., 15.
Mai 2019, 17:11:

> On Wed, 15 May 2019 13:38:19 +0200, Ondrej Pokorny via lazarus
>  wrote:
>
> >Because WinAPI developers wanted it so - the drawing of TProgressBar is
> >fully in charge of the OS.
>
> Strangely just discovered that the progressbar is painted "fast
> enough" if I click a position towards the lower side of the current
> position!
>
> So start and click towards the end (max) - it slowly paints the bar.
> Then click towards the start (min) - it *immediately* paints it
> correctly.
>
> There *must* be a way to enforce the latter paint method also for
> positive moves
>
> I really do not want to create a panel child to implement this
> behaviour unless I am really forced to
>

One possible workaround I found (not tested) is this:

=== code begin ===

YourProgressbar.Position := YourTarget;
YourProgressbar.Position := Your Target - 1;
YourProgressbar.Position := YourTarget;

=== code end ===

You first tell the progress bar your new desired target value (which
triggers a slow animation), then you go one step back (which will enforce a
fast redraw) and then to the target again (which again will be a slow
animation, but shouldn't be that slow with only one point difference).

Note: I currently don't know whether the property on TProgressBar is
Position or Value. It's been a while since I last used one ;)

Note 2: you can put similar code into the click handler, though there
without the first step probably.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lots of access violations with TSQLConnection TSQLQuery on Linux

[Sven Barth via lazarus]

Anthony Walter via lazarus  schrieb am Do.,
4. Apr. 2019, 02:15:

> I don't normally use the Lazarus MS SQL components, but tried using them
> today on Ubuntu Linux and keep experiencing lots of random access
> violations. I wanted to know if this is a normal thing, or if perhaps the
> state of these components is fragile on Linux.
>
> Here is what is happening.
>
> I can place the TSQLConnection, TSQLTransaction, TSQLQuery, TDataSource
> and  data aware controls on a form and connect to the database at design
> time. It works fine. I can run my program and I can view and edit records
> just fine. But if I change any part of TSQLQuery down to TSQLConnection
> setting Active to False, then I get access violations.
>
> This is particularly problematic because certain changes to component
> properties require Active to be set to False, such as editing SQL. And very
> often, though not always, changing the Active property results in access
> violations. And after an AV happens then things start misbehaving in the
> IDE.
>
> Is this a common problem for some people on Linux using the MS SQL
> components? Am I doing something wrong? Are there people her who have
> worked with MS SQL components on Linux much and is familiar with this
> problem?
>

Just to be sure: do you have the necessary library installed on your
system? See here: http://wiki.freepascal.org/mssqlconn#Installation

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] IDE Ctrl+W key

[Sven Barth via lazarus]

Anthony Walter via lazarus  schrieb am So.,
17. März 2019, 19:04:

> You can still keep the old hotkey of ctrl+f4 and add ctrl+w. I really
> think worldwide there are is a grand total of zero people who use the word
> completion feature currently mapped to ctrl+w.
>

Wrong. I use it very often, especially when CodeTools fails due to me
working on features that are not yet supported. Or if some include file is
not picked up correctly.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Convert record to JSON?

[Sven Barth via lazarus]

Luca Olivetti via lazarus  schrieb am Di.,
26. Feb. 2019, 12:05:

> El 26/2/19 a les 11:11, Sven Barth via lazarus ha escrit:
>
> >
> > I didn't test bitbacked records so those might indeed fail.
>
> The RTTI information gives TkUnknown for a bitpacked record.
>

Ah, right, they don't get RTTI at all... 

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Convert record to JSON?

[Sven Barth via lazarus]

Luca Olivetti via lazarus  schrieb am Di.,
26. Feb. 2019, 09:34:

> El 21/7/18 a les 18:26, Sven Barth via Lazarus ha escrit:
>
> >> !! :)
> > There are definitely still some problems with it, e.g. a field of type
> > TObject (or any descendant) currently can't be deserialized as I didn't
> > want to rewrite DeStreamClassProperty. Then there are the sets which for
> > non-published properties can be greater than 32-bit (up to 256-bit
> > currently). Support for dynamic arrays could be added as well.
> > Also I didn't check whether all types serialize/deserialize correctly,
> > e.g. especially the special floating point types Comp and Currency.
> > You'd need to check what Get-/SetFloatProp are doing there.
>
> I tested this unit and I see that it doesn't manage bitpacked records
> inside the record, and the field names are "Field1", "Field2", etc.
> (I wanted to test what happens if I add fields to a record then try to
> deserialize into it a previously serialized version, but without real
> field names I suppose that wouldn't work properly).
>

I didn't test bitbacked records so those might indeed fail.
And field names are currently not available. This would require the
extended RTTI which is still work-in-progress.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] New feature: SQLDB Rest bridge

[Sven Barth via lazarus]

Mattias Gaertner via lazarus  schrieb am
Mo., 25. Feb. 2019, 12:22:

> On Mon, 25 Feb 2019 11:24:29 +0100
> Sven Barth via lazarus  wrote:
>
> >[...]
> > RTTI.Invoke() itself is working as is TRTTIMethod.Invoke(), so the
> > server side wouldn't be a problem, but what I'm still missing is
> > TVirtualInterface for the client side.
>
> Do you mean fpc's unit RTTI?
> pas2js has TVirtualInterface.
>

Yes, I mean FPC's RTTI unit. After all one could use this also for native
FPC clients ;)

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] New feature: SQLDB Rest bridge

[Sven Barth via lazarus]

Michael Van Canneyt via lazarus  schrieb am
Mo., 25. Feb. 2019, 08:07:

>
>
> On Mon, 25 Feb 2019, Sven Barth via lazarus wrote:
>
> > Michael Van Canneyt via lazarus  schrieb
> am
> > So., 24. Feb. 2019, 17:46:
> >
> >>
> >> Hello,
> >>
> >> We received some feedback about Pas2JS - our effort to bring Pascal to
> the
> >> browser - that easy database connectivity is an issue, hampering easy
> >> development.
> >>
> >> To alleviate the problem I have created the SQLDB Rest bridge.
> >>
> >> This is a set of components that allow you to expose any database
> supported
> >> by FPC's SQLDB as a REST service. It is designed to be simple to use,
> yet
> >> extensible.
> >>
> >
> > Cool! Great work!
> > Now I only need to get the parts for implementing an Interface using RTTI
> > working and I'd be all but set :D
>
> You mean for an RPC mechanism ?
>
> Isn't Invoke() working already ? I have a JSON RPC implemention on my list,
> and thought to use Invoke() for that.
>

RTTI.Invoke() itself is working as is TRTTIMethod.Invoke(), so the server
side wouldn't be a problem, but what I'm still missing is TVirtualInterface
for the client side.


> >
> > HTTP:
> >> * Authentication is handled using the HTTP protocol.
> >>
> >> * Basic authentication is included by default, but is completely
> pluggable.
> >>
> >> * Basic authentication can look up valid users in a database (by default
> >> the database being exposed)
> >>
> >
> > How would one check whether the user is allowed to execute an action?
>
> There is an OnAllowResource event, after the authentication. One of the
> parameters is the operation: GET, PUT etc.
> If you set the 'allow' to false, you'll get a 403, 'Forbidden'.
> It's not yet committed, because I wanted that together with the business
> processor component,
> which will make implementing all kinds of events simpler.
> There are stilll several improvements waiting to be tested and committed.
>

Great! Looking forward to that!

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] New feature: SQLDB Rest bridge

[Sven Barth via lazarus]

Michael Van Canneyt via lazarus  schrieb am
So., 24. Feb. 2019, 17:46:

>
> Hello,
>
> We received some feedback about Pas2JS - our effort to bring Pascal to the
> browser - that easy database connectivity is an issue, hampering easy
> development.
>
> To alleviate the problem I have created the SQLDB Rest bridge.
>
> This is a set of components that allow you to expose any database supported
> by FPC's SQLDB as a REST service. It is designed to be simple to use, yet
> extensible.
>

Cool! Great work!
Now I only need to get the parts for implementing an Interface using RTTI
working and I'd be all but set :D

HTTP:
> * Authentication is handled using the HTTP protocol.
>
> * Basic authentication is included by default, but is completely pluggable.
>
> * Basic authentication can look up valid users in a database (by default
> the database being exposed)
>

How would one check whether the user is allowed to execute an action?

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Fppkg error on IDE start with FPC 3.2 fixes

[Sven Barth via lazarus]

Am Do., 21. Feb. 2019, 11:40 hat AlexeyT via lazarus <
lazarus@lists.lazarus-ide.org> geschrieben:

> function TFppkgHelper.IsProperlyConfigured: Boolean;
> {$IF FPC_FULLVERSION>30100}
> var
>CompilerFilename: string;
> {$ENDIF FPC_FULLVERSION>30100}
> begin
>{$IF FPC_FULLVERSION>30100}
>if Assigned(FFPpkg) and (FIsProperlyConfigured=fpcUnknown) then
>  begin
>  FIsProperlyConfigured := fpcYes;
>
>  if not HasPackage('rtl') then
>FIsProperlyConfigured := fpcNo
>
> here I see req for package "rtl", while FPC fixes3.2 don't have "rtl"
> folder in /home/user/fpcupdeluxe/fpcsrc/packages. It has folders
> rtl-console, rtl-extra, rtl-generics, rtl-objpas, rtl-unicode.
>

The RTL package is not part of the packages directory, but is parallel to
that. Nevertheless it contains an fpmake.pp declaring it as a package.

Regards,
Sven

>
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus