Re: [Lazarus] Cross-compiling to win32 from debian stretch

[Péter Gábor via Lazarus]

You may have a different fpc.cfg (named .fpc.cfg << spot the dot on
Linux) in your home folder.

2017-11-28 00:41 keltezéssel, kardan via Lazarus írta:
> Really appreciate the fast reply!
> 
> On Tue, 28 Nov 2017 00:20:29 +0100
> Mattias Gaertner via Lazarus  wrote:
> 
>> Check your -Fu paths in /etc/fpc.cfg. They should contain the
>> paths to fpc's i386-win32 ppu files.
>>
>> Mattias
> 
> This is what i found related to -Fu in /etc/fpc.cfg:
> 
> # searchpath for units and other system dependent things
> -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
> -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
> -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl
> 
> #ifdef cpui8086
> -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/$fpcsubarch-$fpcmemorymodel
> -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/$fpcsubarch-$fpcmemorymodel/*
> -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/$fpcsubarch-$fpcmemorymodel/rtl
> #endif
> 
> #IFDEF FPCAPACHE_1_3
> -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/httpd13/
> #ELSE
> #IFDEF FPCAPACHE_2_0
> -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/httpd20
> #ELSE
> -Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/httpd22
> #ENDIF
> #ENDIF
> 
> # searchpath for fppkg user-specific packages
> -Fu~/.fppkg/lib/fpc/$fpcversion/units/$FPCTARGET/*
> 
> ~/.fpkg does not exist, but there is another version in /etc:
> 
> $ ls /etc/fpc*
> /etc/fpc-3.0.0.cfg  /etc/fpc.bak  /etc/fpc.cfg  /etc/fpc.cfg.bak
> 
> $ diff /etc/fpc.cfg /etc/fpc-3.0.0.cfg
> 2c2
> < # Config file generated by fpcmkcfg on 21-11-17 - 14:07:55
> ---
>> # Config file generated by fpcmkcfg on 10-11-17 - 07:19:33
> 145c145
> < -FM/usr/lib/fpc/../../share/fpc/$fpcversion/unicode/
> ---
>> -FM/unicode/
> 283a284,289
>> # multiarch library search path
>> -Fl/usr/lib/$fpctarget-*
>> # Third party units should be installe in a, multi-arch compatible location.
>> # Units should be installed in /usr/lib/$fpctarget-gnu/fp-units-2.6.2/$pkg/.
>> # Ech fp-units package should install a configuration file called $pkg.cfg in
>> #CFGDIR /etc/fpc-$fpcversion.cfg.d/$fpctarget
> 
> From that I can't see why 3.0.4rc1 is used for win32.
> 
> Kardan
> 

-- 
Péter Gábor
p...@freemail.hu

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

Re: [Lazarus] Cross-compiling to win32 from debian stretch

[kardan via Lazarus]

Really appreciate the fast reply!

On Tue, 28 Nov 2017 00:20:29 +0100
Mattias Gaertner via Lazarus  wrote:

> Check your -Fu paths in /etc/fpc.cfg. They should contain the
> paths to fpc's i386-win32 ppu files.
> 
> Mattias

This is what i found related to -Fu in /etc/fpc.cfg:

# searchpath for units and other system dependent things
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl

#ifdef cpui8086
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/$fpcsubarch-$fpcmemorymodel
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/$fpcsubarch-$fpcmemorymodel/*
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/$fpcsubarch-$fpcmemorymodel/rtl
#endif

#IFDEF FPCAPACHE_1_3
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/httpd13/
#ELSE
#IFDEF FPCAPACHE_2_0
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/httpd20
#ELSE
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/httpd22
#ENDIF
#ENDIF

# searchpath for fppkg user-specific packages
-Fu~/.fppkg/lib/fpc/$fpcversion/units/$FPCTARGET/*

~/.fpkg does not exist, but there is another version in /etc:

$ ls /etc/fpc*
/etc/fpc-3.0.0.cfg  /etc/fpc.bak  /etc/fpc.cfg  /etc/fpc.cfg.bak

$ diff /etc/fpc.cfg /etc/fpc-3.0.0.cfg
2c2
< # Config file generated by fpcmkcfg on 21-11-17 - 14:07:55
---
> # Config file generated by fpcmkcfg on 10-11-17 - 07:19:33
145c145
< -FM/usr/lib/fpc/../../share/fpc/$fpcversion/unicode/
---
> -FM/unicode/
283a284,289
> # multiarch library search path
> -Fl/usr/lib/$fpctarget-*
> # Third party units should be installe in a, multi-arch compatible location.
> # Units should be installed in /usr/lib/$fpctarget-gnu/fp-units-2.6.2/$pkg/.
> # Ech fp-units package should install a configuration file called $pkg.cfg in
> #CFGDIR /etc/fpc-$fpcversion.cfg.d/$fpctarget

From that I can't see why 3.0.4rc1 is used for win32.

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

[Lazarus] Cross-compiling to win32 from debian stretch

[kardan via Lazarus]

Hallo,

As a I am new to this list, FreePascal and Lazarus I need a little help
by you to crosscompile our project to win32. Compiling to win64 however
succeeds:

$ lazbuild --pcp=../../lazconf --os=win64 --cpu=x86_64 Tomboy_NG.lpi
...
Free Pascal Compiler version 3.1.1 [2017/11/27] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
(1002) Target OS: Win64 for x64
(3104) Compiling Tomboy_NG.lpr
(9022) Compiling
resource /home/tomboy/src/tomboy/src/tomboy-ng/lib/x86_64-win64/Tomboy_NG.obj
(9015) Linking tomboy-ng.exe (1008) 25 lines compiled, 13.7 sec,
2336192 bytes code, 408468 bytes data (1022) 2 hint(s) issued

As you see, I installed FPC from trunk with the steps documented here:
https://github.com/traumschule/tomboy/issues/2

I had to use the repository as the zip version
ftp.freepascal.org/pub/fpc/snapshot/trunk/source/fpc.zip (3.1.1) did not
create ppcross386 for OS_TARGET=win32". With the version from trunk it
works however.

Now compiling our project for i386 compared to above output another fpc
is used and fails:

$ lazbuild --pcp=../../lazconf --os=win32 --cpu=i386 Tomboy_NG.lpi
Free Pascal Compiler version 3.0.4rc1 [2017/08/07] for i386
Copyright (c) 1993-2017 by Florian Klaempfl and others
(1002) Target OS: Win32 for i386
(3104) Compiling fcllaz.pas
Fatal: (10022) Can't find unit system used by fcllaz
Fatal: (1018) Compilation aborted
Error: /usr/bin/ppc386 returned an error exitcode
Error: (lazarus) Compile package FCL 1.0.1: stopped with exit code 256
Error: (lazarus) [TLazPackageGraph.CompileRequiredPackages] "Exit code
256" Error: (lazbuild) Project dependencies
of /home/tomboy/src/tomboy/src/tomboy-ng/Tomboy_NG.lpi

$ which fpc
/usr/local/bin/fpc
$ fpc -V|head -n1
Free Pascal Compiler version 3.0.4rc1 [2017/08/07] for i386
$ ls /usr/lib/fpc/*/units
/usr/lib/fpc/3.0.4/units:
i386-linux

