Re: [Lazarus] RFC : "Resolved View"

[Giuliano Colla]

Il 12/02/2016 02:41, Martin Frb ha scritto:
Actual hiding is more work, because it needs to shift x positions in 
some line. Probably needs big changes. Though readonly may be doable.


IMHO such a feature would be typically used to read and understand code, 
therefore read-only is not only acceptable, but desirable.


Giuliano




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

Re: [Lazarus] Loading OpenGL error

[Aradeonas]

I reinstall everything and tried a new test :
 1. add lazopenglcontext
 2. add OpenGLContext unit
 3. type O:=TOpenGLControl.Create(self);
 4. run and no problem.
 5. type  o.Parent:=self;
 6. run and that error again.

Regards, Ara


-- 
http://www.fastmail.com - Accessible with your email software
  or over the web

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

Re: [Lazarus] Tool to convert a multiline text to a pascal string constant

[Marco van de Voort]

On Thu, Feb 11, 2016 at 11:08:12AM +0100, Michalis Kamburelis wrote:
> Hm, I admit I simply didn't know about them long time ago, when creating
> file_to_pascal_xxx utilities in PasDoc:)
> 
> Looking at them now:
> 
> 1. They both have quite longer code than our simple
> file_to_pascal_string.dpr / file_to_pascal_data.dpr...
> 
>   In particular data2inc wants to do much more (being able to process a
> special file format like data2inc.exm). Although it can do the simple
> thing when invoked with -b option.

Data2inc is the result of integration of several such programs and is quite
old (late nineties) because they shared many routines (this was all before
strutils and hex/bin/oct functionality in inttostr etc existed). Yes the
bulk of the code is for other things, but I always used it for the straight
case.

IIRC Michael didn't know it, so he wrote bin2obj.


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

Re: [Lazarus] Tool to convert a multiline text to a pascal string constant

[Michael Van Canneyt]

On Fri, 12 Feb 2016, Marco van de Voort wrote:


On Thu, Feb 11, 2016 at 11:08:12AM +0100, Michalis Kamburelis wrote:

Hm, I admit I simply didn't know about them long time ago, when creating
file_to_pascal_xxx utilities in PasDoc:)

Looking at them now:

1. They both have quite longer code than our simple
file_to_pascal_string.dpr / file_to_pascal_data.dpr...

  In particular data2inc wants to do much more (being able to process a
special file format like data2inc.exm). Although it can do the simple
thing when invoked with -b option.


Data2inc is the result of integration of several such programs and is quite
old (late nineties) because they shared many routines (this was all before
strutils and hex/bin/oct functionality in inttostr etc existed). Yes the
bulk of the code is for other things, but I always used it for the straight
case.

IIRC Michael didn't know it, so he wrote bin2obj.


Exactly.

Michael.

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

Re: [Lazarus] searching the net

[Reimar Grabowski]

On Fri, 12 Feb 2016 08:30:46 +0100
duilio foschi  wrote:

> I'd like to programmatically query intenet for a number of  keys, say "key1
> key2 key3" and get the number of hits. Any browser will do.
> 
> How do I do this ?
Use fpHttpClient and do a standard HTTP request? No browser needed.
(http://wiki.lazarus.freepascal.org/fphttpclient)

R.

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

Re: [Lazarus] RFC : "Resolved View"

[Michael Van Canneyt]

On Fri, 12 Feb 2016, Martin Frb wrote:


On 11/02/2016 23:54, Michael Van Canneyt wrote:



By this I mean a view of a unit as the compiler will see it:
- Correct include files included


This has been long on the list. But still no in the doing.

Ignoring:
- any high/low-light or other markup to indicate the fact that the text comes 
from a different file

- probably also ignoring line numbering

this should actually be relatively easy.


Aha, so there is hope :)



There are already "views" wrapped around the textbuffer. All that it needs is 
to wrap another view around it, that combines 2 real textbuffers.


This could even be editable. Except it needs to prevent joining lines accross 
file bound.


And ask what to do if you delete all lines from an include: remove the
include directive or the file.



There is work on the IDE side (outside SynEdit) to ensure it knows the file 
is open. Could be resolved by pretending it is open in its own editor (which 
is simply hidden)


So, this part is in fact pretty realistic ?

Well, if it is on the todo list, I don't need to file a feature request ;)



- IFDefs properly resolved. 

lowlight exists.

Actual hiding is more work, because it needs to shift x positions in some 
line. Probably needs big changes. Though readonly may be doable.


Hmh. I would think that preprocessing the text would be an easier approach
here, no ?

I think for the second feature, read-only (as pointed out by Giuliano Colla) is 
the only viable option, because there are too many border cases. 
In that case preprocessing is an option.


Still, I suspect that Anthony Walter's original problem would be largely
solved by handling the includes (so simply 'Inclusive view' :) )

Michael.

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

Re: [Lazarus] searching the net

[Lukasz Sokol]

On 12/02/16 07:30, duilio foschi wrote:
> I'd like to programmatically query intenet for a number of  keys, say
> "key1 key2 key3" and get the number of hits. Any browser will do.
> 
> How do I do this ?
> 

CreateProcess - invoke a browser with parameters,
or ShellExecute with appropriate URL - should invoke default browser on most 
os'es...

> Thank you
> 
> Peppe
> 

HTH

-L.



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

[Lazarus] non Unicodode application

[Michael Schnell]

Hi Experts,

A friend of mine wants to port an application from Delphi 7 to a be a 
Lazarus 64 Bit Windows application.


This (huge) application only features a very limited GIU, but uses 
strings lot for "uncoded" characters, going in and out via TCP/IP. Any 
automatic type conversion would kill the application.


