Re: [Lazarus] ListView Custom Draw Item

[zeljko]

On 09/11/2014 07:45 AM, Richard Mace wrote:

Hi All,
I have the following code on a ListView Custom Draw Item event, where
the font is displayed red, but it's not bold.
Any ideas?

Sender.Canvas.Font.Style := [fsBold];
Sender.Canvas.Font.Color := clRed;

Lazarus 1.24 Windows 8


AFAIR there is open issue about font problems in custom draw item in 
win32 widgetset.


zeljko


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

[Lazarus] ListView Custom Draw Item

[Richard Mace]

Hi All,
I have the following code on a ListView Custom Draw Item event, where the
font is displayed red, but it's not bold.
Any ideas?

Sender.Canvas.Font.Style := [fsBold];
Sender.Canvas.Font.Color := clRed;

Lazarus 1.24 Windows 8

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

Re: [Lazarus] Code completion problems with Graph units

[Mattias Gaertner]

On Wed, 10 Sep 2014 17:36:19 +0200
Sven Barth  wrote:

>[...]
> > > Lazarus version is 1.2.4 on i386-linux-gtk2
> >
> > Under Linux 64bit I can use the 'graph' unit and find declaration finds
> > $fpc/packages/graph/src/unix/graph.pp
> > Then FD on the {$i graphh.inc} gets me to
> > $fpc/packages/graph/src/inc/graphh.inc

I tested with linux-i386 and it works too.
So, maybe it's an issue with Lazarus 1.2.4.
Can you test with a 1.3 or a newer 1.2?

 
> I can reproduce it on i368-linux (1.2.4) and
> i368-win32 (1.2.2). What did work however is copying the graph include
> files and units to a local directory and including that in "Other sources".


Mattias

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

Re: [Lazarus] TComboBoxEx and TCheckComboBox

[Vojtěch Čihák]

I wasn't clear. What I was talking about was TCheckComboBox.
 
TComboBoxEx has property ItemsEx which is TCollection descendant.
Property Items is covered there. I used the same what Delphi do. 
__

Od: "Vojtěch Čihák" 
Komu: Lazarus mailing list 
Datum: 10.09.2014 17:44
Předmět: Re: [Lazarus] TComboBoxEx and TCheckComboBox


MyStrings.Assign(ComboEx.Items)  //this should work normally
 
ComboEx.Items.Assign(MyStrings)  //this is possible via 
ComboEx.AssignItems(MyStrings) 
 
There are inconsistency but I see now way how  to avoid it.
 
For example, the ComboEx.Items.Assign(). Here I would need some notification 
that new data was assigned - to clear old TCheckComboItemStates and create new 
one for each new string in list.
But there is no such notification. I tried to create new class derived from 
TStringList but it lead to other problems. Class helper and FPONotifyObserver 
was also a blind way.
 
Vojtěch 
 

[...]  



PTCheckComboItemState(Items.Objects[i])^.Data;
 
Although, I can do new property TCheckComboBox.Objects[] and getters + setter 
will do the job.


This is possible, but it would be inconsistent to the other LCL
controls.

For example:
Items is a TStrings, so it would be nice if 
ComboEx.Items.Assign(MyStrings) and MyStrings.Assign(ComboEx.Items)

works normally.

It would be nice if the Enabled states are stored outside Items.

Mattias

--
___
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 mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Re: [Lazarus] TComboBoxEx and TCheckComboBox

[Vojtěch Čihák]

MyStrings.Assign(ComboEx.Items)  //this should work normally
 
ComboEx.Items.Assign(MyStrings)  //this is possible via 
ComboEx.AssignItems(MyStrings) 
 
There are inconsistency but I see now way how  to avoid it.
 
For example, the ComboEx.Items.Assign(). Here I would need some notification 
that new data was assigned - to clear old TCheckComboItemStates and create new 
one for each new string in list.
But there is no such notification. I tried to create new class derived from 
TStringList but it lead to other problems. Class helper and FPONotifyObserver 
was also a blind way.
 
Vojtěch 
 

[...]  



PTCheckComboItemState(Items.Objects[i])^.Data;
 
Although, I can do new property TCheckComboBox.Objects[] and getters + setter 
will do the job.


This is possible, but it would be inconsistent to the other LCL
controls.

