[Lazarus] test if the list is down, since 21.3.13 no mails?!!

2013-03-24 Thread John Landmesser



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


[Lazarus] AdjustClientRect or GetLogicalClientRect: which one to override?

2013-03-24 Thread Bart
Hi,

For a component I'm building I need to let the subcomponents know that
(for aligning) they cannot use the entire client space.
(It is a panel descendant with asymmetrical bevels).

At first I tried AdjustClientRect but that did not work, so I tried
GetLogicalClientRect.
It all seems to work as expected. Subcomponents align to the new borders.

Then the compiler told me (well, it did before, but I didn't notice)
that I forgot to add the override to AdjustClientRect. I fixed that
(and got rid of the overridden GetLogicalClientRect), and this also
works.

So, here's my question: which of these two methods is the right one
to override in this example? And what is the other method intende for?

Bart

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


[Lazarus] New control TLvlGraphControl and new IDE package graph

2013-03-24 Thread Mattias Gaertner
Hi,

I added a new control TLvlGraphControl to package LazControls. It is a
LCL control showing a graph as level graph. Another name is layered
graph.

See the screenshot and see here:
http://wiki.lazarus.freepascal.org/Lazarus_1.2.0_release_notes#TLvlGraphControl

Level graphs can visualize hundreds of nodes and thousands of
edges on a single screen, reducing the need to scroll.
This control has the ability to highlight the edges under
the mouse, so that even complex graphs with thousands of edges can be
explored.
And it highlights back edges so you can quickly find cycles.

The screenshot is from the IDE's Package Graph.

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


Re: [Lazarus] New control TLvlGraphControl and new IDE package graph

2013-03-24 Thread Reinier Olislagers
On 24-3-2013 13:08, Mattias Gaertner wrote:
 Hi,
 
 I added a new control TLvlGraphControl to package LazControls. It is a
 LCL control showing a graph as level graph. Another name is layered
 graph.
 
 See the screenshot and see here:
 http://wiki.lazarus.freepascal.org/Lazarus_1.2.0_release_notes#TLvlGraphControl
 
 Level graphs can visualize hundreds of nodes and thousands of
 edges on a single screen, reducing the need to scroll.
 This control has the ability to highlight the edges under
 the mouse, so that even complex graphs with thousands of edges can be
 explored.
 And it highlights back edges so you can quickly find cycles.
 
 The screenshot is from the IDE's Package Graph.
 


Yep, had noticed that - very handy!

Thanks a lot,
Reinier


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


Re: [Lazarus] New control TLvlGraphControl and new IDE package graph

2013-03-24 Thread Sven Barth

On 24.03.2013 13:08, Mattias Gaertner wrote:

Hi,

I added a new control TLvlGraphControl to package LazControls. It is a
LCL control showing a graph as level graph. Another name is layered
graph.

See the screenshot and see here:
http://wiki.lazarus.freepascal.org/Lazarus_1.2.0_release_notes#TLvlGraphControl

Level graphs can visualize hundreds of nodes and thousands of
edges on a single screen, reducing the need to scroll.
This control has the ability to highlight the edges under
the mouse, so that even complex graphs with thousands of edges can be
explored.
And it highlights back edges so you can quickly find cycles.

The screenshot is from the IDE's Package Graph.


Oooo... nice. It will be interesting to see how this component copes 
with the dependency graph of the compiler units... hehe ^^


Regards,
Sven


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


[Lazarus] How to send Email from Lazarus program under Linux x86-64

2013-03-24 Thread Donald Ziesig

Hi All!

I am trying to implement a program that will send emails to (a subset 
of) an application-specific roster.


I found numerous references to synapse so I downloaded the source which 
includes a .lpk library (it is several years old).  When I tried to 
compile it under Lazarus 1.1, fpc 2.6.2, the compiler could not find a 
method called inet_addr.  I searched the synapse source code and it 
showed numerous references to inet_addr, but no place where it was 
defined for fpc.  I hacked the code so it used linux rather than fpc and 
it failed while looking for unit libc, before ever getting to the 
inet_addr declaration.  I looked for libc and found that it is obsolete 
and does not seem to be available for 64-bit systems anyway.


Has anyone had success in using this library under Linux (x86-64)?

I also examined Indy (which I used successfully years ago on 
Delphi/Borland c++ Builder) but it, too, is obsolete (latest updates 
seem to be circa 2006) and comes with many, many warnings and caveats.


I found Mailpas (also from 2006) but I am having problems compiling the 
library -- it says it can't find a file which really is there where it 
is supposed to be.  -- During the long mailing list shutdown I found 
that the compiler message about a non-existent include file was wrong.  
The actual failure was that the include file uses libc which does not 
exist on my system (same problem as with synapse).  I'll submit a bug 
report as soon as I can.


Is there any other smtp and pop3 code available for Lazarus or will I 
have to generate my own from scratch?


Thanks,

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


Re: [Lazarus] How to send Email from Lazarus program under Linux x86-64

2013-03-24 Thread reinierolislagers
On 24-3-2013 15:19, Donald Ziesig wrote:
 Hi All!
 
 I am trying to implement a program that will send emails to (a subset
 of) an application-specific roster.
 
 I found numerous references to synapse so I downloaded the source which
 includes a .lpk library (it is several years old).  

Yep, seems about 3 years old:
cd C:\Development\extras\synapse
svn log laz_synapse.lpk | more
r129 | geby | 2010-07-02 12:46:39 +0200 (vr, 02 jul 2010) | 3 lines

- improved MACOS compatibility
- workaround for some broken virtual serial ports
- Added Lazarus package

 Has anyone had success in using this library under Linux (x86-64)?

Yes. See e.g. fpctwit, which happily runs under Linux. Also, the fpcup
Lazarus/fpc updater can install synapse for you, also the synapse trunk
version.

AFAIK no need to change any synapse files.

Please see the wiki page on synapse:
http://wiki.lazarus.freepascal.org/synapse

 I also examined Indy (which I used successfully years ago on
 Delphi/Borland c++ Builder) but it, too, is obsolete (latest updates
 seem to be circa 2006) and comes with many, many warnings and caveats.
Please see the indy wiki page:
... ah well, you'll be able to find it. It's cross referenced in the
synapse page as well IIRC.

 Is there any other smtp and pop3 code available for Lazarus or will I
 have to generate my own from scratch?

There certainly is. IIRC, LazSolutions has code for sending email.
Synapse comes with an email example, or has it in the examples directory
on their site.
Code for sending email using synapse is floating around on e.g. the
synapse mailing list...

Good luck,
Reinier

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


Re: [Lazarus] How to send Email from Lazarus program under Linux x86-64

2013-03-24 Thread silvioprog
2013/3/24 reinierolislag...@gmail.com

 On 24-3-2013 15:19, Donald Ziesig wrote:
  Hi All!
 
  I am trying to implement a program that will send emails to (a subset
  of) an application-specific roster.
 
  I found numerous references to synapse so I downloaded the source which
  includes a .lpk library (it is several years old).

 Yep, seems about 3 years old:
 cd C:\Development\extras\synapse
 svn log laz_synapse.lpk | more
 r129 | geby | 2010-07-02 12:46:39 +0200 (vr, 02 jul 2010) | 3 lines

 - improved MACOS compatibility
 - workaround for some broken virtual serial ports
 - Added Lazarus package

  Has anyone had success in using this library under Linux (x86-64)?

 Yes. See e.g. fpctwit, which happily runs under Linux. Also, the fpcup
 Lazarus/fpc updater can install synapse for you, also the synapse trunk
 version.

 AFAIK no need to change any synapse files.

 Please see the wiki page on synapse:
 http://wiki.lazarus.freepascal.org/synapse

  I also examined Indy (which I used successfully years ago on
  Delphi/Borland c++ Builder) but it, too, is obsolete (latest updates
  seem to be circa 2006) and comes with many, many warnings and caveats.
 Please see the indy wiki page:
 ... ah well, you'll be able to find it. It's cross referenced in the
 synapse page as well IIRC.

  Is there any other smtp and pop3 code available for Lazarus or will I
  have to generate my own from scratch?

 There certainly is. IIRC, LazSolutions has code for sending email.
 Synapse comes with an email example, or has it in the examples directory
 on their site.
 Code for sending email using synapse is floating around on e.g. the
 synapse mailing list...

 Good luck,
 Reinier


Thanks for the indication Reinier! :)