So it would be necessary that fpc is configured to use the (old) 8 bit 
Strings. These might be used with UTF8 encoding for the GUI stuff (and 
for some limited locations in the business-code with *explicit* 
conversion).


Is this possible with the current version of Lazarus  ?

As I lost the clue on the planned path regarding code-aware strings: 
will this be possible with future versions of Lazarus ,as well ?


Thanks,
-Michael

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

Re: [Lazarus] searching the net

[Graeme Geldenhuys]

On 2016-02-12 12:52, Reimar Grabowski wrote:
> Use fpHttpClient and do a standard HTTP request? No browser needed.

Indeed. And the URL syntax for Google would be:

  https://www.google.co.uk/search?q=XYZ

Where XYZ is your search term. Then simply parse the resulting page and
extract the info you need.

And here is the syntax for DuckDuckGo:
 HTML5 + Javascript version:
https://duckduckgo.com/?q=XYZ
 Plain HTML version:
https://duckduckgo.com/html/?q=XYZ




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.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] non Unicodode application

[Kostas Michalopoulos]

I suppose a more clear question would be...

is it possible for now and the foreseeable future to have FPC (3.0+, not
just 2.x) make the "string" type (not rawbytestring or anything else)
behave as it was behaving always since the beginning of time without any
source code changes but (say) via some compiler argument?

I suppose it is worth to have something like this avoid breaking code that
exists out there (some might consider it as already broken, but for many if
it works - especially if it worked for years - it isn't broken and IMO that
is a valid stance to take).


On Fri, Feb 12, 2016 at 3:38 PM, Juha Manninen 
wrote:

> On Fri, Feb 12, 2016 at 3:25 PM, Michael Schnell 
> wrote:
> > Any automatic type conversion would kill the application.
> > [...]
> > will this be possible with future versions of Lazarus ,as well ?
>
> I guess you mean automatic encoding conversion for strings. (?)
> The automatic conversion is NOT a feature of Lazarus. It is a feature
> of FPC 3.0+.
> If you don't want it then you can continue using FPC 2.6.4. It is a
> valid choice in some cases, thus Lazarus will support FPC 2.6.4 for
> some time to come.
>
> Juha
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] RFC : "Resolved View"

[Michael Van Canneyt]

On Fri, 12 Feb 2016, Mattias Gaertner wrote:


On Fri, 12 Feb 2016 00:54:38 +0100 (CET)
Michael Van Canneyt  wrote:


[...]
By this I mean a view of a unit as the compiler will see it:
- Correct include files included
- IFDefs properly resolved.

The IDE groks include files and can already syntax highlight conditional code,
so the necessary mechanisms surely are in place.


Yes, in fact the codetools create such a source as first step. It is
called the "cleaned source". Skipped code is in special comments and
there is a map to the original sources.
So it is possible to show it in a read-only synedit. With a bit more
work the view can support code navigation and code explorer.
It would be more work to integrate such a view in the source editor.
Especially editing would be complex.
What should happen when the include file of the cursor is no longer in
the unit?
What about include files used twice in a unit?


Yes, that happens in the RTL as a kind of poor-mans generics.





This view can be read-only for all I care, can optionally have gutter markers
for 'special' locations (where includes occur or IFDEFS were observed).
Maybe gutter colors/folds to indicate includes, etc.
How this view is to be entered is also up for discussion.

Just running an idea up the flagpole...

If it's pure balderdash, feel free to say so.


A read-only view is a good idea. Supporting editing might not be worth
the trouble.


Indeed. In view of what can happen, I think read-only is the only viable
option.



Maybe someone can implement a package adding a "unit explorer" - a
window with pages for units, with code navigation and a light weight
code explorer. Jumping between source editor and unit explorer could be done 
with menu items (and/or icons in the tool bar).

Another idea is to show links to the include structure of the unit, for
example on top of an include file or in the code explorer.


; So many ideas, so little time

Luckily we have a SuperMattias on board. Now to get that globe to spin
backwards... ;)

Michael.

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

Re: [Lazarus] Lazarus application crash. Is PostMessage thread safe?

[Michael Schnell]

On 02/12/2016 03:17 PM, Mattias Gaertner wrote:
IMHO, Michael, you should not redefine words. It confuses people. 
Reentrant means it can be called again, while it is still running. It 
does not need to be thread-safe. 


Sorry that was not me. The subject here is " thread save " ,so I 
tried to explain exactly the difference you mention.


-Michael

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

Re: [Lazarus] non Unicodode application

[Michael Van Canneyt]

On Fri, 12 Feb 2016, Michael Schnell wrote:


On 02/12/2016 03:16 PM, Michael Van Canneyt wrote:



On Fri, 12 Feb 2016, Michael Schnell wrote:


On 02/12/2016 02:38 PM, Michael Van Canneyt wrote:


Just use RawByteString as stringtype for all parameters and variables
in calls where  you don't want code page conversions to occur.


This would mean rewriting the complete application. This obviously is not 
desired .


Tish...

{$define String:=RawByteString}

and you are done.


I don't thinks this is true.

Many built-in functions and RTL functions and classes (such as "pos" and 
"TStrings") explicitly use "string" as parameter and property type. If they 
are not re-compiled they will not work at all or not as expected .


Then you are, as they say, f*d...

Michael.

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

Re: [Lazarus] non Unicodode application

[Juha Manninen]

On Fri, Feb 12, 2016 at 4:18 PM, Michael Schnell  wrote:
> Now a friend of mine is faced by a similar task. But here he wants to keep a
> (small) GUI and he does not want to go for Linux but for 64 Bit.

Both Delphi and FPC now support 64-bit. I don't know how that relates
to dynamic String encoding.