/usr/lib/fpc/3.1.1/units:
i386-win32  x86_64-win64
$ ls /usr/bin/ppcross*
/usr/bin/ppcross386  /usr/bin/ppcrossx64
$ /usr/bin/ppcross386 -V|head -n1
Free Pascal Compiler version 3.1.1 [2017/11/27] for i386
$ /usr/bin/ppcrossx64 -V|head -n1
Free Pascal Compiler version 3.1.1 [2017/11/27] for x86_64

I assume the solution is to specify another compiler
in ../../lazconf/environmentoptions.xml so I attached it. I am using
Lazarus 1.8.0RC5 installed via deb from sourceforge. Without other
advise I will try again with Lazarus from trunk.

If you want to try my steps, this repository may be of help:
https://github.com/tomboy-notes/tomboy-ng

To build it, I use ansible for automation:
https://github.com/traumschule/tomboy

To explain the funny path above, these are the steps I did:
cd ~/src
git clone https://github.com/traumschule/tomboy
cd tomboy
./bin/configure.sh # this installs lazarus, patches KControls and
checks out tomboy-ng cd src/tomboy-ng
lazbuild --pcp=../../lazconf --os=win32 --cpu=i386 Tomboy_NG.lpi

Thanks!
kardan


environmentoptions.xml
Description: XML document
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Compiling/linking/debugging package with generics