Meet the XMailer also:

https://github.com/silvioprog/xmailer

XMailer is a nice plugin for send e-mails easily. It's improved derivation
of LSSendMail. :) (it use Synapse too, and offers support to UTF-8)

-- 
Silvio Clécio
My public projects - github.com/silvioprog
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] New control TLvlGraphControl and new IDE package graph

2013-03-24 Thread Hans-Peter Diettrich

Mattias Gaertner schrieb:

Hi,

I added a new control TLvlGraphControl to package LazControls. It is a
LCL control showing a graph as level graph. Another name is layered
graph.

See the screenshot and see here:
http://wiki.lazarus.freepascal.org/Lazarus_1.2.0_release_notes#TLvlGraphControl


Nice :-)


Level graphs can visualize hundreds of nodes and thousands of
edges on a single screen, reducing the need to scroll.
This control has the ability to highlight the edges under
the mouse, so that even complex graphs with thousands of edges can be
explored.
And it highlights back edges so you can quickly find cycles.

The screenshot is from the IDE's Package Graph.


Did you already consider to analyze the graph using methods known from 
the theory of graphs, like splitting the graph into components?


Graph components can help to structure the display of the entire graph, 
so that e.g. a component can be represented as a single node on the 
screen, which then can be expanded on demand into a more detailed 
representation.


DoDi


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


Re: [Lazarus] New control TLvlGraphControl and new IDE package graph

2013-03-24 Thread Mattias Gaertner
On Sun, 24 Mar 2013 16:31:10 +0100
Hans-Peter Diettrich drdiettri...@aol.com wrote:

 Mattias Gaertner schrieb:
  Hi,
  
  I added a new control TLvlGraphControl to package LazControls. It is a
  LCL control showing a graph as level graph. Another name is layered
  graph.
  
  See the screenshot and see here:
  http://wiki.lazarus.freepascal.org/Lazarus_1.2.0_release_notes#TLvlGraphControl
 
 Nice :-)

Thanks.

 
  Level graphs can visualize hundreds of nodes and thousands of
  edges on a single screen, reducing the need to scroll.
  This control has the ability to highlight the edges under
  the mouse, so that even complex graphs with thousands of edges can be
  explored.
  And it highlights back edges so you can quickly find cycles.
  
  The screenshot is from the IDE's Package Graph.
 
 Did you already consider to analyze the graph using methods known from 
 the theory of graphs, like splitting the graph into components?

TLvlGraph has a property Graph: TLvlGraph, that consists of nodes and
edges. The nodes have arrays of InEdges and OutEdges. So implementing
the normal graph algorithms should be pretty straightforward.
 
 Graph components can help to structure the display of the entire graph, 
 so that e.g. a component can be represented as a single node on the 
 screen, which then can be expanded on demand into a more detailed 
 representation.

Yes, that was my first idea too for packages and units. But it seems
it is more helpful to simply use another lvlgraph
for the details.

Mattias

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


Re: [Lazarus] New control TLvlGraphControl and new IDE package graph

2013-03-24 Thread Juha Manninen
This is close to the reverse engineered class diagram tool that was
discussed already a long time ago.
I thought the most difficult part is automatic layout calculation and
this component implements it quite perfectly. Cool!

Still, it cannot be directly used for a class diagram because there
not only nodes connect to each other but a connection can be from a
property inside a node.
It could be extended with special nodes having connection points, and
edges (lines) having graphs at the ends.
At least a diamond and a circle graph is needed for class diagram lines.

Juha

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


Re: [Lazarus] New control TLvlGraphControl and new IDE package graph

2013-03-24 Thread Mattias Gaertner
On Sun, 24 Mar 2013 13:56:31 +0100
Sven Barth pascaldra...@googlemail.com wrote:

[...]
 Oooo... nice. It will be interesting to see how this component copes 
 with the dependency graph of the compiler units... hehe ^^

Here is are two screenshots of the compiler units.
The first shows the compiler/x86 directory, the second the
compiler/systems directory.
For the units of the compiler directory you need a 4k screen and it's
very messy.
This needs some specials. Like filtering or something like the
components suggested by DoDi.

Mattias
attachment: compiler_x86.pngattachment: compiler_systems.png--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] New control TLvlGraphControl and new IDE package graph

2013-03-24 Thread Sven Barth

On 24.03.2013 17:41, Mattias Gaertner wrote:

On Sun, 24 Mar 2013 13:56:31 +0100
Sven Barth pascaldra...@googlemail.com wrote:


[...]
Oooo... nice. It will be interesting to see how this component copes
with the dependency graph of the compiler units... hehe ^^


Here is are two screenshots of the compiler units.
The first shows the compiler/x86 directory, the second the
compiler/systems directory.
For the units of the compiler directory you need a 4k screen and it's
very messy.
This needs some specials. Like filtering or something like the
components suggested by DoDi.


Components won't help here as the compiler is too interconnected (though 
the CPU directories look rather nice ^^).


I've written a little tool some weeks ago which uses fcl-passrc to 
extract the unit dependencies and prints a dot file which can be 
processed by Graphviz. With this I wanted to check where we might have 
cycles and if we could fix their detection, but for now I've given up, 
because the graph is to messy. As a next step I planned to implement a 
Circos (see http://circos.ca/images/ ) backend for that tool...


Regards,
Sven


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


Re: [Lazarus] New control TLvlGraphControl and new IDE package graph

2013-03-24 Thread Joao Morais
2013/3/24 Sven Barth pascaldra...@googlemail.com:
 I've written a little tool some weeks ago which uses fcl-passrc to extract
 the unit dependencies and prints a dot file which can be processed by
 Graphviz. With this I wanted to check where we might have cycles and if we
 could fix their detection, but for now I've given up, because the graph is
 to messy. As a next step I planned to implement a Circos (see
 http://circos.ca/images/ ) backend for that tool...

Did you try a DSM? I've successfuly used this approach to find cycles
as well as helping me to elaborate a migration strategy of a little
messy project =)

http://en.wikipedia.org/wiki/Design_structure_matrix

Joao Morais

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


Re: [Lazarus] New control TLvlGraphControl and new IDE package graph

2013-03-24 Thread Sven Barth

On 24.03.2013 17:55, Joao Morais wrote:

2013/3/24 Sven Barth pascaldra...@googlemail.com:

I've written a little tool some weeks ago which uses fcl-passrc to extract
the unit dependencies and prints a dot file which can be processed by
Graphviz. With this I wanted to check where we might have cycles and if we
could fix their detection, but for now I've given up, because the graph is
to messy. As a next step I planned to implement a Circos (see
http://circos.ca/images/ ) backend for that tool...


Did you try a DSM? I've successfuly used this approach to find cycles
as well as helping me to elaborate a migration strategy of a little
messy project =)

http://en.wikipedia.org/wiki/Design_structure_matrix


A design structure matrix aka adjency matrix is just a graph in matrix 
form... And I personally prefer visual approaches here :) [even if it 
should mean that I'll need a 4k beamer or a DIN A0 printer to view this 
correctly :P ]


Regards,
Sven


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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Mattias Gaertner
On Sun, 24 Mar 2013 14:51:26 -0300
Leonardo M. Ramé l.r...@griensu.com wrote:

 Hi, I'm copying a buffer of PWord to a TMemoryStream using this code:
 
 lTmpBuff := lBuffer;  
 I := 0;
 while I  lBufSize do
 begin
   lStream.Write(lTmpBuff^, SizeOf(PWord));
   inc(lTmpBuff, 1);
   inc(I, 1);
 end;
 
 As you can see, on each iteration, one PWord is copied. What I would
 like to do, is to copy bigger blocks, for example:
 
 lStream.WriteBuffer(lTmpBuff^, lBufSize);

lStream.WriteBuffer(lTmpBuff^, lBufSize*SizeOf(Word));

 
[...]

Mattias

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Leonardo M . Ramé
On 2013-03-24 19:02:18 +0100, Mattias Gaertner wrote:
 On Sun, 24 Mar 2013 14:51:26 -0300
 Leonardo M. Ramé l.r...@griensu.com wrote:
 
 
 lStream.WriteBuffer(lTmpBuff^, lBufSize*SizeOf(Word));

I've already tried that, but it doesn't work as expected.

Maybe the problem is caused because lBufSize is a longint, instead of
Word or LongWord?.
-- 
Leonardo M. Ramé
http://leonardorame.blogspot.com

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Joao Morais
2013/3/24 Leonardo M. Ramé l.r...@griensu.com:
 Hi, I'm copying a buffer of PWord to a TMemoryStream using this code:

 lTmpBuff := lBuffer;
 I := 0;
 while I  lBufSize do
 begin
   lStream.Write(lTmpBuff^, SizeOf(PWord));
   inc(lTmpBuff, 1);
   inc(I, 1);

What about:

   inc(lTmpBuff, SizeOf(PWord));
   inc(I, SizeOf(PWord));

Joao Morais

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Leonardo M . Ramé
On 2013-03-24 15:19:11 -0300, Joao Morais wrote:
 2013/3/24 Leonardo M. Ramé l.r...@griensu.com:
  Hi, I'm copying a buffer of PWord to a TMemoryStream using this code:
 
  lTmpBuff := lBuffer;
  I := 0;
  while I  lBufSize do
  begin
lStream.Write(lTmpBuff^, SizeOf(PWord));
inc(lTmpBuff, 1);
inc(I, 1);
 
 What about:
 
inc(lTmpBuff, SizeOf(PWord));
inc(I, SizeOf(PWord));
 

I've already tried that, but the only way it works is incrementing by
just 1.

-- 
Leonardo M. Ramé
http://leonardorame.blogspot.com

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Sven Barth

On 24.03.2013 19:19, Joao Morais wrote:

2013/3/24 Leonardo M. Ramé l.r...@griensu.com:

Hi, I'm copying a buffer of PWord to a TMemoryStream using this code:

lTmpBuff := lBuffer;
I := 0;
while I  lBufSize do
begin
   lStream.Write(lTmpBuff^, SizeOf(PWord));
   inc(lTmpBuff, 1);
   inc(I, 1);


What about:

inc(lTmpBuff, SizeOf(PWord));
inc(I, SizeOf(PWord));


If lTmpBuff is declared as PWord then Inc already increases in 
multiplies of SizeOf(PWord).
Regarding lBufSize it will be important to know whether the C code 
returns the size in elements or in byte.


Regards,
Sven


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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Mattias Gaertner
On Sun, 24 Mar 2013 19:21:49 +0100
Sven Barth pascaldra...@googlemail.com wrote:

[...]
  Hi, I'm copying a buffer of PWord to a TMemoryStream using this code:
 inc(lTmpBuff, 1);
 inc(I, 1);
 
  What about:
 
  inc(lTmpBuff, SizeOf(PWord));
  inc(I, SizeOf(PWord));
 
 If lTmpBuff is declared as PWord then Inc already increases in 
 multiplies of SizeOf(PWord).