> But the challenge is rather similar, and again there *might* be hope to 
> convert
> a professional application and programmer team from Delphi to Lazarus.

Sure there is hope. See the new UTF-8 support:
  http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus

The only problem comes if you depend on Windows system codepage a lot.
That's why there is :
  http://wiki.freepascal.org/Lazarus_with_FPC3.0_without_UTF-8_mode
Note: Even there FPC 3.0 still has the dynamic string encoding but it
is still useful.

Juha

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

Re: [Lazarus] non Unicodode application

[Juha Manninen]

On Fri, Feb 12, 2016 at 3:25 PM, Michael Schnell  wrote:
> Any automatic type conversion would kill the application.
> [...]
> will this be possible with future versions of Lazarus ,as well ?

I guess you mean automatic encoding conversion for strings. (?)
The automatic conversion is NOT a feature of Lazarus. It is a feature
of FPC 3.0+.
If you don't want it then you can continue using FPC 2.6.4. It is a
valid choice in some cases, thus Lazarus will support FPC 2.6.4 for
some time to come.

Juha

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

Re: [Lazarus] non Unicodode application

[Michael Schnell]

On 02/12/2016 02:38 PM, Michael Van Canneyt wrote:


Just use RawByteString as stringtype for all parameters and variables
in calls where  you don't want code page conversions to occur.


This would mean rewriting the complete application. This obviously is 
not desired .


-Michael

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

Re: [Lazarus] non Unicodode application

[Michael Schnell]

On 02/12/2016 03:16 PM, Michael Van Canneyt wrote:


Tish...

{$define String:=RawByteString}

and you are done.


I'll let him know...

-Michael

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

Re: [Lazarus] non Unicodode application

[Graeme Geldenhuys]

On 2016-02-12 14:16, Michael Van Canneyt wrote:
> {$define String:=RawByteString}
> 
> and you are done.


Awesome!


FPC:1
Delphi: 0

:)


Regards,
  G.



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

Re: [Lazarus] non Unicodode application

[Michael Schnell]

On 02/12/2016 03:16 PM, Michael Van Canneyt wrote:



On Fri, 12 Feb 2016, Michael Schnell wrote:


On 02/12/2016 02:38 PM, Michael Van Canneyt wrote:


Just use RawByteString as stringtype for all parameters and variables
in calls where  you don't want code page conversions to occur.


This would mean rewriting the complete application. This obviously is 
not desired .


Tish...

{$define String:=RawByteString}

and you are done.


I don't thinks this is true.

Many built-in functions and RTL functions and classes (such as "pos" and 
"TStrings") explicitly use "string" as parameter and property type. If 
they are not re-compiled they will not work at all or not as expected .


-Michael

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

Re: [Lazarus] Lazarus application crash. Is PostMessage thread safe?

[Michael Schnell]

On 02/10/2016 10:12 PM, C Western wrote:


My understanding is Application.ProcessMessages has to be reentrant ...


As calling Application.ProcessMessages is only allowed from the main 
thread it does not need to be reentrant = thread-save.


Of course it can be called recursively and it hence is reentrant in that 
meaning.


-Michael


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

Re: [Lazarus] non Unicodode application

[Michael Schnell]

On 02/12/2016 02:57 PM, Juha Manninen wrote:
And yes, often the same arguments were repeated by the same person who 
started this thread.


At the time I did those researches and discussions, my colleagues here 
were interested in porting their Delphi application to Linux using 
Lazarus and I tried to help. They finally decided do delay the task, and 
now, as we have Windows 10 IOT, they supposedly are not interested any 
more at all, as Delphi applications (services without a GUI)  do run on 
Win 10 IOT


Now a friend of mine is faced by a similar task. But here he wants to 
keep a (small) GUI and he does not want to go for Linux but for 64 Bit.


But the challenge is rather similar, and again there *might* be hope to 
convert a professional application and programmer team from Delphi to 
Lazarus.


-Michael

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

Re: [Lazarus] non Unicodode application

[Michael Van Canneyt]

On Fri, 12 Feb 2016, Michael Schnell wrote:


Hi Experts,

A friend of mine wants to port an application from Delphi 7 to a be a Lazarus 
64 Bit Windows application.


This (huge) application only features a very limited GIU, but uses strings 
lot for "uncoded" characters, going in and out via TCP/IP. Any automatic type 
conversion would kill the application.


If you code well, none will happen.



So it would be necessary that fpc is configured to use the (old) 8 bit 
Strings. These might be used with UTF8 encoding for the GUI stuff (and for 
some limited locations in the business-code with *explicit* conversion).


Is this possible with the current version of Lazarus  ?

As I lost the clue on the planned path regarding code-aware strings: will 
this be possible with future versions of Lazarus ,as well ?


It is possible today. You don't need an 'old' style fpc.

Just use RawByteString as stringtype for all parameters and variables
in calls where  you don't want code page conversions to occur. The compiler
will not touch the codepage then.

Michael.

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

Re: [Lazarus] non Unicodode application

[Michael Van Canneyt]

On Fri, 12 Feb 2016, Michael Schnell wrote:


On 02/12/2016 02:38 PM, Michael Van Canneyt wrote:


Just use RawByteString as stringtype for all parameters and variables
in calls where  you don't want code page conversions to occur.


This would mean rewriting the complete application. This obviously is not 
desired .


Tish...

{$define String:=RawByteString}

and you are done.

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

[Lazarus] Bug in MY code. fpc 3.0.0 did NOT detect - leads to strange error.

[Donald Ziesig]

Hi All!

After a multi-day debugging binge, I found the problem described in my 
previous email.


Quick summary:

Common Library has a unit which defines a generic class that itself is 
derived from a class from another unit of the same library.


Application Library has many units which specialize the generic class.