For example:
Items is a TStrings, so it would be nice if 
ComboEx.Items.Assign(MyStrings) and MyStrings.Assign(ComboEx.Items)

works normally.

It would be nice if the Enabled states are stored outside Items.

Mattias

--
___
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] Code completion problems with Graph units

[Sven Barth]

Am 10.09.2014 11:19 schrieb "Mattias Gaertner" :
>
> On Tue, 09 Sep 2014 22:17:38 +0200
> Sven Barth  wrote:
>
> > Hello together!
> >
> > I'm currently working on a project that uses the good old Graph units
> > (or PtcGraph to be more precise) and I have the problem that code
> > completion is erratic if (Ptc)Graph is in the uses-clause, because the
> > IDE can not find the graphh.inc include file which is at the top of all
> > Graph units. This include file is located in $fpc/packages/graph/src/inc
> > whereas the full Graph units are located in other directories of
> > $fpc/packages/graph/src/.
> > I've also tried adding the path of the include directory to the "Other
> > source files" or the "Include directories" path. The IDE then either
> > complains that it still can not find the file or it complains that it
> > could not find the end of the file with the cursor still getting
> > positioned at the $include directive.
> >
> > Any ideas I could try? (besides commenting out the include directive :P)
> >
> > Lazarus version is 1.2.4 on i386-linux-gtk2
>
> Under Linux 64bit I can use the 'graph' unit and find declaration finds
> $fpc/packages/graph/src/unix/graph.pp
> Then FD on the {$i graphh.inc} gets me to
> $fpc/packages/graph/src/inc/graphh.inc
>
> Works on 2.6.4 and 2.7.1.
>
> It works with unit ptcgraph as well:
> $fpc/packages/graph/src/ptcgraph/ptcgraph.pp
> $fpc/packages/graph/src/inc/graphh.inc
>
> Have you tried Tools / Rescan FPC source directory?

I now did, no difference. I can reproduce it on i368-linux (1.2.4) and
i368-win32 (1.2.2). What did work however is copying the graph include
files and units to a local directory and including that in "Other sources".

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

Re: [Lazarus] TComboBoxEx and TCheckComboBox

[Mattias Gaertner]

On Wed, 10 Sep 2014 16:59:10 +0200
Vojtěch Čihák  wrote:

>[...]  

> PTCheckComboItemState(Items.Objects[i])^.Data;
>  
> Although, I can do new property TCheckComboBox.Objects[] and getters + setter 
> will do the job.

This is possible, but it would be inconsistent to the other LCL
controls.
For example:
Items is a TStrings, so it would be nice if 
ComboEx.Items.Assign(MyStrings) and MyStrings.Assign(ComboEx.Items)
works normally.

It would be nice if the Enabled states are stored outside Items.

Mattias

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

Re: [Lazarus] TComboBoxEx and TCheckComboBox

[Vojtěch Čihák]

Currently, Items.Objects[] is used as a pointer:
 
{ TCheckComboItemState }
TCheckComboItemState = record
State: TCheckBoxState;
Enabled: Boolean;
end;
PTCheckComboItemState = ^TCheckComboItemState;  
 
I needed to hook there because the combo can be sorted and Objects are sorted 
too.
If it is enough, I can extend the record to:
{ TCheckComboItemState }
TCheckComboItemState = record
State: TCheckBoxState;
Enabled: Boolean;
Data: TObject;
end;
PTCheckComboItemState = ^TCheckComboItemState;
 
which will allow to users to have associated object but working with Data will 
be little different
than working with normal Combo.
 
Instead
Items.Objects[i];
it will be
PTCheckComboItemState(Items.Objects[i])^.Data;
 
Although, I can do new property TCheckComboBox.Objects[] and getters + setter 
will do the job.
__

Od: Mattias Gaertner 
Komu: 
Datum: 10.09.2014 16:14
Předmět: Re: [Lazarus] TComboBoxEx and TCheckComboBox


On Wed, 10 Sep 2014 15:51:03 +0200
Vojtěch Čihák  wrote:



The second is combo with checkboxes. Internally it uses Items.Objects[] for 
storing State and ItemEnabled.


Can you change that? 
Items.Objects is usually for users custom data.