I guess, you mean multiples of SizeOf(Word).


 Regarding lBufSize it will be important to know whether the C code 
 returns the size in elements or in byte.


Mattias

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Sven Barth

On 24.03.2013 19:24, Mattias Gaertner wrote:

On Sun, 24 Mar 2013 19:21:49 +0100
Sven Barth pascaldra...@googlemail.com wrote:


[...]

Hi, I'm copying a buffer of PWord to a TMemoryStream using this code:
inc(lTmpBuff, 1);
inc(I, 1);


What about:

 inc(lTmpBuff, SizeOf(PWord));
 inc(I, SizeOf(PWord));


If lTmpBuff is declared as PWord then Inc already increases in
multiplies of SizeOf(PWord).


I guess, you mean multiples of SizeOf(Word).


Of course :)

Regards,
Sven

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Leonardo M . Ramé
On 2013-03-24 19:21:49 +0100, Sven Barth wrote:
 On 24.03.2013 19:19, Joao Morais wrote:
 2013/3/24 Leonardo M. Ramé l.r...@griensu.com:
 Hi, I'm copying a buffer of PWord to a TMemoryStream using this code:
 
 lTmpBuff := lBuffer;
 I := 0;
 while I  lBufSize do
 begin
lStream.Write(lTmpBuff^, SizeOf(PWord));
inc(lTmpBuff, 1);
inc(I, 1);
 
 What about:
 
 inc(lTmpBuff, SizeOf(PWord));
 inc(I, SizeOf(PWord));
 
 If lTmpBuff is declared as PWord then Inc already increases in
 multiplies of SizeOf(PWord).
 Regarding lBufSize it will be important to know whether the C code
 returns the size in elements or in byte.
 

Heres the interface of the library:

myfunction(void * buffer, unsigned long bufSize)
{
bufsize = interdata-getcount() * sizeof(uint16);
buffer = new uint16[bufSize];
// interdata is an object containing image data
memcpy((void *)buffer, interdata-getData(), interdata-getCount());
}

So, I'm using this variables:

lTmpBuff: PWord;
lBufSize: longword;
I: Integer;


-- 
Leonardo M. Ramé
http://leonardorame.blogspot.com

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Sven Barth

On 24.03.2013 19:30, Leonardo M. Ramé wrote:

On 2013-03-24 19:21:49 +0100, Sven Barth wrote:

On 24.03.2013 19:19, Joao Morais wrote:

2013/3/24 Leonardo M. Ramé l.r...@griensu.com:

Hi, I'm copying a buffer of PWord to a TMemoryStream using this code:

lTmpBuff := lBuffer;
I := 0;
while I  lBufSize do
begin
   lStream.Write(lTmpBuff^, SizeOf(PWord));
   inc(lTmpBuff, 1);
   inc(I, 1);


What about:

inc(lTmpBuff, SizeOf(PWord));
inc(I, SizeOf(PWord));


If lTmpBuff is declared as PWord then Inc already increases in
multiplies of SizeOf(PWord).
Regarding lBufSize it will be important to know whether the C code
returns the size in elements or in byte.



Heres the interface of the library:

myfunction(void * buffer, unsigned long bufSize)
{
 bufsize = interdata-getcount() * sizeof(uint16);


So bufsize contains the amount of Bytes.


 buffer = new uint16[bufSize];


Ehm... shouldn't this be new uint16[interdata-getcount()]? Because 
currently if your getcount() function returns e.g. 42 you will 
allocate an array containing 84 elements...



 // interdata is an object containing image data
 memcpy((void *)buffer, interdata-getData(), interdata-getCount());
}


So assuming that lBuffer is passed as the buffer argument and lBufSize 
as the bufSize one then your old code is wrong.


It should look like this:

=== code begin ===

I := 0;
while I  lBufSize do begin
  lStream.Write(lTmpBuffer^, SizeOf(Word)); // do you really have 
SizeOf(PWord) there?

  Inc(lTmpBuff); // move pointer by one element
  Inc(I, SizeOf(Word)); // we need to increase I by the element size
end;

=== code end ===

An alternative would be:

=== code begin ===

for I := 0 to lBufSize div SizeOf(Word) do
  lStream.Write(lBuffer[I], SizeOf(Word));

=== code end ===

And to finally write all data at once:

=== code begin ===

lStream.Write(lBuffer^, lBufSize); // as lBufSize is the byte size, this 
is correct without further multiplication


=== code end ===

Now if your C function is written correctly, all three should give you 
the same result.


Regards,
Sven

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


Re: [Lazarus] AdjustClientRect or GetLogicalClientRect: which one to override?

2013-03-24 Thread Mattias Gaertner
On Sun, 24 Mar 2013 12:19:24 +0100
Bart bartjun...@gmail.com wrote:

[...]
 Then the compiler told me (well, it did before, but I didn't notice)
 that I forgot to add the override to AdjustClientRect. I fixed that
 (and got rid of the overridden GetLogicalClientRect), and this also
 works.
 
 So, here's my question: which of these two methods is the right one
 to override in this example? And what is the other method intende for?

The LCL uses the output of GetLogicalClientRect as input for
AdjustClientRect.

AdjustClientRect:
http://wiki.freepascal.org/Autosize_/_Layout#AdjustClientRect

GetLogicalClientRect:
http://wiki.freepascal.org/Autosize_/_Layout#Scrolling

So, you can use either AdjustClientRect or the ChildSizing properties.

Mattias

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Leonardo M . Ramé
On 2013-03-24 19:46:09 +0100, Sven Barth wrote:
 On 24.03.2013 19:30, Leonardo M. Ramé wrote:
 On 2013-03-24 19:21:49 +0100, Sven Barth wrote:
 On 24.03.2013 19:19, Joao Morais wrote:
 2013/3/24 Leonardo M. Ramé l.r...@griensu.com:
 Hi, I'm copying a buffer of PWord to a TMemoryStream using this code:
 
 lTmpBuff := lBuffer;
 I := 0;
 while I  lBufSize do
 begin
lStream.Write(lTmpBuff^, SizeOf(PWord));
inc(lTmpBuff, 1);
inc(I, 1);
 
 What about:
 
 inc(lTmpBuff, SizeOf(PWord));
 inc(I, SizeOf(PWord));
 
 If lTmpBuff is declared as PWord then Inc already increases in
 multiplies of SizeOf(PWord).
 Regarding lBufSize it will be important to know whether the C code
 returns the size in elements or in byte.
 
 
 Heres the interface of the library:
 
 myfunction(void * buffer, unsigned long bufSize)
 {
  bufsize = interdata-getcount() * sizeof(uint16);
 
 So bufsize contains the amount of Bytes.
 
  buffer = new uint16[bufSize];
 
 Ehm... shouldn't this be new uint16[interdata-getcount()]?
 Because currently if your getcount() function returns e.g. 42 you
 will allocate an array containing 84 elements...
 
  // interdata is an object containing image data
  memcpy((void *)buffer, interdata-getData(), interdata-getCount());
 }
 
 So assuming that lBuffer is passed as the buffer argument and
 lBufSize as the bufSize one then your old code is wrong.
 
 It should look like this:
 
 === code begin ===
 
 I := 0;
 while I  lBufSize do begin
   lStream.Write(lTmpBuffer^, SizeOf(Word)); // do you really have
 SizeOf(PWord) there?
   Inc(lTmpBuff); // move pointer by one element
   Inc(I, SizeOf(Word)); // we need to increase I by the element size
 end;
 
 === code end ===
 
 An alternative would be:
 
 === code begin ===
 
 for I := 0 to lBufSize div SizeOf(Word) do
   lStream.Write(lBuffer[I], SizeOf(Word));
 
 === code end ===
 
 And to finally write all data at once:
 
 === code begin ===
 
 lStream.Write(lBuffer^, lBufSize); // as lBufSize is the byte size,
 this is correct without further multiplication
 
 === code end ===
 
 Now if your C function is written correctly, all three should give
 you the same result.
 

Thanks Sven, I modified the C function as this:

bufSize = interdata-getCount(); // - returns number of pixels
buffer = new Uint16[bufSize];
memcpy((void *)buffer, interdata-getData(), interdata-getCount());

Here's the getCount() documentation:
http://support.dcmtk.org/docs/classDiPixel.html#15bbe5e57b15ea67bbc9541752ce

Hence, my confusion is because I thought getCount was number of bytes,
but it is number of pixels :)

After changing the C function, now I can do this:

lStream.Write(lTmpBuff^, SizeOf(PWord));
inc(lTmpBuff);
inc(I, 2); // it also works with inc(I, 1) but not using inc(I,
sizeof(Word));

-- 
Leonardo M. Ramé
http://leonardorame.blogspot.com

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Sven Barth

On 24.03.2013 19:57, Leonardo M. Ramé wrote:

On 2013-03-24 19:46:09 +0100, Sven Barth wrote:

On 24.03.2013 19:30, Leonardo M. Ramé wrote:

On 2013-03-24 19:21:49 +0100, Sven Barth wrote:

On 24.03.2013 19:19, Joao Morais wrote:

2013/3/24 Leonardo M. Ramé l.r...@griensu.com:

Hi, I'm copying a buffer of PWord to a TMemoryStream using this code:

lTmpBuff := lBuffer;
I := 0;
while I  lBufSize do
begin
   lStream.Write(lTmpBuff^, SizeOf(PWord));
   inc(lTmpBuff, 1);
   inc(I, 1);


What about:

inc(lTmpBuff, SizeOf(PWord));
inc(I, SizeOf(PWord));


If lTmpBuff is declared as PWord then Inc already increases in
multiplies of SizeOf(PWord).
Regarding lBufSize it will be important to know whether the C code
returns the size in elements or in byte.



Heres the interface of the library:

[snip]

Now if your C function is written correctly, all three should give
you the same result.



Thanks Sven, I modified the C function as this:

bufSize = interdata-getCount(); // - returns number of pixels
buffer = new Uint16[bufSize];
memcpy((void *)buffer, interdata-getData(), interdata-getCount());

Here's the getCount() documentation:
http://support.dcmtk.org/docs/classDiPixel.html#15bbe5e57b15ea67bbc9541752ce

Hence, my confusion is because I thought getCount was number of bytes,
but it is number of pixels :)

After changing the C function, now I can do this:

lStream.Write(lTmpBuff^, SizeOf(PWord));
inc(lTmpBuff);
inc(I, 2); // it also works with inc(I, 1) but not using inc(I,
sizeof(Word));



Now your lBufSize contains the number of pixels, so only Inc(I, 1) 
should be correct. And for copying all data at once you now need to use 
lBufSize * SizeOf(Word) instead. And the for-loop variant would look 
like this:


=== code begin ===

for i := 0 to lBufSize - 1 do
  lStream.Write(lBuffer[i], SizeOf(Word));
  // or
  lStream.WriteWord(lBuffer[i]);

=== code end ===

Regards,
Sven

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


Re: [Lazarus] How to send Email from Lazarus program under Linux x86-64

2013-03-24 Thread Paul Breneman

silvioprog wrote:

2013/3/24 reinierolislag...@gmail.com


On 24-3-2013 15:19, Donald Ziesig wrote:

Hi All!

I am trying to implement a program that will send emails to (a subset
of) an application-specific roster.

I found numerous references to synapse so I downloaded the source which
includes a .lpk library (it is several years old).

Yep, seems about 3 years old:
cd C:\Development\extras\synapse
svn log laz_synapse.lpk | more
r129 | geby | 2010-07-02 12:46:39 +0200 (vr, 02 jul 2010) | 3 lines

- improved MACOS compatibility
- workaround for some broken virtual serial ports
- Added Lazarus package


Has anyone had success in using this library under Linux (x86-64)?

Yes. See e.g. fpctwit, which happily runs under Linux. Also, the fpcup
Lazarus/fpc updater can install synapse for you, also the synapse trunk
version.

AFAIK no need to change any synapse files.

Please see the wiki page on synapse:
http://wiki.lazarus.freepascal.org/synapse


I also examined Indy (which I used successfully years ago on
Delphi/Borland c++ Builder) but it, too, is obsolete (latest updates
seem to be circa 2006) and comes with many, many warnings and caveats.

Please see the indy wiki page:
... ah well, you'll be able to find it. It's cross referenced in the
synapse page as well IIRC.


Is there any other smtp and pop3 code available for Lazarus or will I
have to generate my own from scratch?

There certainly is. IIRC, LazSolutions has code for sending email.
Synapse comes with an email example, or has it in the examples directory
on their site.
Code for sending email using synapse is floating around on e.g. the
synapse mailing list...

Good luck,
Reinier



