Re: [Lazarus] Log4D weirdness

[Marcos Douglas]

On Wed, Dec 31, 2014 at 6:56 PM, Marco van de Voort  wrote:
> On Sun, Dec 28, 2014 at 07:51:25PM -0200, Marcos Douglas wrote:
>> > Delphi. As a first try I remove the "const", in case of unexpected trouble.
>>
>> Delphi and FPC have problems with refcounting -- but I'm referring
>> only interfaces.
>> Circular references is a big problem too.
>
> This is totally new for me. I have used interfaces a lot, and while I had
> trouble from time to time, I haven't really encountered these.

New? What do you mean?
This problem was talked in FPC list and here before.
I use "weak reference". Somethings are not possible to implement
without this "technique".
For example:
https://github.com/mdbs99/AWS/blob/master/src/aws_s3.pas#L166
https://github.com/mdbs99/AWS/blob/master/src/aws_s3.pas#L304

These objects have circular reference and they need weak reference to
keep memory safe.

>> This link could help:
>> http://blog.synopse.info/post/2012/06/18/Circular-reference-and-zeroing-weak-pointers
>
> IMHO wrong. GC also has problems, e.g. when two roots circularly reference
> eachother. The major implementations are somewhat hardened against it, but
> more involved reference counting implementations (like Python) are too.

I know some others approaches have problems, but Delphi/FPC is not perfect too.

> Delphi/FPC reference counting is simple and cheap. The problem is IMHO not
> the implementation, but the fact that people try to abuse it for things it
> wasn't meant for (a holistic automatic memory management solution).

I agree.

> ARC is IMHO no solution but only damage control (by explicitely naming pure
> references). IIRC Python has similar tricks to keep circular detections
> cheap (cycle checking can stop at a weak reference)

Happy New year!

Regards,
Marcos Douglas

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

Re: [Lazarus] Question {%MainUnit} IDE directive

[Mattias Gaertner]

On Wed, 31 Dec 2014 17:50:40 +0200
Juha Manninen  wrote:

>[...]
> > I looked here: http://wiki.freepascal.org/IDE_directives, this directive is 
> > not mentioned there.
> 
> Right, the page should be updated. The directive is valid only in .inc
> files which must be mentioned.

Done.

Mattias

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

Re: [Lazarus] Indy 10

[A. Fortuny]

Le 29/12/2014 11:26, Juha Manninen a écrit :

What is the recommended link to download Indy 10 for lazarus?
The wiki :
   http://wiki.freepascal.org/Indy_with_Lazarus#Downloads_.2F_Links
tells to use Indy 10 website :
   http://www.indyproject.org/index.en.aspx

This link works and the zip file looks ok.
link 

Antonio.

BTW, happy new year 2015 to all of you


which is messy.

Juha

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




---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
http://www.avast.com



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

Re: [Lazarus] Indy 10

[Marco van de Voort]

On Mon, Dec 29, 2014 at 12:26:37PM +0200, Juha Manninen wrote:
> What is the recommended link to download Indy 10 for lazarus?
> The wiki :
>   http://wiki.freepascal.org/Indy_with_Lazarus#Downloads_.2F_Links
> tells to use Indy 10 website :
>   http://www.indyproject.org/index.en.aspx
> which is messy.

Afaik indy recommnds to use fulgan (FTP) snapshots, the releases are too old.

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

Re: [Lazarus] Log4D weirdness

[Marco van de Voort]

On Sun, Dec 28, 2014 at 07:51:25PM -0200, Marcos Douglas wrote:
> > Delphi. As a first try I remove the "const", in case of unexpected trouble.
> 
> Delphi and FPC have problems with refcounting -- but I'm referring
> only interfaces.
> Circular references is a big problem too.

This is totally new for me. I have used interfaces a lot, and while I had
trouble from time to time, I haven't really encountered these.
 
> This link could help:
> http://blog.synopse.info/post/2012/06/18/Circular-reference-and-zeroing-weak-pointers