___
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] TComboBoxEx and TCheckComboBox

[Mattias Gaertner]

On Wed, 10 Sep 2014 15:51:03 +0200
Vojtěch Čihák  wrote:

> Hi,
>  
> I implemented TComboBoxEx and TCheckComboBox.
> The first is combo with images. This control is in Delphi7 too.

Great!

> My implementation has one difference - it is readonly, because I
> needed csOwnerDrawFixed for painting.
>
> The second is combo with checkboxes. Internally it uses Items.Objects[] for 
> storing State and ItemEnabled.

Can you change that? 
Items.Objects is usually for users custom data.


> Some known issues are described in README.txt which is attached in archive. 
> Package in comboex.zip is now available here: 
> http://bugs.freepascal.org/view.php?id=26515#bugnotes 
>  
> So it's up to Lazarus managers to decide whether the components will be part 
> of Lazarus or if I should make them in separate package or part of my 
> EC-Controls.
>  
> I tested them in GTK2/Qt4 and Wine, so some test in Carbon is welcome.

Thanks for contributing.

Mattias

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

[Lazarus] TComboBoxEx and TCheckComboBox

[Vojtěch Čihák]

Hi,
 
I implemented TComboBoxEx and TCheckComboBox.
The first is combo with images. This control is in Delphi7 too. My 
implementation has one difference - it is readonly, because I needed 
csOwnerDrawFixed for painting.
The second is combo with checkboxes. Internally it uses Items.Objects[] for 
storing State and ItemEnabled.
Some known issues are described in README.txt which is attached in archive. 
Package in comboex.zip is now available here: 
http://bugs.freepascal.org/view.php?id=26515#bugnotes 
 
So it's up to Lazarus managers to decide whether the components will be part of 
Lazarus or if I should make them in separate package or part of my EC-Controls.
 
I tested them in GTK2/Qt4 and Wine, so some test in Carbon is welcome.
 
Thanks.
 
Vojtěch 
 

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

Re: [Lazarus] Code completion problems with Graph units

[Mattias Gaertner]

On Tue, 09 Sep 2014 22:17:38 +0200
Sven Barth  wrote:

> Hello together!
> 
> I'm currently working on a project that uses the good old Graph units 
> (or PtcGraph to be more precise) and I have the problem that code 
> completion is erratic if (Ptc)Graph is in the uses-clause, because the 
> IDE can not find the graphh.inc include file which is at the top of all 
> Graph units. This include file is located in $fpc/packages/graph/src/inc 
> whereas the full Graph units are located in other directories of 
> $fpc/packages/graph/src/.
> I've also tried adding the path of the include directory to the "Other 
> source files" or the "Include directories" path. The IDE then either 
> complains that it still can not find the file or it complains that it 
> could not find the end of the file with the cursor still getting 
> positioned at the $include directive.
> 
> Any ideas I could try? (besides commenting out the include directive :P)
> 
> Lazarus version is 1.2.4 on i386-linux-gtk2

Under Linux 64bit I can use the 'graph' unit and find declaration finds 
$fpc/packages/graph/src/unix/graph.pp
Then FD on the {$i graphh.inc} gets me to
$fpc/packages/graph/src/inc/graphh.inc

Works on 2.6.4 and 2.7.1.

It works with unit ptcgraph as well:
$fpc/packages/graph/src/ptcgraph/ptcgraph.pp
$fpc/packages/graph/src/inc/graphh.inc

Have you tried Tools / Rescan FPC source directory?

Note: The FPC source directory has its own search paths. It does not use
the project's search paths.

Mattias

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

Re: [Lazarus] Code completion problems with Graph units

[payl]

On 10.09.2014 07:52, Sven Barth wrote:

Nope... moving the "graph" node up does not change anything *sigh*

(Warning: No nice solutions here)
Well I would first try if CodeTools are just unable to find inc file, so I  
would try to move/copy include file so CodeTools can find it. You noted  
that sometimes It tells you it's unable to find end of file: Maybe  
conditionals make CodeTools ignore rest of file? You could try messing  
with predefined conditionals. Or bruteforce solution: Manually include inc  
file and then test if everything works.
I wouldn't be surprised if CodeTools couldn't parse this file due to some  
bug in parsing, there are still some notable bugs there.


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