Thanks for the indication Reinier! :)

Meet the XMailer also:

https://github.com/silvioprog/xmailer

XMailer is a nice plugin for send e-mails easily. It's improved derivation
of LSSendMail. :) (it use Synapse too, and offers support to UTF-8)


Thanks Silvio.  Now I need to try and update this code:
  http://www.turbocontrol.com/easyemail.htm

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Sven Barth

On 24.03.2013 20:14, Leonardo M. Ramé wrote:

On 2013-03-24 20:02:38 +0100, Sven Barth wrote:

On 24.03.2013 19:57, Leonardo M. Ramé wrote:

On 2013-03-24 19:46:09 +0100, Sven Barth wrote:

On 24.03.2013 19:30, Leonardo M. Ramé wrote:

On 2013-03-24 19:21:49 +0100, Sven Barth wrote:

On 24.03.2013 19:19, Joao Morais wrote:

2013/3/24 Leonardo M. Ramé l.r...@griensu.com:

Hi, I'm copying a buffer of PWord to a TMemoryStream using this code:

lTmpBuff := lBuffer;
I := 0;
while I  lBufSize do
begin
   lStream.Write(lTmpBuff^, SizeOf(PWord));
   inc(lTmpBuff, 1);
   inc(I, 1);


What about:

inc(lTmpBuff, SizeOf(PWord));
inc(I, SizeOf(PWord));


If lTmpBuff is declared as PWord then Inc already increases in
multiplies of SizeOf(PWord).
Regarding lBufSize it will be important to know whether the C code
returns the size in elements or in byte.



Heres the interface of the library:

[snip]

Now if your C function is written correctly, all three should give
you the same result.



Thanks Sven, I modified the C function as this:

bufSize = interdata-getCount(); // - returns number of pixels
buffer = new Uint16[bufSize];
memcpy((void *)buffer, interdata-getData(), interdata-getCount());

Here's the getCount() documentation:
http://support.dcmtk.org/docs/classDiPixel.html#15bbe5e57b15ea67bbc9541752ce

Hence, my confusion is because I thought getCount was number of bytes,
but it is number of pixels :)

After changing the C function, now I can do this:

lStream.Write(lTmpBuff^, SizeOf(PWord));
inc(lTmpBuff);
inc(I, 2); // it also works with inc(I, 1) but not using inc(I,
sizeof(Word));



Now your lBufSize contains the number of pixels, so only Inc(I, 1)
should be correct. And for copying all data at once you now need to
use lBufSize * SizeOf(Word) instead. And the for-loop variant
would look like this:

=== code begin ===

for i := 0 to lBufSize - 1 do
   lStream.Write(lBuffer[i], SizeOf(Word));
   // or
   lStream.WriteWord(lBuffer[i]);

=== code end ===



Yes, the code looks correct, but it still creates the wrong resulting
image.

If you look at the attachment, the upper image is the result of your
last suggestion, while the lower image was created using the while loop
I've shown.

I'll re-check my drawing function, maybe your code is correct and the
problem is on that function.


I just noticed that you are still using SizeOf(PWord) in your 
lStream.Write. This is wrong. You want to copy one Word element 
(SizeOf(Word)=2) instead of two/four (depending on 32 vs 64 bit 
SizeOf(PWord) is either 4 or 8). Which is also why your Inc(..., 2) 
works as you are copying multiple entries at once.


Regards,
Sven

Regards,
Sven

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Leonardo M . Ramé
On 2013-03-24 20:29:44 +0100, Sven Barth wrote:
 On 24.03.2013 20:14, Leonardo M. Ramé wrote:
 On 2013-03-24 20:02:38 +0100, Sven Barth wrote:
 On 24.03.2013 19:57, Leonardo M. Ramé wrote:
 On 2013-03-24 19:46:09 +0100, Sven Barth wrote:
 On 24.03.2013 19:30, Leonardo M. Ramé wrote:
 On 2013-03-24 19:21:49 +0100, Sven Barth wrote:
 On 24.03.2013 19:19, Joao Morais wrote:
 2013/3/24 Leonardo M. Ramé l.r...@griensu.com:
 Hi, I'm copying a buffer of PWord to a TMemoryStream using this code:
 
 lTmpBuff := lBuffer;
 I := 0;
 while I  lBufSize do
 begin
lStream.Write(lTmpBuff^, SizeOf(PWord));
inc(lTmpBuff, 1);
inc(I, 1);
 
 What about:
 
 inc(lTmpBuff, SizeOf(PWord));
 inc(I, SizeOf(PWord));
 
 If lTmpBuff is declared as PWord then Inc already increases in
 multiplies of SizeOf(PWord).
 Regarding lBufSize it will be important to know whether the C code
 returns the size in elements or in byte.
 
 
 Heres the interface of the library:
 [snip]
 Now if your C function is written correctly, all three should give
 you the same result.
 
 
 Thanks Sven, I modified the C function as this:
 
 bufSize = interdata-getCount(); // - returns number of pixels
 buffer = new Uint16[bufSize];
 memcpy((void *)buffer, interdata-getData(), interdata-getCount());
 
 Here's the getCount() documentation:
 http://support.dcmtk.org/docs/classDiPixel.html#15bbe5e57b15ea67bbc9541752ce
 
 Hence, my confusion is because I thought getCount was number of bytes,
 but it is number of pixels :)
 
 After changing the C function, now I can do this:
 
 lStream.Write(lTmpBuff^, SizeOf(PWord));
 inc(lTmpBuff);
 inc(I, 2); // it also works with inc(I, 1) but not using inc(I,
 sizeof(Word));
 
 
 Now your lBufSize contains the number of pixels, so only Inc(I, 1)
 should be correct. And for copying all data at once you now need to
 use lBufSize * SizeOf(Word) instead. And the for-loop variant
 would look like this:
 
 === code begin ===
 
 for i := 0 to lBufSize - 1 do
lStream.Write(lBuffer[i], SizeOf(Word));
// or
lStream.WriteWord(lBuffer[i]);
 
 === code end ===
 
 
 Yes, the code looks correct, but it still creates the wrong resulting
 image.
 
 If you look at the attachment, the upper image is the result of your
 last suggestion, while the lower image was created using the while loop
 I've shown.
 
 I'll re-check my drawing function, maybe your code is correct and the
 problem is on that function.
 
 I just noticed that you are still using SizeOf(PWord) in your
 lStream.Write. This is wrong. You want to copy one Word element
 (SizeOf(Word)=2) instead of two/four (depending on 32 vs 64 bit
 SizeOf(PWord) is either 4 or 8). Which is also why your Inc(..., 2)
 works as you are copying multiple entries at once.
 

