Re: [Lazarus] WMEnterSizeMove Messages not firing

[Ondrej Pokorny]

On 10.10.2015 15:36, Aradeonas wrote:

Now I get a kind message from Székely Balázs that show a temporary way.


Great! Thanks Balázs for the code and also thanks for sharing!

I added the workaround to the bug report:
http://bugs.freepascal.org/view.php?id=23302

Ondrej

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

Re: [Lazarus] lazcontrols filters

[Krzysztof]

TextHint could be visibile even when edit is focused (but still empty of
course). This is how many edit controls work nowadays, e.g address edit in
FireFox
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] WMEnterSizeMove Messages not firing

[Aradeonas]

Its a temp way and it should work the easy way but for now its good to
go.

Regards,
Ara


-- 
http://www.fastmail.com - Access all of your messages and folders
  wherever you are


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

Re: [Lazarus] lazcontrols filters

[Ondrej Pokorny]

On 10.10.2015 17:52, Krzysztof wrote:
TextHint could be visibile even when edit is focused (but still empty 
of course). This is how many edit controls work nowadays, e.g address 
edit in FireFox
This is exactly what I was thinking. The rekonq browser has the same. It 
is even able to put a button in front of the text in the edit and start 
the text after the edit + the hint text is centered. I admit that I 
don't know if rekonq uses Qt or Gtk2.


Whereas I know how to achieve it on Windows (one can find a lot of 
sources for it in the internet), on other widgetsets it could be tricky 
as Bart already stated. Unfortunately I don't have the knowledge to do 
it in all widgetsets :(


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

[Lazarus] Built Lazarus on RPi2, warning on every project build

[Bo Berglund]

I have successfully compiled and installed fpc and lazarus from trunk
sources retrieved by svn on a Raspberry Pi2 unit.
Versions are 3.1.1 and 1.5 respectively
I can run Lazarus in the RPi2 and simple programs that I have tested
work as expected.
But nevertheless on every single compile there are two warnings shown:

Warning: "crtbegin.o" not found, this will probably cause a linking
failure
Warning: "crtend.o" not found, this will probably cause a linking
failure

Why does this happen? And what can be done about it?

-- 
Bo Berglund
Developer in Sweden


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

Re: [Lazarus] lazcontrols filters

[Juha Manninen]

On Sat, Oct 10, 2015 at 7:38 PM, Ondrej Pokorny  wrote:
> This is exactly what I was thinking. The rekonq browser has the same. It is
> even able to put a button in front of the text in the edit and start the
> text after the edit + the hint text is centered. I admit that I don't know
> if rekonq uses Qt or Gtk2.

Rekonq uses both QT and KDE libs. Not directly usable for LCL
implementation but a nice idea anyway.

Juha

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

Re: [Lazarus] Built Lazarus on RPi2, warning on every project build

[wkitty42]

On 10/10/2015 03:13 PM, Bo Berglund wrote:

I have successfully compiled and installed fpc and lazarus from trunk
sources retrieved by svn on a Raspberry Pi2 unit.
Versions are 3.1.1 and 1.5 respectively
I can run Lazarus in the RPi2 and simple programs that I have tested
work as expected.
But nevertheless on every single compile there are two warnings shown:

Warning: "crtbegin.o" not found, this will probably cause a linking
failure
Warning: "crtend.o" not found, this will probably cause a linking
failure

Why does this happen? And what can be done about it?


i cannot help with the problem but i wanted to point out that those two are "C 
Run Time" and not "CRT" items... many mistake those types of names as CRT 
related and go looking in that direction instead of in the "C" direction...


a possible help is that you have to tell the system where to find the C runtime 
developer's library code... i don't know how this is done but the topic has been 
spoken of numerous times in either the FPC or Lazarus lists... i'm sure that 
others will have the real info if they haven't answered you already...


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list* unless
   private contact is specifically requested and granted.

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

[Lazarus] Lazarus eats comment characters using Swedish keyboard

[Bo Berglund]

A problem surfaced just a moment ago...
I was writing code in Lazarus ver 1.5 running on a Raspberry Pi2 with
Raspbian Jessie.
I wanted to comment out a number of lines so I hit the key combination
to produce the { } pair. But nothing was printed in the Lazarus
editor.
If I switched to the text editor in the GUI the keys produced the
wanted characters.

So something in Lazarus eats the key presses needed in Sweden to
produce the braces (RightAlt-7 and RightAlt-0).
Is there a configuration somewhere to stop this from happening so one
can enter comments in Lazarus?

-- 
Bo Berglund
Developer in Sweden


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

Re: [Lazarus] Accessing GPIO on RaspberryPi2 from Lazarus/FPC

[Bo Berglund]

On Thu, 08 Oct 2015 23:30:10 +0200, Bo Berglund
 wrote:

>I have found a description of a unit implementing an interface to the
>gpio driver in the Free Pascal documentation. It is here:
>http://wiki.freepascal.org/Lazarus_on_Raspberry_Pi#5._PiGpio_Low-level_native_pascal_unit_.28GPIO_control_instead_of_wiringPi_c_library.29
>
>However, it specifically lists the BCM2835 chip and not the BCM2836
>which is used on the Pi2.
>
>So I wonder if anyone here knows about an updated gpio.pas file which
>works on the Pi2?

I have solved the problem now. This is how I modified pigpio.pas:
1) I added a define for RPI2 and used it in a conditional to set the
REG_GPIO constant to $3F000 or $2