Compiling the Application LIbrary causes a "File not found" error giving 
the name of a valid file (the one declaring the generic) but in an 
incorrect directory,  There is no indication of where the failure 
(file:line no) occurs.  There is no sign of the file where the error 
message says it is (that part is correct, but why it happens is not).


A long series of tests determined that the error occurs in all files 
that specialize the generic class.  I had not touched the file declaring 
the generic class in years.


The bug in my code was in the Common Library unit that declared the 
class from which the generic class was derived.  FPC 3.0.0 did not 
detect the following error in the class declaration:


class function Load( TextIO : TTextIO; aParent : TPersists = nil ) 
: TPersists; virtual; overload; // Calls read afterwards


procedure Load( TextIO : TTextIO ); overload; // Loads without 
creating *<<< this was newly added and caused the p**roblem. fpc did not 
object!


*This module is many years old. I know now that the class function could 
have been replaced by a constructor, but that would require refactoring 
many working programs.


I added the procedure recently to simplify a lot of application code 
(which it did).  It had been working without the error for a few days.  
I don't know what I did to trigger the failure, but once I did it would 
not go away (that in itself is problematic, I would have expected the 
failure right after I introduced the bug).


The first instance of the error occurred using Lazarus 1.7/fpc 3.0.0 on 
Raspbian.  During the bug hunt, I copied the code to my laptop where it 
occurred using Lazarus 1.6RC2/fpc 3.0.0 on Linux Mint 17.3.


When I changed the code to:

class function Load( TextIO : TTextIO; aParent : TPersists = nil ) 
: TPersists; virtual; // Calls read afterwards


procedure LoadExisting( TextIO : TTextIO );  // Loads without creating

and refactored, the errors disappeared and the recursion tests worked.

I believe this is a Compiler bug so I will post a bug report for fpc 
over the weekend.


Comments will be appreciated.

Don Ziesig


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

Re: [Lazarus] 5dpo components last update

[Paulo Costa]

On 11-Feb-16 23:33, Michael Van Canneyt wrote:



On Thu, 11 Feb 2016, Paulo Costa wrote:


On 11-Feb-16 21:48, Michael Van Canneyt wrote:

The most important changes are:
- TSdpoSerial tested and working on the Raspberry Pi 2.



Question: can these components be used to work with the pi's camera ?


Now I can answer:

Yes! The UVC component (TSdpoVideo4L2) works with the native V4L2 driver!

With a raspberry pi 2, I've captured and displayed a 640x480 image at 30 
fps.

I can send you the code if you want.

The supplied example does not work out of the box because the gtk based 
form viewer component isn't working with the raspberry pi. I had to 
replace it with a bgrabitmap based one. That adds one more dependency. 
Do you have any suggestion for a fpc "native" alternative?


Paulo Costa


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

Re: [Lazarus] non Unicodode application

[Juha Manninen]

On Fri, Feb 12, 2016 at 3:38 PM, Michael Van Canneyt
 wrote:
> Just use RawByteString as stringtype for all parameters and variables
> in calls where  you don't want code page conversions to occur. The compiler
> will not touch the codepage then.

Ok, true. That works, too. :)

Juha

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

Re: [Lazarus] Lazarus application crash. Is PostMessage thread safe?

[Mattias Gaertner]

On Fri, 12 Feb 2016 14:53:29 +0100
Michael Schnell  wrote:

> On 02/10/2016 10:12 PM, C Western wrote:
> >
> > My understanding is Application.ProcessMessages has to be reentrant ...
> 
> As calling Application.ProcessMessages is only allowed from the main 
> thread it does not need to be reentrant = thread-save.

IMHO, Michael, you should not redefine words. It confuses people.
Reentrant means it can be called again, while it is still running. It
does not need to be thread-safe. And a thread-safe function does not
need to be reentrant.
Application.ProcessMessages itself is reentrant, but it is not
thread-safe. In fact, as already noted by Michael, it must only be
called by the main thread.
But Application.ProcessMessages can call almost any event
handler, which might not support changing certain properties while
executing.

 
> Of course it can be called recursively and it hence is reentrant in that 
> meaning.

True.

Mattias

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

Re: [Lazarus] non Unicodode application

[Mattias Gaertner]

On Fri, 12 Feb 2016 15:38:49 +0200
Juha Manninen  wrote:

> On Fri, Feb 12, 2016 at 3:25 PM, Michael Schnell  wrote:
> > Any automatic type conversion would kill the application.
> > [...]
> > will this be possible with future versions of Lazarus ,as well ?
> 
> I guess you mean automatic encoding conversion for strings. (?)
> The automatic conversion is NOT a feature of Lazarus. It is a feature
> of FPC 3.0+.
> If you don't want it then you can continue using FPC 2.6.4. It is a
> valid choice in some cases, thus Lazarus will support FPC 2.6.4 for
> some time to come.

True, although the wording might be misleading.
FPC 3.0+ does not arbitrarily change encoding of strings.
That's why the LCL can use UTF-8 in AnsiStrings even without the new
UTF-8 mode.
It then works pretty similar to FPC 2.6.4.

Mattias

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

Re: [Lazarus] non Unicodode application

[Michael Schnell]

On 02/12/2016 05:37 PM, Dmitry Boyarintsev wrote:


In this particular case (of porting Delphi 7 code straight to FPC 
3.0.0) is a matter of backward compatibility.

Yep.

Not only to D7, but also to legacy fpc and Lazarus versions, that (as we 
all know) were modeled after D7 (and friends).


I think that it is *very* desirable to provide configuration options to 
provide full backwards compatibility (while still allow to use as many 
of the new features as possible when explicitly writing coding for this).


-Michael

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