Well, this is funny, after re-checking the code, I noted it works if I
use this:

(1)   for I := 0 to lBufSize - 1 do
lUnCompressed.Write(lTmpBuff[i], SizeOf(PWord));

But, using SizeOf(Word) doesn't:

(2)   for I := 0 to lBufSize - 1 do
lUnCompressed.Write(lTmpBuff[i], SizeOf(Word));

What I would like to achieve is this:

(3)   lUnCompressed.WriteBuffer(lTmpBuff^, lBufSize * SizeOf(Word)); 
  
But using this, I get the same result of (2).

-- 
Leonardo M. Ramé
http://leonardorame.blogspot.com

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Sven Barth

On 24.03.2013 20:39, Leonardo M. Ramé wrote:

Now your lBufSize contains the number of pixels, so only Inc(I, 1)
should be correct. And for copying all data at once you now need to
use lBufSize * SizeOf(Word) instead. And the for-loop variant
would look like this:

=== code begin ===

for i := 0 to lBufSize - 1 do
   lStream.Write(lBuffer[i], SizeOf(Word));
   // or
   lStream.WriteWord(lBuffer[i]);

=== code end ===



Yes, the code looks correct, but it still creates the wrong resulting
image.

If you look at the attachment, the upper image is the result of your
last suggestion, while the lower image was created using the while loop
I've shown.

I'll re-check my drawing function, maybe your code is correct and the
problem is on that function.


I just noticed that you are still using SizeOf(PWord) in your
lStream.Write. This is wrong. You want to copy one Word element
(SizeOf(Word)=2) instead of two/four (depending on 32 vs 64 bit
SizeOf(PWord) is either 4 or 8). Which is also why your Inc(..., 2)
works as you are copying multiple entries at once.



Well, this is funny, after re-checking the code, I noted it works if I
use this:

(1)   for I := 0 to lBufSize - 1 do
 lUnCompressed.Write(lTmpBuff[i], SizeOf(PWord));

But, using SizeOf(Word) doesn't:

(2)   for I := 0 to lBufSize - 1 do
 lUnCompressed.Write(lTmpBuff[i], SizeOf(Word));

What I would like to achieve is this:

(3)   lUnCompressed.WriteBuffer(lTmpBuff^, lBufSize * SizeOf(Word));

But using this, I get the same result of (2).



Maybe your problem is indeed in your drawing function. Because the usage 
of SizeOf(PWord) is definitely wrong if your lBuffer basically contains 
Word sized pixels after each other. You should currently even get 
different results depending on whether the application is 32 or 64 bit.


Regards,
Sven

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


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Leonardo M . Ramé
On 2013-03-24 20:44:50 +0100, Sven Barth wrote:
 On 24.03.2013 20:39, Leonardo M. Ramé wrote:
 Now your lBufSize contains the number of pixels, so only Inc(I, 1)
 should be correct. And for copying all data at once you now need to
 use lBufSize * SizeOf(Word) instead. And the for-loop variant
 would look like this:
 
 === code begin ===
 
 for i := 0 to lBufSize - 1 do
lStream.Write(lBuffer[i], SizeOf(Word));
// or
lStream.WriteWord(lBuffer[i]);
 
 === code end ===
 
 
 Yes, the code looks correct, but it still creates the wrong resulting
 image.
 
 If you look at the attachment, the upper image is the result of your
 last suggestion, while the lower image was created using the while loop
 I've shown.
 
 I'll re-check my drawing function, maybe your code is correct and the
 problem is on that function.
 
 I just noticed that you are still using SizeOf(PWord) in your
 lStream.Write. This is wrong. You want to copy one Word element
 (SizeOf(Word)=2) instead of two/four (depending on 32 vs 64 bit
 SizeOf(PWord) is either 4 or 8). Which is also why your Inc(..., 2)
 works as you are copying multiple entries at once.
 
 
 Well, this is funny, after re-checking the code, I noted it works if I
 use this:
 
 (1)   for I := 0 to lBufSize - 1 do
  lUnCompressed.Write(lTmpBuff[i], SizeOf(PWord));
 
 But, using SizeOf(Word) doesn't:
 
 (2)   for I := 0 to lBufSize - 1 do
  lUnCompressed.Write(lTmpBuff[i], SizeOf(Word));
 
 What I would like to achieve is this:
 
 (3)   lUnCompressed.WriteBuffer(lTmpBuff^, lBufSize * SizeOf(Word));
 
 But using this, I get the same result of (2).
 
 
 Maybe your problem is indeed in your drawing function. Because the
 usage of SizeOf(PWord) is definitely wrong if your lBuffer basically
 contains Word sized pixels after each other. You should currently
 even get different results depending on whether the application is
 32 or 64 bit.
 
 Regards,
 Sven
 

Sven, I can confirm the image display function was wrong. Now I can
write all data to the stream at once!.

-- 
Leonardo M. Ramé
http://leonardorame.blogspot.com

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


Re: [Lazarus] How to send Email from Lazarus program under Linux x86-64

2013-03-24 Thread silvioprog
2013/3/24 Paul Breneman list2...@brenemanlabs.com

 silvioprog wrote:

 2013/3/24 reinierolislag...@gmail.com

  On 24-3-2013 15:19, Donald Ziesig wrote:

 Hi All!

 I am trying to implement a program that will send emails to (a subset
 of) an application-specific roster.

 I found numerous references to synapse so I downloaded the source which
 includes a .lpk library (it is several years old).

 Yep, seems about 3 years old:
 cd C:\Development\extras\synapse
 svn log laz_synapse.lpk | more
 r129 | geby | 2010-07-02 12:46:39 +0200 (vr, 02 jul 2010) | 3 lines

 - improved MACOS compatibility
 - workaround for some broken virtual serial ports
 - Added Lazarus package

  Has anyone had success in using this library under Linux (x86-64)?

 Yes. See e.g. fpctwit, which happily runs under Linux. Also, the fpcup
 Lazarus/fpc updater can install synapse for you, also the synapse trunk
 version.

 AFAIK no need to change any synapse files.

 Please see the wiki page on synapse:
 http://wiki.lazarus.**freepascal.org/synapsehttp://wiki.lazarus.freepascal.org/synapse

  I also examined Indy (which I used successfully years ago on
 Delphi/Borland c++ Builder) but it, too, is obsolete (latest updates
 seem to be circa 2006) and comes with many, many warnings and caveats.

 Please see the indy wiki page:
 ... ah well, you'll be able to find it. It's cross referenced in the
 synapse page as well IIRC.

  Is there any other smtp and pop3 code available for Lazarus or will I
 have to generate my own from scratch?

 There certainly is. IIRC, LazSolutions has code for sending email.
 Synapse comes with an email example, or has it in the examples directory
 on their site.
 Code for sending email using synapse is floating around on e.g. the
 synapse mailing list...

 Good luck,
 Reinier



 Thanks for the indication Reinier! :)

 Meet the XMailer also:

 https://github.com/silvioprog/**xmailerhttps://github.com/silvioprog/xmailer

 XMailer is a nice plugin for send e-mails easily. It's improved derivation
 of LSSendMail. :) (it use Synapse too, and offers support to UTF-8)


 Thanks Silvio.  Now I need to try and update this code:
   
 http://www.turbocontrol.com/**easyemail.htmhttp://www.turbocontrol.com/easyemail.htm