IMHO wrong. GC also has problems, e.g. when two roots circularly reference
eachother. The major implementations are somewhat hardened against it, but
more involved reference counting implementations (like Python) are too.

Delphi/FPC reference counting is simple and cheap. The problem is IMHO not
the implementation, but the fact that people try to abuse it for things it
wasn't meant for (a holistic automatic memory management solution).

ARC is IMHO no solution but only damage control (by explicitely naming pure
references). IIRC Python has similar tricks to keep circular detections
cheap (cycle checking can stop at a weak reference)



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

Re: [Lazarus] Log4D weirdness

[Marco van de Voort]

On Sun, Dec 28, 2014 at 04:03:07AM +0100, Hans-Peter Diettrich wrote:
> > Like many cases, Delphi does not specify this behaviour, and in general for
> > Delphi not much is known what of the implementation is intended, or what is
> > coincidence.  This is aggrevated by the fact that too much Delphi code
> > messing with interface refcounting seems to be created with trial and error.
> Also strings had (have?) problems with refcounting of *const* parameters 
> in Delphi. As a first try I remove the "const", in case of unexpected 
> trouble.

Afaik the problem is that "const" as used in classic delphi is not very
portable. In theory it is specified as immutable (can't be modified), but
widely abused to mean "by reference". This happens to be the case for x86
ABIs, but this is not portable (which why FPC introduced constref)

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

Re: [Lazarus] TListView - column alignment doesn't work when OwnerData

[Krzysztof]

Forgot write details:

Lazarus 1.2.6
FPC 2.6.4
Kubuntu 14.04 64 bit (Qt widgetset)
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

[Lazarus] TListView - column alignment doesn't work when OwnerData

[Krzysztof]

Hi,

I have column alignment taRightJustify. When using as "normal" listview
then everything is ok but with OwnerData, data is always taLeftJustify (but
column title is ok). Is it a bug or need I set some extra property?

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

Re: [Lazarus] Deleting a control in its OnClick event can cause a SIGSEV?

[Luca Olivetti]

El 31/12/14 a les 19:26, Bart ha escrit:
> On 12/31/14, Luca Olivetti  wrote:
> 
>> It turns out that in the OnClick event I was calling a method that freed
>> the control that generated the OnClick, so I supposed that was the cause
>> of the sigsev.
> 
> Probably you are right.
> Been there, done that.

OK, thank you

> 
>> Now I use Application.QueueAsyncCall to fire the method after the event
> 
> You can use Application.ReleaseComponent()
> (Was offered as a solution to me when I had the same problem)

Well, I'm doing a lot of other things in the method, so QueueAsyncCall
is more fitting.

> 
>> Is it possible that destroying the control was the cause of the SIGSEV?
> 
> Yes

Phew, I'm relieved. You know, the system is going to go live next week.
I simulated around six months worth of operating cycles in a virtual
machine, but this problem appeared in the real hardware with a
configuration form (which isn't going to be used much but still has to
work) that never gave problems during previous testing.


Bye, and happy new year!
-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es
Tel. +34 935883004  Fax +34 935883007

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

Re: [Lazarus] Deleting a control in its OnClick event can cause a SIGSEV?

[Bart]

On 12/31/14, Luca Olivetti  wrote:

> It turns out that in the OnClick event I was calling a method that freed
> the control that generated the OnClick, so I supposed that was the cause
> of the sigsev.

Probably you are right.
Been there, done that.

> Now I use Application.QueueAsyncCall to fire the method after the event

You can use Application.ReleaseComponent()
(Was offered as a solution to me when I had the same problem)

> Is it possible that destroying the control was the cause of the SIGSEV?

Yes

Bart

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

Re: [Lazarus] Typecast set to byte in mode OBJFPC

[Jürgen Hestermann]

Am 2014-12-31 um 18:42 schrieb Jürgen Hestermann:


Am 2014-12-31 um 17:46 schrieb Luca Olivetti:

El 31/12/14 a les 17:33, Jürgen Hestermann ha escrit:


Is this realy compiler mode dependent?
I can't find any documentation about this.

Sorry, I meant that FlagSETType seems to be 4 bytes now.

http://www.freepascal.org/docs-html/prog/progsu59.html#x66-650001.2.59



Is this valid for set types too?
I think this is what I was looking for:
http://www.freepascal.org/docs-html/prog/progsu61.html


It seems that I had to use both directives:

{$PackSet 1}
{$PackEnum 1}

because in OBJFPC mode enum *and* set sizes
are both different to DELPHI mode.
Any other sizes that may have changed?
Is there a list of differences for all modes?


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

[Lazarus] fpspreadsheet 1.4 released

[Werner Pamler]

I am glad to announce that a new version of fpspreadsheet, version 1.4, 
has been uploaded to 
https://sourceforge.net/projects/lazarus-ccr/files/FPSpreadsheet/. Here 
is a list of the main additions of the new release:


 * Full support for *string formulas* (reading, writing, calculating).
   Registration mechanism which allows to extend the built-in formulas
   by user-defined ones. Calculation occurs when a workbook is saved
   (activate workbook option boCalcBeforeSaving) or when cell content
   changes (workbook option boAutoCalc).
 * *Shared formulas* (reading for sfExcel5, sfExcel8, sfOOXML; writing
   for sfExcel2, sfExcel5, sfExcel8).
 * Significant *speed-up* of writing of large spreadsheets for the
   xml-based formats (ods and xlsx), speed up for biff2; *speedtest
   demo* program
 * *VirtualMode* allowing to read and write very large spreadsheet
   files without having the entire document in memory. Formatting of
   cells in VirtualMode.
 * db export unit allowing programmatic exporting datasets using
   *TFPSExport*. Similar export units are e.g. fpdbfexport
   , fpXMLXSDExport
   .
 * Demo program for database export using virtual mode and TFPSExport.
 * Reader for *xlsx* files, now fully supporting the same features as
   the other readers.
 * Reader/writer for *CSV files* based on CsvDocument
   .
 * *Wikitables writer* supports now most of the fpspreadsheet
   formatting options (background color, font style, font color, text
   alignment, cell borders/line styles/line colors, merged cells,
   column widths, row heights); new "wikitablemaker" demo
 * *Insertion and deletion of rows and columns* into a worksheet
   containing data.
 * Implementation of *sorting* of a worksheet.
 * Support of *diagonal "border" lines*
 * *Logging of non-fatal error messages* during reading/writing
   (TsWorksheet.ErrorMsg)
 * *Merged* cells
 * *Registration* of currency strings for automatic conversion of
   strings to *currency values*
 * A set of *visual controls* (TsWorkbookSource, TsWorkbookTabControl,
   TsSpreadsheetInspector, TsCellEdit, TsCellIndicator, TsCellCombobox,
   in addition to the already-existing TsWorksheetGrid) and pre-defined
   standard actions to facilitate creation of GUI applications
   
.

 * *Overflow cells* in TsWorksheetGrid: label cells with text longer
   than the cell width extend into the neighboring cell(s).

See the wiki page  for 
documentation of the package, or the chm help file in the installation 
folder. If you need fpspreadsheet in gui applications you may also want 
to have a look at the tutorial 
.


This release is devoted to the late Reinier Olislagers ("bigchimp", 
http://forum.lazarus.freepascal.org/index.php/topic,26726), one of the 
former maintainers of the package.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Alternative component palette layout

[Sandro Cumerlato]

Hello Juha,
I've implemented (auto) resize of Components list columns.

Please review attached patch and apply if OK.

Sandro


On 28 December 2014 at 21:11, Juha Manninen 
wrote:

> On Sun, Dec 28, 2014 at 1:08 PM, zeljko  wrote:
> > I'm against such workarounds since it can hide bug. Is it enough to
> comment
> > code LCLQt to completely disable LCLQt ifdef ?
> > I'll try to debug and see what exactly happens, since it's impossible to
> > reproduce it with simple example project.
>
> I already thought I spotted the error and I almost opened a bug
> report. Unneeded pages are deleted like :
>   Application.ReleaseComponent(Sheet);
> I could reproduce the error in a small test project and then fix it using :
>   TabControl := TCustomTabControl(PageControl1);
>   TabControl.Pages.Delete(0);
> But ... I tried to use it in the component palette code and it didn't
> work. I am puzzled and will not touch this issue for a while.
>
> TPageControl API sucks badly.
> TPageControl inherits from TCustomTabControl. They both have "Pages"
> but with different meaning. There is Pages[] and Page[].
> I think it should be fixed even if it breaks Delphi compatibility.
>
> Anyway, the palette reordering works pretty much perfectly now!
> Giuliano made a workaround for the QT issue and I fixed a last
> remaining bug related to saving the configuration.
> Please everybody test and create alternative palette layouts.
>
> Juha
>
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus.freepascal.org
> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>
Index: ide/frames/componentpalette_options.lfm
===
--- ide/frames/componentpalette_options.lfm (revisione 47273)
+++ ide/frames/componentpalette_options.lfm (copia locale)
@@ -216,17 +216,17 @@
 end  
 item
   Caption = 'Name'
-  MaxWidth = 300
   MinWidth = 50
   Width = 145
 end  
 item
   Caption = 'Page'
-  MaxWidth = 1000
+  MinWidth = 50
   Width = 201
 end  
 item
-  Caption = 'Package'
+  Caption = 'Unit'
+  MinWidth = 50
   Width = 301
 end>
   DragMode = dmAutomatic
Index: ide/frames/componentpalette_options.pas
===
--- ide/frames/componentpalette_options.pas (revisione 47273)
+++ ide/frames/componentpalette_options.pas (copia locale)
@@ -313,9 +313,18 @@
   PageCnt, CompCnt: Integer;
   StartInd, EndInd: Integer;
   RealPageName, CompName: String;
+  bListAll : Boolean;
+  TempWidth,
+  NameWidth,
+  PageWidth,
+  UnitWidth : Integer;
 begin
-  if aPageName = lis_All_ then
+  bListAll := aPageName = lis_All_;
+  if bListAll then
   begin
+NameWidth := 50;
+PageWidth := 50;
+UnitWidth := 50;
 StartInd := 1;// Skip the first entry for all components.
 EndInd := PagesListBox.Count-1;
   end
@@ -338,8 +347,23 @@
   Item.SubItems.Add(RealPageName);
   Item.SubItems.Add(Comp.GetUnitName);
   Item.Data := Comp;
+  if bListAll then
+  begin
+TempWidth := 20 + ComponentsListView.Canvas.GetTextWidth(CompName);
+if TempWidth > NameWidth then NameWidth := TempWidth;
+TempWidth := 20 + ComponentsListView.Canvas.GetTextWidth(RealPageName);
+if TempWidth > PageWidth then PageWidth := TempWidth;
+TempWidth := 20 + 
ComponentsListView.Canvas.GetTextWidth(Comp.GetUnitName);
+if TempWidth > UnitWidth then UnitWidth := TempWidth;
+  end;
 end;
   end;
+  if bListAll then
+  begin
+ComponentsListView.Column[1].Width := NameWidth;
+ComponentsListView.Column[2].Width := PageWidth;
+ComponentsListView.Column[3].Width := UnitWidth;
+  end;
   ComponentsListView.Items.EndUpdate;
 end;
 
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] Typecast set to byte in mode OBJFPC

[Jürgen Hestermann]

Am 2014-12-31 um 17:46 schrieb Luca Olivetti:

El 31/12/14 a les 17:33, Jürgen Hestermann ha escrit:


Is this realy compiler mode dependent?
I can't find any documentation about this.

Sorry, I meant that FlagSETType seems to be 4 bytes now.

http://www.freepascal.org/docs-html/prog/progsu59.html#x66-650001.2.59



Is this valid for set types too?
I think this is what I was looking for:
http://www.freepascal.org/docs-html/prog/progsu61.html


BTW:
The first link I find on Google with "free pascal sets"
is http://www.freepascal.org/docs-html/ref/refsu20.html
which does not mention any compiler directive dependencies
nor any link to $PackSet.
Maybe it should be added.




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

Re: [Lazarus] Typecast set to byte in mode OBJFPC

[Luca Olivetti]

El 31/12/14 a les 17:33, Jürgen Hestermann ha escrit:

>> Is this realy compiler mode dependent?
>> I can't find any documentation about this.
> Sorry, I meant that FlagSETType seems to be 4 bytes now.

http://www.freepascal.org/docs-html/prog/progsu59.html#x66-650001.2.59


Bye

-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es
Tel. +34 935883004  Fax +34 935883007

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

Re: [Lazarus] Typecast set to byte in mode OBJFPC

[Jürgen Hestermann]

Am 2014-12-31 um 17:30 schrieb Jürgen Hestermann:


Am 2014-12-31 um 16:55 schrieb Joost van der Sluis:

On 12/31/2014 04:40 PM, Jürgen Hestermann wrote:

type FlagType= (Flag1,Flag2);
  FlagSetType   = set of FlagType;
var i : SizeInt;
   S : FlagSetTyp;

S := [Flag1];
i := byte(S); // < Error "illegal type conversion"


i := ord(S); ?

But it's still invalid, though. A set can contain more then 32 items, and then 
your conversion does not hold anymore.


It seems that now FlagType is always 4 bytes in size while it was 1 byte in 
DELPHI mode.
That's a real problem because I have stored (and reread) these sets from a 
binary file
which now fails because of the larger set size.
Is this realy compiler mode dependent?
I can't find any documentation about this.

Sorry, I meant that FlagSETType seems to be 4 bytes now.

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

Re: [Lazarus] Typecast set to byte in mode OBJFPC

[Jürgen Hestermann]

Am 2014-12-31 um 16:55 schrieb Joost van der Sluis:

On 12/31/2014 04:40 PM, Jürgen Hestermann wrote:

type FlagType= (Flag1,Flag2);
  FlagSetType   = set of FlagType;
var i : SizeInt;
   S : FlagSetTyp;

S := [Flag1];
i := byte(S); // < Error "illegal type conversion"


i := ord(S); ?

But it's still invalid, though. A set can contain more then 32 items, and then 
your conversion does not hold anymore.


It seems that now FlagType is always 4 bytes in size while it was 1 byte in 
DELPHI mode.
That's a real problem because I have stored (and reread) these sets from a 
binary file
which now fails because of the larger set size.
Is this realy compiler mode dependent?
I can't find any documentation about this.

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

Re: [Lazarus] Typecast set to byte in mode OBJFPC

[Jürgen Hestermann]

Am 2014-12-31 um 16:55 schrieb Joost van der Sluis:

On 12/31/2014 04:40 PM, Jürgen Hestermann wrote:

type FlagType= (Flag1,Flag2);
  FlagSetType   = set of FlagType;
var i : SizeInt;
   S : FlagSetTyp;

S := [Flag1];
i := byte(S); // < Error "illegal type conversion"


i := ord(S); ?

But it's still invalid, though. A set can contain more then 32 items, and then 
your conversion does not hold anymore.



Yes, in DELPHI mode I get an error at compile time when
the set is declared larger than a byte which is ok
because I can then change all byte(S) calls.

But as already written in another mail I found that
i := SizeInt(S) works (is accepted by the compiler).
But I am not sure, whether the result is the same.
I use the typecasted integer values as an index into
an array which is declared like this:

FileStatistikArrayTyp = array[0..(1 shl (ord(High(FlagSetType))+1))-1] of ...; 
// 0..2^n-1

I don't know whether the typecasted set still starts with zero.

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

Re: [Lazarus] Typecast set to byte in mode OBJFPC

[Jürgen Hestermann]

Am 2014-12-31 um 16:40 schrieb Jürgen Hestermann:

---
type FlagType= (Flag1,Flag2);
 FlagSetType   = set of FlagType;
var i : SizeInt;
  S : FlagSetTyp;

S := [Flag1];
i := byte(S); // < Error "illegal type conversion"
---


I have already found a solution:

i := SizeInt(S);

works (although I don't know why this is accepted but byte(S) is not).

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

Re: [Lazarus] Typecast set to byte in mode OBJFPC

[Joost van der Sluis]

On 12/31/2014 04:40 PM, Jürgen Hestermann wrote:

type FlagType= (Flag1,Flag2);
  FlagSetType   = set of FlagType;
var i : SizeInt;
   S : FlagSetTyp;

S := [Flag1];
i := byte(S); // < Error "illegal type conversion"


i := ord(S); ?

But it's still invalid, though. A set can contain more then 32 items, 
and then your conversion does not hold anymore.


Joost.


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

Re: [Lazarus] Question {%MainUnit} IDE directive

[Juha Manninen]

On Wed, Dec 31, 2014 at 4:59 PM, Vojtěch Čihák  wrote:
> I have a small question about this directive.
>
> If I use: {%MainUnit ../umain.pas}
>
> is it problem when someone will open this project under Windows?
> I mean slash / backslash.

The IDE supports slash also on Windows. No problem.


> I looked here: http://wiki.freepascal.org/IDE_directives, this directive is 
> not mentioned there.

Right, the page should be updated. The directive is valid only in .inc
files which must be mentioned.


> BTW, Happy new year !

Yes, Happy new Year 2015 for everybody.

Regards,
Juha

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

[Lazarus] Deleting a control in its OnClick event can cause a SIGSEV?

[Luca Olivetti]

Hello,

I was having a random SIGSEV ("random" meaning it didn't happen every
time) in an OnClick event, the sigsev being always on the MouseUp
instruction in TControl.DoMouseUp (include/control.inc). It happened
both in windows and linux.
It turns out that in the OnClick event I was calling a method that freed
the control that generated the OnClick, so I supposed that was the cause
of the sigsev.
Now I use Application.QueueAsyncCall to fire the method after the event
has been executed and the SIGSEV seems to be gone, however, since it was
random, it may still reappear, unless the above hypothesis is true.
Is it possible that destroying the control was the cause of the SIGSEV?

TIA

Bye
-- 
Luca Olivetti
Wetron Automation Technology http://www.wetron.es
Tel. +34 935883004  Fax +34 935883007

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

[Lazarus] Typecast set to byte in mode OBJFPC

[Jürgen Hestermann]

I have a unit that is compiling in DELPHI mode
but now wanted to change it to OBJFPC mode
(in DELPHI mode I cannot use binary constants %10011100).

But OBJFPC mode I get an "illegal type conversion" with the following code:

---
type FlagType= (Flag1,Flag2);
 FlagSetType   = set of FlagType;
var i : SizeInt;
  S : FlagSetTyp;

S := [Flag1];
i := byte(S); // < Error "illegal type conversion"
---

Any idea how to convince the compiler to typecast
the set to byte in OBJFPC mode too?

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

Re: [Lazarus] Question {%MainUnit} IDE directive

[zeljko]

On 12/31/2014 03:59 PM, Vojtěch Čihák wrote:

Hello,

I have a small question about this directive.

If I use: {%MainUnit ../umain.pas}

is it problem when someone will open this project under Windows?
I mean slash / backslash.


No, LCL sources uses %MainUnit and I've never spotted such problem.
eg. look into lcl/include/dbmemo.inc. (or any other include file in 
lcl/include and it's same - use slash.


zeljko



I looked here: http://wiki.freepascal.org/IDE_directives, this directive is not 
mentioned there.

Thanks.

BTW, Happy new year !



--
___
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

[Lazarus] Question {%MainUnit} IDE directive

[Vojtěch Čihák]

Hello,
 
I have a small question about this directive.
 
If I use: {%MainUnit ../umain.pas}
 
is it problem when someone will open this project under Windows?
I mean slash / backslash.
 
I looked here: http://wiki.freepascal.org/IDE_directives, this directive is not 
mentioned there.
 
Thanks.
 
BTW, Happy new year ! 
 
 

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