[Donald Ziesig via Lazarus]

On 11/27/2017 04:27 PM, Mattias Gaertner via Lazarus wrote:

On Mon, 27 Nov 2017 15:52:09 -0500
Donald Ziesig via Lazarus  wrote:


[...]

Are your 'Other unit files (-Fu)' paths in project inspector and
your package empty?

Yes, both are empty.

Good.
If your project and packages have their own directories, it seems
you found a compiler bug.
Can you reproduce it in a small example?

Will do.


Mattias



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

Re: [Lazarus] Compiling/linking/debugging package with generics

[Mattias Gaertner via Lazarus]

On Mon, 27 Nov 2017 15:52:09 -0500
Donald Ziesig via Lazarus  wrote:

>[...]
> > Are your 'Other unit files (-Fu)' paths in project inspector and
> > your package empty?  
> Yes, both are empty.

Good. 
If your project and packages have their own directories, it seems
you found a compiler bug.
Can you reproduce it in a small example?


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

Re: [Lazarus] Compiling/linking/debugging package with generics

[Donald Ziesig via Lazarus]

On 11/27/2017 01:41 PM, Mattias Gaertner via Lazarus wrote:

On Mon, 27 Nov 2017 13:33:13 -0500
Donald Ziesig via Lazarus  wrote:


[...]

When you change a pas file of your package and you compile your project,
does the IDE automatically compile your package?

Yes (at least it catches typos).  Also, the same problem occurs when I
compile the package manually, then run the program without using
"cleanup and build".  (I am gradually discovering the extent of the
problem ;-)).

Are your 'Other unit files (-Fu)' paths in project inspector and
your package empty?

Yes, both are empty.


Mattias



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

Re: [Lazarus] Who is using Object Pascal in production?

[Marcos Douglas B. Santos via Lazarus]

On Mon, Nov 27, 2017 at 4:54 PM, Alexsander Rosa via Lazarus
 wrote:
>
> Our ERP (version 3) was written in Lazarus + PostgreSQL.
>

Is it desktop or web?

Best regards,
Marcos Douglas
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] External/out-of-tree LCL widgetset

[Graeme Geldenhuys via Lazarus]

On 2017-11-27 19:04, Graeme Geldenhuys via Lazarus wrote:

Just so inform everybody. fpGUI has the ability to switch between "alien
windows" (only a top level window handle) or "each widget has a handle"
during compile time.


I forgot to mention, the latest stable release of fpGUI Toolkit (v1.4.x) 
is still based on the each-widget-has-its-own-window-handle design.



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] External/out-of-tree LCL widgetset

[Graeme Geldenhuys via Lazarus]

On 2017-11-26 17:32, Kostas Michalopoulos via Lazarus wrote:

Also AFAIK fpGUI doesn't use the native window system beyond the toplevel
windows, which i think would make OpenGL support and interfacing with
external stuff (e.g. calling an external library where you pass a HWND/X11
Window directly) harder.


Just so inform everybody. fpGUI has the ability to switch between "alien 
windows" (only a top level window handle) or "each widget has a handle" 
during compile time. I've been a huge supported of the latter for many 
years, but in the last year or two I've seen first hand the benefits of 
the "alien windows" style and want performances it brings.


Implementing OpenGL inside a fpGUI application (where alien windows is 
enabled by default) shouldn't be a problem at all, as any fpGUI widget 
can specify if it needs its own window handle or not.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] External/out-of-tree LCL widgetset

[Graeme Geldenhuys via Lazarus]