Re: [Lazarus] non Unicodode application

[Juha Manninen]

On Fri, Feb 12, 2016 at 6:52 PM, Michael Schnell  wrote:
> I think that it is *very* desirable to provide configuration options to
> provide full backwards compatibility (while still allow to use as many of
> the new features as possible when explicitly writing coding for this).

Uhhh...
Michael Schnell, how is it possible you behave like a complete newbie
with FPC's String encoding issues, after so many years of arguing
about it in various mailing lists?
Please show some respect to the people who made it work and even documented it.
For example these questions :

> That would mean that the type "String" is 8 Bit  ?
> That would mean that 8 bit Strings are used in TStrings and hence in 
> TStringList ?
> That would mean that (e.g.) storing 8 bit "String"s in a TStringList would 
> not do any conversion at all ?
> And it would mean that pos() and friends work on 8 bit Strings (and wist 
> simple byte-positions and length)   ?

... were answered in the wiki pages I linked to you, and they are
obvious after just minimal testing.
If you find a bug then let us know, otherwise please show some
positive attitude. The new UTF-8 system "just works" in most
situations.
I remember you repeated the same arguments against FPC's new String
type in FPC lists during many years again and again.
Let's not do the same here.

Juha

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

Re: [Lazarus] non Unicodode application

[Michael Schnell]

This does sound good. :-)

-Michael

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

Re: [Lazarus] non Unicodode application

[Michael Schnell]

On 02/12/2016 05:23 PM, Mattias Gaertner wrote:
If your friend use string literals in Delphi they are encoded in 
system code page. Here might be some traps.


He will easily  be able to handle this .

Thanks a lot !

-Michael

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

Re: [Lazarus] RFC : "Resolved View"

[Mattias Gaertner]

On Fri, 12 Feb 2016 15:25:11 +0100 (CET)
Michael Van Canneyt  wrote:

>[...]
> > What about include files used twice in a unit?
> 
> Yes, that happens in the RTL as a kind of poor-mans generics.

That's no problem when the file compiles. But while typing a directive
the unit structure falls apart. That's no easy problem for a source
editor.


>[...]
> Luckily we have a SuperMattias on board. Now to get that globe to spin
> backwards... ;)

Actually Superman traveled back in time, not the globe. The film was
wrong.

Mattias

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

Re: [Lazarus] non Unicodode application

[Michael Schnell]

On 02/12/2016 03:54 PM, Juha Manninen wrote:

Sure there is hope. See the new UTF-8 support:
   http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus


I'll let him know...

And of course I will take read this myself, too.

In fact he does not want "Better_Unicode_Support" but 
*no_unicode_support* ;-)


But maybe this is possible somehow



The only problem comes if you depend on Windows system codepage a lot.
That's why there is :
   http://wiki.freepascal.org/Lazarus_with_FPC3.0_without_UTF-8_mode



The code does not depend on Windows system codepage at all. The just 
receives text (characters) from TCP/IP, converts it using databases and 
some "embedded"/"realtime" conditions and sends it out via TCP/IP. Not 
windows or other codepages "implicitly" involved. If some o the work 
needs codepage conversion, this is done explicitly in user code.


-Michael

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

Re: [Lazarus] non Unicodode application

[Michael Schnell]

On 02/12/2016 03:54 PM, Juha Manninen wrote:
Both Delphi and FPC now support 64-bit. I don't know how that relates 
to dynamic String encoding.

.
   http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus

AFAIK, any 64 bit Delphi forces UTF-16 Unicode and cant do what is 
described in the wiki page you mention.


-Michael

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

Re: [Lazarus] non Unicodode application

[Michael Schnell]

On 02/12/2016 03:54 PM, Juha Manninen wrote:

Sure there is hope. See the new UTF-8 support:
   http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus


This page says:

"This page covers Unicode support in Lazarus programs (console or 
server, no GUI) and applications (GUI with LCL) using features of FPC 
3.0+. "

"RTL with default codepage UTF-8"

That would mean that the type "String" is 8 Bit  ?

That would mean that 8 bit Strings are used in TStrings and hence in 
TStringList ?


That would mean that (e.g.) storing 8 bit "String"s in a TStringList 
would not do any conversion at all ?


And it would mean that pos() and friends work on 8 bit Strings (and wist 
simple byte-positions and length)   ?



If string constants and strings coming from and going to the GUI are 
implicitly converted, I suppose this is manageable.


Is all this is here to stay, I think my friend could use Lazarus and fpc 
for his task.


-Michael

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

Re: [Lazarus] RFC : "Resolved View"

[Michael Van Canneyt]

On Fri, 12 Feb 2016, Mattias Gaertner wrote:


On Fri, 12 Feb 2016 15:25:11 +0100 (CET)
Michael Van Canneyt  wrote:


[...]

What about include files used twice in a unit?


Yes, that happens in the RTL as a kind of poor-mans generics.


That's no problem when the file compiles. But while typing a directive
the unit structure falls apart. That's no easy problem for a source
editor.


Yes, absolutely.
Well, even a read-only view will get us a long way, I expect.


[...]
Luckily we have a SuperMattias on board. Now to get that globe to spin
backwards... ;)


Actually Superman traveled back in time, not the globe. The film was
wrong.


[Michael falls from his chair in disbelief]

All my beliefs shattered


Michael.

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

Re: [Lazarus] non Unicodode application

[Mattias Gaertner]

On Fri, 12 Feb 2016 16:41:23 +0100
Michael Schnell  wrote:

> On 02/12/2016 03:54 PM, Juha Manninen wrote:
> > Sure there is hope. See the new UTF-8 support:
> >http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus
> >
> This page says:
> 
> "This page covers Unicode support in Lazarus programs (console or 
> server, no GUI) and applications (GUI with LCL) using features of FPC 
> 3.0+. "
> "RTL with default codepage UTF-8"
> 
> That would mean that the type "String" is 8 Bit  ?

Yes, 8bit per Char.

 
> That would mean that 8 bit Strings are used in TStrings and hence in 
> TStringList ?

Yes.

 
> That would mean that (e.g.) storing 8 bit "String"s in a TStringList 
> would not do any conversion at all ?

Yes.

 
> And it would mean that pos() and friends work on 8 bit Strings (and wist 
> simple byte-positions and length)   ?

Yes.

 
> If string constants and strings coming from and going to the GUI are 
> implicitly converted, I suppose this is manageable.

Without UTF-8 mode you are responsible to convert the LCL UTF-8 strings
to whatever needed (probably system code page, UTF8ToSyS).

With UTF-8 mode all strings are by default UTF-8 and implicitely
converted when using functions like FileExists or
TStrings.LoadFromFile. If you want to work in system code page you have
to convert back and forth between RTL+LCL and your code. 

When converting a Delphi 7 application it depends on what charset(s) the
application supports to decide which mode is easier/better.

Just saying "uncoded strings in TCP/IP" is not enough information.
That can be done in both modes.
 
> Is all this is here to stay, I think my friend could use Lazarus and fpc 
> for his task.

Mattias

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

Re: [Lazarus] non Unicodode application

[Dmitry Boyarintsev]

On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt  wrote:

> {$define String:=RawByteString}
>
> and you are done.
>

How to achieve the same effect from command line?

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

Re: [Lazarus] non Unicodode application

[Mattias Gaertner]

On Fri, 12 Feb 2016 17:16:29 +0100 (CET)
Michael Van Canneyt  wrote:

>[...]
> >> {$define String:=RawByteString}
>[...]
> Type
>T = Type Ansistring(850);

AFAIK this was introduced with Delphi 2009. Not available in Delphi 7.

Mattias

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

Re: [Lazarus] non Unicodode application

[Mattias Gaertner]

On Fri, 12 Feb 2016 15:16:38 +0100 (CET)
Michael Van Canneyt  wrote:

>[...]
> {$define String:=RawByteString}
> 
> and you are done.

Won't compile when calling RTL functions with var parameters.

I fail to see why RawByteString should do less conversions than using
AnsiString, when porting a Delphi 7 application. Can you give an
example?

Mattias

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

Re: [Lazarus] non Unicodode application

[Michael Van Canneyt]

On Fri, 12 Feb 2016, Mattias Gaertner wrote:


On Fri, 12 Feb 2016 15:16:38 +0100 (CET)
Michael Van Canneyt  wrote:


[...]
{$define String:=RawByteString}

and you are done.


Won't compile when calling RTL functions with var parameters.

I fail to see why RawByteString should do less conversions than using
AnsiString, when porting a Delphi 7 application. Can you give an
example?


As I understand it, calling

Procedure MyProcedure(S : RawByteString) ;

begin
end;

with

Type
  T = Type Ansistring(850);


Var
  D : T;

begin
  MyProcedure(d)
end;

will not cause any code page conversion. While if it was

Procedure MyProcedure(S : String) ;

Then the compiler would first convert the code page to
DefaultSystemCodePage or CP_ACP

Michael.

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

Re: [Lazarus] non Unicodode application

[Michael Schnell]

On 02/12/2016 03:55 PM, Mattias Gaertner wrote:

True, although the wording might be misleading.
FPC 3.0+ does not arbitrarily change encoding of strings.
That's why the LCL can use UTF-8 in AnsiStrings even without the new
UTF-8 mode.
It then works pretty similar to FPC 2.6.4.



This is exactly what I seemed to remember from multiple discussions in 
multiple forums, and this is why I recommended my friend to take a look 
at Lazarus/FPC.



the LCL *can* use UTF-8
How to set it to do so ? (I may be able guess, but as I said I am asking 
for a pal who is rather new to Lazarus/FPC, so explicit pointers are 
appreciated. ...)



even without the new UTF-8 mode.

How to set this mode  when compiling with Lazarus  ?
What mode do you think is more appropriate when most work is done on 
strings that just have no or an unknown encoding ?


Thanks a lot !
-Michael



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

Re: [Lazarus] RFC : "Resolved View"

[Martin Frb]

On 12/02/2016 12:45, Michael Van Canneyt wrote:


Well, if it is on the todo list, I don't need to file a feature 
request ;)


Not really on todo, only remembered as being wanted.

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

Re: [Lazarus] non Unicodode application

[Michael Schnell]

On 02/12/2016 03:53 PM, Mattias Gaertner wrote:
Your friend can use the LCL for the GUI with disabled UTF-8 mode. 

Sounds great !
He has to check (convert) the strings between his TCP/IP code and the 
LCL controls (e.g. UTF8ToSys). As he has only a small GUI this should 
be easy. 
No problem. The current D7 code does this,anyway, it just converts 
to/from ANSI with the appropriate code page,and now would need to 
convert to/from UTF8 .



The new UTF-8 mode is easier for new projects. Many old projects still
use the old mode. So chances are high that it will be supported the
next years.
Am I correct assuming that "The new UTF-8 mode" is this 
http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus  ?


We will try to find out if this mode or the "old" is more suitable for 
the task in question.


-Michael

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

Re: [Lazarus] 5dpo components last update

[Michael Van Canneyt]

On Fri, 12 Feb 2016, Paulo Costa wrote:


On 11-Feb-16 23:33, Michael Van Canneyt wrote:



On Thu, 11 Feb 2016, Paulo Costa wrote:


On 11-Feb-16 21:48, Michael Van Canneyt wrote:

The most important changes are:
- TSdpoSerial tested and working on the Raspberry Pi 2.



Question: can these components be used to work with the pi's camera ?


Now I can answer:

Yes! The UVC component (TSdpoVideo4L2) works with the native V4L2 driver!


Great news.



With a raspberry pi 2, I've captured and displayed a 640x480 image at 30 fps.
I can send you the code if you want.


Yes, please !!

Can you also send me the complete configuration you used ?
(model pi, raspbian version, fpc, laz etc.)

I would like to write an article for Blaise Pascal magazine, the editor will
be very pleased to hear this, he has been asking for it since a long time :)

The supplied example does not work out of the box because the gtk based form 
viewer component isn't working with the raspberry pi. I had to replace it 
with a bgrabitmap based one. That adds one more dependency. Do you have any 
suggestion for a fpc "native" alternative?


You mean an image component ? What is missing in the ones in fpImage ?

Michael.

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

Re: [Lazarus] RFC : "Resolved View"

[Martin Frb]

On 12/02/2016 16:10, Michael Van Canneyt wrote:


On Fri, 12 Feb 2016, Martin Frb wrote:



Not really on todo, only remembered as being wanted.


Should I file a request anyway or has memory been sufficiently 
refreshed ?


I had not yet read Mattias will go for a different approach solving it.

The problem for me is, that I will not have the time to look at it any 
time soon.


Also my approach would have more been "editing includes inline" rather 
than a cleaned source.


If I surprisingly will get time, then we can still have both one day in 
the future.


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

Re: [Lazarus] non Unicodode application

[Mattias Gaertner]

On Fri, 12 Feb 2016 16:53:12 +0100
Michael Schnell  wrote:

>[...]
> > even without the new UTF-8 mode.
> How to set this mode  when compiling with Lazarus  ?

See here
http://wiki.freepascal.org/Lazarus_with_FPC3.0_without_UTF-8_mode

> What mode do you think is more appropriate when most work is done on 
> strings that just have no or an unknown encoding ?

If your strings don't have an encoding the compiler treats them as
default encoding and so the mode does not matter.
Your friend's application won't pass such strings to the GUI, so no
problem with the LCL.
You just have to be careful when mixing strings and widestrings (just
like Delphi), or strings with non default codepage (AFAIK Delphi 7 does
not have them, but maybe you use a package that does).

If your friend use string literals in Delphi they are encoded in system
code page. Here might be some traps.

Mattias

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

Re: [Lazarus] non Unicodode application

[Dmitry Boyarintsev]

On Fri, Feb 12, 2016 at 11:24 AM, Sven Barth 
wrote:

> Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev" <
> skalogryz.li...@gmail.com>:
> >
> > On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt <
> mich...@freepascal.org> wrote:
> >>
> >> {$define String:=RawByteString}
> >>
> >> and you are done.
> >
> >
> > How to achieve the same effect from command line?
>
> Just don't. There are things that are not worth the trouble and this is
> one of them.
>
In this particular case (of porting Delphi 7 code straight to FPC 3.0.0) is
a matter of backward compatibility.

I could agree that there are very little options left:
* Delphi (whatever version supports 64bit) - changes in code are needed
* FPC 3.0.0 - {$define String:=RawByteString} must be added to every unit
(or a single .inc file if used)
* FPC 2.6.4 - no changes needed (?)
So it might be indeed a thing not worth the trouble.

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

Re: [Lazarus] RFC : "Resolved View"

[Michael Van Canneyt]

On Fri, 12 Feb 2016, Martin Frb wrote:


On 12/02/2016 12:45, Michael Van Canneyt wrote:


Well, if it is on the todo list, I don't need to file a feature request ;)


Not really on todo, only remembered as being wanted.


Should I file a request anyway or has memory been sufficiently refreshed ?

Michael.

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

Re: [Lazarus] non Unicodode application

[Sven Barth]

Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev" :
>
> On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt <
mich...@freepascal.org> wrote:
>>
>> {$define String:=RawByteString}
>>
>> and you are done.
>
>
> How to achieve the same effect from command line?

Just don't. There are things that are not worth the trouble and this is one
of them.

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

Re: [Lazarus] non Unicodode application

[Michael Van Canneyt]

On Fri, 12 Feb 2016, Sven Barth wrote:


Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev"  wrote:


{$define String:=RawByteString}

and you are done.



How to achieve the same effect from command line?


Just don't. There are things that are not worth the trouble and this is one
of them.


I normally would not advise such a trick.
But if the alternative is 'rewriting the whole application'...
then probably anything is worth a shot...

Michael.

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

[Lazarus] Guess the problem with Heap

[Aradeonas]

Hi,

Im working on one of my projects and tried to make a release version, so
I used shortcut button in build modes and add release mode but when I
compile and run I get SIGSEGV error when main form want to be create.
After many tries I found out that if I check "Use Heaptrc unit" in
project debugging option program will run correctly even it is release
mode so there is no debug info. So simple : If I check that option and
use Heaptrc, no problem and if I unchecked it, error .

Its a old project and I dont remind any code I write about heap so I
cant find the problem so I want to ask anyone can guess what code can
make such problem?

Regards, Ara

-- 
http://www.fastmail.com - Accessible with your email software
  or over the web

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

Re: [Lazarus] Guess the problem with Heap

[Martin Frb]

On 12/02/2016 19:04, Aradeonas wrote:

Hi,
Im working on one of my projects and tried to make a release version, 
so I used shortcut button in build modes and add release mode but when 
I compile and run I get SIGSEGV error when main form want to be create.
After many tries I found out that if I check "Use Heaptrc unit" in 
project debugging option program will run correctly even it is release 
mode so there is no debug info.