2) I changed the device from /dev/mem to /dev/gpiomem
This allowed the generated program to run as user pi.

3) I also added the Pi connector mapping defines into pigpio.pas so
that any user program does not have to enter this in its own code.
Just use RPI_P12 or similar in the user code.

Apart from this pigpio.pas stays the same as before.

Thanks to all that helped me come to this result!

-- 
Bo Berglund
Developer in Sweden


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

Re: [Lazarus] Codetools question

[Ondrej Pokorny]

On 10.10.2015 12:35, Michael Van Canneyt wrote:


Hi,

Mainly for Mattias, I suppose:

The SetString routine in the system unit has become a compiler 
procedure in 3.0:


{$ifdef FPC_HAS_CPSTRING}
Procedure fpc_setstring_ansistr_pansichar(out S : RawByteString; Buf : 
PAnsiChar; Len : SizeInt; cp: TSystemCodePage); rtlproc; compilerproc;

{$else}
Procedure SetString(out S : AnsiString; Buf : PAnsiChar; Len : SizeInt);
{$endif}
begin
  SetLength(S,Len);
{$ifdef FPC_HAS_CPSTRING}
  SetCodePage(S,cp,false);
{$endif}
  If (Buf<>Nil) then
fpc_pchar_ansistr_intern_charmove(Buf,0,S,0,Len);
end;

This means the codetools are no longer able to find the SetString 
declaration.


Is there any way to fix this kind of things (i.e. find compiler procs) 
in the code tools ?


Yes, see TIdentCompletionTool.GatherPredefinedIdentifiers() in 
IdentCompletionTool.pas


Add this line there:

AddCompilerProcedure('SetString','out 
S:RawByteString;Buf:PAnsiChar;Len:SizeInt;cp:TSystemCodePage');


Ondrej

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

Re: [Lazarus] Codetools question

[Michael Van Canneyt]

On Sat, 10 Oct 2015, Ondrej Pokorny wrote:


On 10.10.2015 12:43, Michael Van Canneyt wrote:



On Sat, 10 Oct 2015, Ondrej Pokorny wrote:


On 10.10.2015 12:35, Michael Van Canneyt wrote:


Hi,

Mainly for Mattias, I suppose:

The SetString routine in the system unit has become a compiler procedure 
in 3.0:


{$ifdef FPC_HAS_CPSTRING}
Procedure fpc_setstring_ansistr_pansichar(out S : RawByteString; Buf : 
PAnsiChar; Len : SizeInt; cp: TSystemCodePage); rtlproc; compilerproc;

{$else}
Procedure SetString(out S : AnsiString; Buf : PAnsiChar; Len : SizeInt);
{$endif}
begin
  SetLength(S,Len);
{$ifdef FPC_HAS_CPSTRING}
  SetCodePage(S,cp,false);
{$endif}
  If (Buf<>Nil) then
fpc_pchar_ansistr_intern_charmove(Buf,0,S,0,Len);
end;

This means the codetools are no longer able to find the SetString 
declaration.


Is there any way to fix this kind of things (i.e. find compiler procs) in 
the code tools ?


Yes, see TIdentCompletionTool.GatherPredefinedIdentifiers() in 
IdentCompletionTool.pas


Add this line there:

   AddCompilerProcedure('SetString','out 
S:RawByteString;Buf:PAnsiChar;Len:SizeInt;cp:TSystemCodePage');


Oh cool :-)
I didn't know this existed, I keep underestimating the Lazarus IDE ;)
How to detect the compiler version ? Because it is only for 3.0+, I 
suppose.


I think it is save to assume that Lazarus was compiled with the same FPC 
version that is also used for the sources in editor. Therefore you can use 
the same compiler directive:


This is definitely not so :-(
I compile lazarus with 2.6.4, but work with compiler set to 3.0 or even jvm.

That is how I bumped into the problem to begin with... :-)

Michael.

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

Re: [Lazarus] Codetools question

[Sven Barth]

Am 10.10.2015 12:47 schrieb "Ondrej Pokorny" :
>
> I think it is save to assume that Lazarus was compiled with the same FPC
version that is also used for the sources in editor. Therefore you can use
the same compiler directive:

Not necessarily. As a compiler developer I often switch between versions
depending on whether I want to use a non-released feature or a stable
compiler...

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

Re: [Lazarus] Codetools question

[Ondrej Pokorny]

On 10.10.2015 13:00, Michael Van Canneyt wrote:

This is definitely not so :-(
I compile lazarus with 2.6.4, but work with compiler set to 3.0 or 
even jvm.


That is how I bumped into the problem to begin with... :-)


CodeTools know what compiler constants are defined in the target tool. 
You have to check if FPC_HAS_CPSTRING is defined. This should be 
possible but I don't know how to do it. You'll have to wait for Mattias' 
answer.


Ondrej

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

[Lazarus] Codetools question

[Michael Van Canneyt]

Hi,

Mainly for Mattias, I suppose:

The SetString routine in the system unit has become a compiler procedure in 3.0:

{$ifdef FPC_HAS_CPSTRING}
Procedure fpc_setstring_ansistr_pansichar(out S : RawByteString; Buf : 
PAnsiChar; Len : SizeInt; cp: TSystemCodePage); rtlproc; compilerproc;
{$else}
Procedure SetString(out S : AnsiString; Buf : PAnsiChar; Len : SizeInt);
{$endif}
begin
  SetLength(S,Len);
{$ifdef FPC_HAS_CPSTRING}
  SetCodePage(S,cp,false);
{$endif}
  If (Buf<>Nil) then
fpc_pchar_ansistr_intern_charmove(Buf,0,S,0,Len);
end;

This means the codetools are no longer able to find the SetString declaration.

Is there any way to fix this kind of things (i.e. find compiler procs) in the 
code tools ?

Michael.

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

Re: [Lazarus] Codetools question

[Michael Van Canneyt]

On Sat, 10 Oct 2015, Ondrej Pokorny wrote:


On 10.10.2015 12:35, Michael Van Canneyt wrote:


Hi,

Mainly for Mattias, I suppose:

The SetString routine in the system unit has become a compiler procedure in 
3.0:


{$ifdef FPC_HAS_CPSTRING}
Procedure fpc_setstring_ansistr_pansichar(out S : RawByteString; Buf : 
PAnsiChar; Len : SizeInt; cp: TSystemCodePage); rtlproc; compilerproc;

{$else}
Procedure SetString(out S : AnsiString; Buf : PAnsiChar; Len : SizeInt);
{$endif}
begin
  SetLength(S,Len);
{$ifdef FPC_HAS_CPSTRING}
  SetCodePage(S,cp,false);
{$endif}
  If (Buf<>Nil) then
fpc_pchar_ansistr_intern_charmove(Buf,0,S,0,Len);
end;

This means the codetools are no longer able to find the SetString 
declaration.


Is there any way to fix this kind of things (i.e. find compiler procs) in 
the code tools ?


Yes, see TIdentCompletionTool.GatherPredefinedIdentifiers() in 
IdentCompletionTool.pas


Add this line there:

   AddCompilerProcedure('SetString','out 
S:RawByteString;Buf:PAnsiChar;Len:SizeInt;cp:TSystemCodePage');


Oh cool :-)
I didn't know this existed, I keep underestimating the Lazarus IDE ;)
How to detect the compiler version ? Because it is only for 3.0+, I suppose.

Michael.

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

Re: [Lazarus] Codetools question

[Ondrej Pokorny]

On 10.10.2015 12:43, Michael Van Canneyt wrote:



On Sat, 10 Oct 2015, Ondrej Pokorny wrote:


On 10.10.2015 12:35, Michael Van Canneyt wrote:


Hi,

Mainly for Mattias, I suppose:

The SetString routine in the system unit has become a compiler 
procedure in 3.0:


{$ifdef FPC_HAS_CPSTRING}
Procedure fpc_setstring_ansistr_pansichar(out S : RawByteString; Buf 
: PAnsiChar; Len : SizeInt; cp: TSystemCodePage); rtlproc; 
compilerproc;

{$else}
Procedure SetString(out S : AnsiString; Buf : PAnsiChar; Len : 
SizeInt);

{$endif}
begin
  SetLength(S,Len);
{$ifdef FPC_HAS_CPSTRING}
  SetCodePage(S,cp,false);
{$endif}
  If (Buf<>Nil) then
fpc_pchar_ansistr_intern_charmove(Buf,0,S,0,Len);
end;

This means the codetools are no longer able to find the SetString 
declaration.


Is there any way to fix this kind of things (i.e. find compiler 
procs) in the code tools ?


Yes, see TIdentCompletionTool.GatherPredefinedIdentifiers() in 
IdentCompletionTool.pas


Add this line there:

   AddCompilerProcedure('SetString','out 
S:RawByteString;Buf:PAnsiChar;Len:SizeInt;cp:TSystemCodePage');


Oh cool :-)
I didn't know this existed, I keep underestimating the Lazarus IDE ;)
How to detect the compiler version ? Because it is only for 3.0+, I 
suppose.


I think it is save to assume that Lazarus was compiled with the same FPC 
version that is also used for the sources in editor. Therefore you can 
use the same compiler directive:


{$ifdef FPC_HAS_CPSTRING}
   AddCompilerProcedure('SetString','out 
S:RawByteString;Buf:PAnsiChar;Len:SizeInt;cp:TSystemCodePage');

{$endif}

Ondrej

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

Re: [Lazarus] Accessing GPIO on RaspberryPi2 from Lazarus/FPC

[Michael Ring]

I agree, this is a really, really nice find.

Not only because of the rpi code, their xml parser implementation is the 
most easiest to debug I have ever seen, not the usual pointer chaos seen 
in all the other implementations.


Hopefully there are even more gems hidden in this library.

Michael

Am 10.10.15 um 00:31 schrieb Bo Berglund:

On Fri, 09 Oct 2015 07:31:52 +, Alfred  wrote:


Please have a look at:
http://www.afterwarp.net/products/pxl
https://github.com/yunkot/pxl

Forum post:
http://forum.lazarus.freepascal.org/index.php/topic,29852.0.html?PHPSESSID=bf43911005bf788ab072b3d73d1bfb4f

Pxl is a very well written library, capable of doing a lot, with the
inclusion of hardware access on RPi(2) !

See sample:
https://github.com/yunkot/pxl/tree/master/Samples/FreePascal/SingleBoard/RaspberryPI

Very good suggestion, Thanks!

I noticed in the file PXL.Boards.RPi.pas the following note:

// The following option controls whether the code is optimized for
Raspberry PI 2.
{.$DEFINE RPi2}

And further down I found that this define controls the address used
for GPIO:
   FChipOffsetBase := {$IFDEF RPi2} $3F000 {$ELSE} $2 {$ENDIF}; //
in pages (x 4096 bytes)

So it looks like it is going to solve my I/O control on the Pi2!
Now I just have to figure which files to copy over to the Pi for this
to work, the complete download is very big and most of it I really do
not need...





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

Re: [Lazarus] Accessing GPIO on RaspberryPi2 from Lazarus/FPC

[Michael Van Canneyt]

On Sat, 10 Oct 2015, Michael Ring wrote:


I agree, this is a really, really nice find.

Not only because of the rpi code, their xml parser implementation is the most 
easiest to debug I have ever seen, not the usual pointer chaos seen in all 
the other implementations.


The difference will be in speed, most likely.



Hopefully there are even more gems hidden in this library.


At first glance, it is a very nice piece of work, quite complete.

Michael.

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

Re: [Lazarus] WMEnterSizeMove Messages not firing

[Aradeonas]

Now I get a kind message from Székely Balázs that show a temporary way.

> Hi Ara, I saw your conversation with Ondrej about catching the
> WMEnterSizeMove and WMExitSizeMove message. I did respond on the
> mailing list, unfortunately my mails still get filtered out(this was
> also confirmed by Juha). Anyway here is a possible solution. Feel free
> to post in the mailing list if you like:
>
> uses windows; var  PrevWndProc: WNDPROC;
>
> function WndCallback(AHWND: HWND; uMsg: UINT; wParam: WParam; lParam:
> LParam): LRESULT; stdcall; begin  case uMsg of    WM_ENTERSIZEMOVE:
> begin  //...  Result := CallWindowProc(PrevWndProc, Ahwnd,
> uMsg, WParam, LParam);    end;    WM_EXITSIZEMOVE:    begin  //...
> Result := CallWindowProc(PrevWndProc, Ahwnd, uMsg, WParam, LParam);
> end;    else  Result := CallWindowProc(PrevWndProc, Ahwnd, uMsg,
> WParam, LParam);  end; end;
>
> procedure TForm1.FormCreate(Sender: TObject); begin  PrevWndProc :=
> Windows.WNDPROC(SetWindowLongPtr(Self.Handle, GWL_WNDPROC,
> PtrInt(@WndCallback))); end;
>
> regards, Balázs


Regards, Ara


-- 
http://www.fastmail.com - Access your email from home and the web

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