On 2017-11-23 02:23, Kostas Michalopoulos via Lazarus wrote:

My main motivation is wanting to get away from the modern madness of
GTK3+/Qt5+/Wayland and all that stuff and their dependencies


Then my I suggest you take a look at the LCL-fpGUI widgetset. It has all 
the basic components working (except for TLabel), and many of the other 
Windows like API's and dialogs etc. It desperately needs a maintainer - 
I don't have the time, and rather spend my time improving fpGUI 
directly, than maintain a LCL widgetset.


Either way, it would save you a ton of time and effort - plus it will 
check off some of your requirements like no large toolkit dependency 
hell like GTK3 and QT introduces. Plus, everything is implemented in 
Object Pascal LCL and fpGUI Toolkit.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Compiling/linking/debugging package with generics

[Mattias Gaertner via Lazarus]

On Mon, 27 Nov 2017 13:33:13 -0500
Donald Ziesig via Lazarus  wrote:

>[...]
> > When you change a pas file of your package and you compile your project,
> > does the IDE automatically compile your package?  
> Yes (at least it catches typos).  Also, the same problem occurs when I 
> compile the package manually, then run the program without using 
> "cleanup and build".  (I am gradually discovering the extent of the 
> problem ;-)).

Are your 'Other unit files (-Fu)' paths in project inspector and
your package empty?

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

Re: [Lazarus] Compiling/linking/debugging package with generics

[Donald Ziesig via Lazarus]

On 11/27/2017 01:28 PM, Mattias Gaertner via Lazarus wrote:

On Mon, 27 Nov 2017 13:15:36 -0500
Donald Ziesig via Lazarus  wrote:


[...]
TL;DR   Library packages which declare generics do compile, but do not
get included in the code that specializes them unless I "Cleanup and
build" the whole program.  (Workable, but much *slower* than programs
without generics).

I searched the bug tracker, but did not see anything resembling this
problem.  I would submit a bug report but I'm not sure whether this is
an IDE problem, a package problem or a compiler/linker problem.  Would
someone more familiar with this part of the architecture give me pointers?

When you change a pas file of your package and you compile your project,
does the IDE automatically compile your package?
Yes (at least it catches typos).  Also, the same problem occurs when I 
compile the package manually, then run the program without using 
"cleanup and build".  (I am gradually discovering the extent of the 
problem ;-)).


Mattias



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

Re: [Lazarus] Compiling/linking/debugging package with generics

[Mattias Gaertner via Lazarus]

On Mon, 27 Nov 2017 13:15:36 -0500
Donald Ziesig via Lazarus  wrote:

>[...]
> TL;DR   Library packages which declare generics do compile, but do not 
> get included in the code that specializes them unless I "Cleanup and 
> build" the whole program.  (Workable, but much *slower* than programs 
> without generics).
> 
> I searched the bug tracker, but did not see anything resembling this 
> problem.  I would submit a bug report but I'm not sure whether this is 
> an IDE problem, a package problem or a compiler/linker problem.  Would 
> someone more familiar with this part of the architecture give me pointers?

When you change a pas file of your package and you compile your project,
does the IDE automatically compile your package?


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

Re: [Lazarus] External/out-of-tree LCL widgetset

[Mattias Gaertner via Lazarus]

On Mon, 27 Nov 2017 19:45:42 +0200
Kostas Michalopoulos via Lazarus  wrote:

>[...]
> Thanks for the information. So in theory i could write a shell script that
> creates a symbolic link lcl/interfaces/wsfoo that points to some external
> (from Lazarus' source code dir) directory and adds (via sed, awk or
> whatever) wsfoo to lcl/lclplatformdef.pas and then projects that override
> the target widgetset (via the LCLWidgetType:=foo IDE macro) would work?

Yes.

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

Re: [Lazarus] External/out-of-tree LCL widgetset

[Kostas Michalopoulos via Lazarus]

@Sven:
Ah, i thought the custom drawn was built on top of LCL. Hm, regardless, it
doesn't solve my concern, since what i want is to reuse my widget toolkit.
Otherwise i'd probably work on fpGUI's Lazarus bindings since fpGUI seems
to be more mature.