So simple :
If I check that option and use Heaptrc, no problem and if I unchecked 
it, error .
Its a old project and I dont remind any code I write about heap so I 
cant find the problem so I want to ask anyone can guess what code can 
make such problem?




Common candidates are any code that
1) accesses memory behind or before allocatien
  dynArray[-10]  := x
  dynArray[length(dynArray)+10] := x

  foo := TObject.create;
  TChildClass(foo).something 

  getmem, and then access outside the bounds
  pointer 

2) any code accessing memory that was freed (any of the above)

---
and worst of all, the error may or may not be triggered at the time of 
accessing the invalid mem. Sometimes it fails at some other completely 
valid code.


heaptrc changes memory layout as it stores the leaktrace info, and that 
means that by pure luck, the invalid memory access you do, does not 
affect the rest of your data. (or not anything that you detected yet)


A)
compile with heaptrc
and -Criot  and any other flag you can find. Note the LCL does not work 
with -CR (upper R)


set the HEAPTRC environment to "keepreleased"

B)
If you can compile an Linux and run with valgrind.




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

Re: [Lazarus] 5dpo components last update

[Michael Van Canneyt]

On Fri, 12 Feb 2016, Paulo Costa wrote:


On 12-Feb-16 16:04, Michael Van Canneyt wrote:

Can you also send me the complete configuration you used ?


The setup:

Raspberry Pi 2 Model B
Raspbian Jessie (Debian version 8.0)
Lazarus 1.2.4+dfsg2-1 (It is the version available on their repository. Call 
me lazy :)
fpc 2.6.4+dfsg-4+rpi1 (Again, it is the version available on their 
repository.)


I have update the repository to include the Raspberry Pi example.


Thank you.




I would like to write an article for Blaise Pascal magazine, the editor
will
be very pleased to hear this, he has been asking for it since a long
time :)


Nice :)


The supplied example does not work out of the box because the gtk
based form viewer component isn't working with the raspberry pi. I had
to replace it with a bgrabitmap based one. That adds one more
dependency. Do you have any suggestion for a fpc "native" alternative?


You mean an image component ? What is missing in the ones in fpImage ?


When I was investigating fpImage, in the wiki 
(ttp://wiki.freepascal.org/fcl-image) came across with this:
"fcl-image is written for maximal portability and maintainability and is 
quite slow. The main storage type is 16-bit RGBA, storing always 64-bit per 
pixel, and a function is called to get each pixel."


That information is old and outdated. 
You can perfectly have other storage formats in any buffer you like.


But a dependency on bgrabitmap is not the end of the world.

Michael.

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

Re: [Lazarus] non Unicodode application

[Sven Barth]

Am 12.02.2016 17:37 schrieb "Dmitry Boyarintsev" :
>
> On Fri, Feb 12, 2016 at 11:24 AM, Sven Barth 
wrote:
>>
>> Am 12.02.2016 17:16 schrieb "Dmitry Boyarintsev" <
skalogryz.li...@gmail.com>:
>> >
>> > On Fri, Feb 12, 2016 at 9:16 AM, Michael Van Canneyt <
mich...@freepascal.org> wrote:
>> >>
>> >> {$define String:=RawByteString}
>> >>
>> >> and you are done.
>> >
>> >
>> > How to achieve the same effect from command line?
>>
>> Just don't. There are things that are not worth the trouble and this is
one of them.
>
> In this particular case (of porting Delphi 7 code straight to FPC 3.0.0)
is a matter of backward compatibility.
>
> I could agree that there are very little options left:
> * Delphi (whatever version supports 64bit) - changes in code are needed
> * FPC 3.0.0 - {$define String:=RawByteString} must be added to every unit
(or a single .inc file if used)
> * FPC 2.6.4 - no changes needed (?)
> So it might be indeed a thing not worth the trouble.

As long as you don't change the default code page strings in 3.0.0 should
behave very close to 2.6.4. The only exceptions would be API that talk to
the system (e.g. file APIs, though AFAIK we haven't really touched those
yet and the FindFirst API).
But in the end one should simply try it and after all one should have
testcases that help one discover problems anyway...

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

Re: [Lazarus] 5dpo components last update

[Paulo Costa]

On 12-Feb-16 16:04, Michael Van Canneyt wrote:

Can you also send me the complete configuration you used ?


The setup:

Raspberry Pi 2 Model B
Raspbian Jessie (Debian version 8.0)
Lazarus 1.2.4+dfsg2-1 (It is the version available on their repository. 
Call me lazy :)
fpc 2.6.4+dfsg-4+rpi1 (Again, it is the version available on their 
repository.)


I have update the repository to include the Raspberry Pi example.


I would like to write an article for Blaise Pascal magazine, the editor
will
be very pleased to hear this, he has been asking for it since a long
time :)


Nice :)


The supplied example does not work out of the box because the gtk
based form viewer component isn't working with the raspberry pi. I had
to replace it with a bgrabitmap based one. That adds one more
dependency. Do you have any suggestion for a fpc "native" alternative?


You mean an image component ? What is missing in the ones in fpImage ?


When I was investigating fpImage, in the wiki 
(ttp://wiki.freepascal.org/fcl-image) came across with this:
"fcl-image is written for maximal portability and maintainability and is 
quite slow. The main storage type is 16-bit RGBA, storing always 64-bit 
per pixel, and a function is called to get each pixel."


That does not seem good for showing a 640x480 image 30 times per second.
If the problem was only showing the image, the native overlay 
capabilities could take of that, but usually we want to show also the 
processed image.
For the bgrabitmap I need only to do a direct copy of the acquired 
buffer to its internal storage.


Regards,

Paulo Costa



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