Very nice! :)

XMailer is very simple, and it uses universal unicode. Sending email with
XMailer you can open it in any account such as Gmail, Yahoo, Hotmail etc.,
even if the email has special characters.

-- 
Silvio Clécio
My public projects - github.com/silvioprog
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus


Re: [Lazarus] Copy buffer of PWord to TMemoryStream

2013-03-24 Thread Sven Barth

On 24.03.2013 21:09, Leonardo M. Ramé wrote:

On 2013-03-24 20:44:50 +0100, Sven Barth wrote:

On 24.03.2013 20:39, Leonardo M. Ramé wrote:

Now your lBufSize contains the number of pixels, so only Inc(I, 1)
should be correct. And for copying all data at once you now need to
use lBufSize * SizeOf(Word) instead. And the for-loop variant
would look like this:

=== code begin ===

for i := 0 to lBufSize - 1 do
   lStream.Write(lBuffer[i], SizeOf(Word));
   // or
   lStream.WriteWord(lBuffer[i]);

=== code end ===



Yes, the code looks correct, but it still creates the wrong resulting
image.

If you look at the attachment, the upper image is the result of your
last suggestion, while the lower image was created using the while loop
I've shown.

I'll re-check my drawing function, maybe your code is correct and the
problem is on that function.


I just noticed that you are still using SizeOf(PWord) in your
lStream.Write. This is wrong. You want to copy one Word element
(SizeOf(Word)=2) instead of two/four (depending on 32 vs 64 bit
SizeOf(PWord) is either 4 or 8). Which is also why your Inc(..., 2)
works as you are copying multiple entries at once.



Well, this is funny, after re-checking the code, I noted it works if I
use this:

(1)   for I := 0 to lBufSize - 1 do
 lUnCompressed.Write(lTmpBuff[i], SizeOf(PWord));

But, using SizeOf(Word) doesn't:

(2)   for I := 0 to lBufSize - 1 do
 lUnCompressed.Write(lTmpBuff[i], SizeOf(Word));

What I would like to achieve is this:

(3)   lUnCompressed.WriteBuffer(lTmpBuff^, lBufSize * SizeOf(Word));

But using this, I get the same result of (2).



Maybe your problem is indeed in your drawing function. Because the
usage of SizeOf(PWord) is definitely wrong if your lBuffer basically
contains Word sized pixels after each other. You should currently
even get different results depending on whether the application is
32 or 64 bit.

Regards,
Sven



Sven, I can confirm the image display function was wrong. Now I can
write all data to the stream at once!.



Nice to hear that you found the final problem as well :)

Regards,
Sven

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


Re: [Lazarus] IUnknown and reference counting

2013-03-24 Thread Graeme Geldenhuys
On 2013-03-21 17:46, Hans-Peter Diettrich wrote:
 
 Thanks for giving me insight into the crippled implementation of 
 interfaces in FPC :-]

Sorry, but you seem very confused. The default Interfaces style used
by FPC is the COM-style interfaces. 100% compatible with Delphi. So I
really do not see your problem.


 IUnknown  IInterface- Exactly the same as Delphi
 TInterfacedObject- Exactly the same as Delphi

To use CORBA-style interfaces, you need to explicitly tell the compiled
to do so, via the {$interfaces corba} directive.

I use plenty of projects that use Interfaces, and that code is shared
verbatim between Delphi and FPC. Just take a look at the tiOPF project.



Regards,
  - Graeme -

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


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


Re: [Lazarus] IUnknown and reference counting

2013-03-24 Thread Graeme Geldenhuys
On 2013-03-21 20:48, Hans-Peter Diettrich wrote:
 Sven Barth schrieb:
 On 21.03.2013 21:14, Hans-Peter Diettrich wrote:
 Sven Barth schrieb:

   Thanks for giving me insight into the crippled implementation of
 interfaces in FPC :-]

 Why crippled?

 When FPC does not allow to use delegation (implements) together with
 implementing selected methods, this feature is of no practical use :-(

 There exists at least a bug report about it: 
 http://bugs.freepascal.org/view.php?id=16531 :)
 
 +1
 
 Also the hype about CORBA interfaces looks like mere eye-candy or
 obfuscation to me. Delphi interfaces require neither COM nor CORBA, they
 are only open in either direction.

 But some people don't like the reference counting. They want to use 
 interfaces like in other languages to just define a interface to a class.
 
 Since reference counting must be implemented,

Why *must* reference counting be implemented when you want to use
Interfaces? Many other languages also have interfaces with no reference
counting.

The CORBA-style interfaces that FPC support also make descendant classes
easier to extend. For example

  // this class is supplied by a 3rd party company.
  TMyClass = class(TObject)
...
  end;


Now I want to add some functionality to a descendant class in my
project, and use interfaces to do it [for whatever reason I see fit]. No
problem.

  TMySuperClass = class(TMyClass, IObserver)
  private
// implement IObserver methods here
  end;


All done!

If reference counting interfaces was the only option, I would be forced
to implement IUnknown in the TMySuperClass class for what? TMyClass
is not a TInterfacedObject descendant, and the 3rd party vendor never
had a need for interfaces, so they used the very common TObject base
class. I don't need reference counting just to have interfaces support -
so based on what you say, reference counting must be forced upon me! And
I must do more work in my class by adding IUnknown to the TMySuperClass too.


Regards,
  - Graeme -

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


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