@Martin:
No, it is tied to LCL :-P a lot of code uses LCL classes and i don't really
separate the "business logic" since i never planned (nor plan) to use that
code outside of LCL/Lazarus. This is mostly library code for
graphics-related utilities, common code for UI stuff like adjustments, etc.
Some code could work outside of LCL, but it is mixed with code that relies
on LCL and separating the two isn't worth the effort.

@Michael:
The "most of my code is LCL specific" part is about the code i work with on
Lazarus. Overall my code is pretty much even between Lazarus and C (with a
very tiny bit of LCL-free Free Pascal code). Generally for GUI heavy
desktop stuff i use Lazarus (and LCL) and for everything else i use C. For
some newer GUI stuff (currently light in GUI) i also use C with my toolkit.

@Mattias:
Thanks for the information. So in theory i could write a shell script that
creates a symbolic link lcl/interfaces/wsfoo that points to some external
(from Lazarus' source code dir) directory and adds (via sed, awk or
whatever) wsfoo to lcl/lclplatformdef.pas and then projects that override
the target widgetset (via the LCLWidgetType:=foo IDE macro) would work?

Kostas


On Mon, Nov 27, 2017 at 1:36 PM, Mattias Gaertner via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:

> On Sun, 26 Nov 2017 19:32:21 +0200
> Kostas Michalopoulos via Lazarus  wrote:
>
> >[...]
> > As i said, i do not think this would be useful enough to others to be
> part
> > of the Lazarus tree. I ask because i remember a few months ago someone
> > having an Amiga widgetset pretty much in working condition and that was
> > something he worked on for a while, so i wondered if there was some
> > mechanism for that. I suppose just having a big patch would also work,
> > although it is kind of inconvenient.
>
> The Amiga widgetset is the 'mui'.
>
> You can add a new widgetset in folder lcl/interfaces/yourws and use it
> in your project.
>
> For some nicer integration you can add an enum to
> lcl/lclplatformdef.pas.
>
> The IDE checks only the sources listed in the lcl.lpk. Since your files
> are not listed there, changing any of your widgetset sources will not
> trigger building the LCL package automatically. So you have to click on
> the 'Compile' button in the LCL package.
>
> Mattias
> --
> ___
> 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] String Grid Component

[Werner Pamler via Lazarus]

Am 27.11.2017 um 17:51 schrieb Torsten Bonde Christiansen via Lazarus:

[...]  so that i can copy/paste the data to the clipboard.


Hmm... You must be aware that the DrawGrid does not own any data. 
Therefore it cannot copy anything to the clipboard. You'll have to write 
clipboard access by yourself - which is not too difficult I guess.



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

Re: [Lazarus] String Grid Component

[Torsten Bonde Christiansen via Lazarus]

On 2017-11-27 16:48, Werner Pamler via Lazarus wrote:

Am 27.11.2017 um 16:21 schrieb Werner Pamler via Lazarus:
(a) What is "fast"? If I populate a standard TStringGrid with 100.000 
rows x 100 columns (= 10 millions of cells) it takes about 9 seconds 
on my PC - if BeginUpdate/EndUpdate is used. Not too bad in my eyes. 
If it's too long you should use a TDrawGrid and paint the cells in 
the OnDrawCell event. Since this draws only the visible cells it will 
occur within the blink of an eye. Editing a TDrawGrid is a bit more 
complicated, though, but doable.


I forgot: Of course, this does not take into account the time it takes 
to populate the primary storage of the data shown in the DrawGrid. 
Filling a 2D-array with millions of strings, for example, will take 
its time too, 6 seconds on my PC for a 100.000 x 100 array. In these 
tests, the string is assembled as 'R' + IntToStr(rowindex) + 'C' + 
IntToStr(colIndex).
Yes, sorry for the lack of other factors too - those were just the two 
most needed.



I already have the data at hand in my own object structure so that is no 
problem. By fast i mean less than one second, even on a modern PC. The 
users of our program often have old or very old hardware in which case 
my/your 9 seconds turns to 30 or more seconds.


In reallity all i need is a read-only grid that can display the data in 
string format and range selection so that i can copy/paste the data to 
the clipboard.


From your reply it seems i am going with TDrawGrid.

Thank you for the help!

Regards,
Torsten.




Look at attached demo.





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

Re: [Lazarus] String Grid Component

[Ondrej Pokorny via Lazarus]

On 27.11.2017 13:43, Torsten Bonde Christiansen via Lazarus wrote:
So i am asking if you know of a good string grid component that can 
handle both things equally well.


TDrawGrid. Use a string/data storage of your choice.

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

[Lazarus] String Grid Component

[Torsten Bonde Christiansen via Lazarus]

Hi List.

I am looking for grid component that can display string. Simple enought 
and i know of a few already, but the ones i know of cannot do both of 
the following requirements i have:


a) Fast (very low delay on 100.000+ lines of test)
b) Allow selecting multiple cells spanning rows and colomns.

For a) i know of VirtualTreeview which handles large data very very 
fine. The problem is that is does not allow for selecting multiple 
columns and rows combined.


For b) there is the native LCL stringgrid, the lazarus package TKontrols 
is also good, but they don't handle large data very well. Mostly because 
all rows/columns are traversed (initialized) instead of the just the 
actual rows/columns displayed onscreen.


So i am asking if you know of a good string grid component that can 
handle both things equally well.


Kind regards,
Torsten.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Developing a WidgetSet

[Lubos Pintes via Lazarus]

Hmm... But if I disable my UIA code then the form works as expected.
Also If I place some standard control to a form like TButton. But I will 
try the MainFormInTaskbar property to see what happens.

Dňa 26. 11. 2017 o 18:13 Ondrej Pokorny via Lazarus napísal(a):

On 26.11.2017 16:09, Martin Frb via Lazarus wrote:
I am not 100% sure, but maybe this is because (afaik) there is a 
hidden form for the task button. This hidden form can be disabled 
somewhere, then the main form will be responsible for the task button.


On 20/11/2017 09:54, Lubos Pintes via Lazarus wrote:


I can confirm that Inspect can see the object(s). But one symptom I 
am receiving that a screen reader is unable to register that a form 
receives the focus. If I alt-tabbing, I hear "Project1", instead of 
"Form1".


Correct. Use Application.MainFormOnTaskbar := True to register the form 
for the taskbar.


Ondrej




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

Re: [Lazarus] External/out-of-tree LCL widgetset

[Michael Schnell via Lazarus]

On 26.11.2017 17:13, Sven Barth via Lazarus wrote:
Lazarus already contains a custom drawn widgetset that supports X11. I 
don't know its current state, but maybe it would be best to bring that 
up to speed and form instead of starting a new one.


Some time ago I did play with the custom drawn Widget Type. I found that 
it was not yet complete but rather promising. AFAIK, not much has 
changed since then .


Anyway I also would suggest to use this to build on. This will be a lot 
easier that do something completely new.


In fact, Widget Types need to be known to the Lazarus IDE, as same is 
able to have the user select them and force them via definition of 
conditionals fed to the compiler.


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

Re: [Lazarus] translation of oss' soundcard.h

[Michael Van Canneyt via Lazarus]

On Mon, 27 Nov 2017, Marc Santhoff via Lazarus wrote:


Hi,


has soundcard.h from OSS API already been translated to Pascal?

OSS is used for accessing soundcards and MIDI devices by Linux and
FreeBSD.


Not that I am aware of.

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

Re: [Lazarus] translation of oss' soundcard.h

[Marc Santhoff via Lazarus]

Sorry, this would belong to the fpc list...


On Mo, 2017-11-27 at 11:25 +0100, Marc Santhoff via Lazarus wrote:
> Hi,
> 
> 
> has soundcard.h from OSS API already been translated to Pascal?
> 
> OSS is used for accessing soundcards and MIDI devices by Linux and
> FreeBSD.
> 
> TIA,
> Marc
> 
> 


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