How can I interogate a TCheckGroup?

[J-G]

I have created a TCheckGroup with 7 options any number of which may be checked and there could well be a further 4 options available later - though they would be exclusive so could be a separate group.

There is no problem with putting a tick in the boxes but I cannot fathom how to determine which are [ticked] at run-time.

The example on the Wiki page just talks about creating an event for when the box is [ticked] but doesn't explain which property to interrogate to determine if it is [ticked] at run-time.

Perhaps this isn't possible because TCheckGroup is the wrong component for what I want to achieve. In which case can anyone suggest a component which would do the job?

[Phil]

See extctrls.pp.

Checked property.

[molly]

As mentioned by Phil. the checked property.

small example:

Code: Pascal  [Select][+][-]

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, ExtCtrls,
9.   StdCtrls;
10.  
11. type
12.  
13.   { TForm1 }
14.  
15.   TForm1 = class(TForm)
16.     Button1: TButton;
17.     CheckGroup1: TCheckGroup;
18.     procedure Button1Click(Sender: TObject);
19.   private
20.     { private declarations }
21.   public
22.     { public declarations }
23.   end;
24.  
25. var
26.   Form1: TForm1;
27.  
28. implementation
29.  
30. {$R *.lfm}
31.  
32. { TForm1 }
33.  
34. procedure TForm1.Button1Click(Sender: TObject);
35. var
36.     i: integer;
37. begin
38.   for i := 1 to 10 do
39.   begin
40.     CheckGroup1.Items.Add('this is item ' + intToStr(i));
41.     CheckGroup1.Checked[i-1] := Odd(i-1);
42.   end;
43.  
44.   for i := 0 to Pred(CheckGroup1.Items.count) do
45.   begin
46.     if CheckGroup1.Checked[i]
47.     then ShowMessage('Item with index ' + IntToStr(i) + ' is checked')
48.     else ShowMessage('Item with index ' + IntToStr(i) + ' is not checked');
49.   end;
50. end;
51.  
52. end.
53.  
54.  

[J-G]

Thanks Phil & Molly but in my version of Laz (1.6) I don't see a 'checked' property for a TCheckGroup. I'm sure you appreciate that had there been one I would have at least tried it 

For the sake of avoiding confusion I'm talking about the TCheckGroup 4th from the right in the [Standard] components (but I can't see another).

[molly]

That is exactly the same TCheckGroup i was using in the example.

Note that Checked is not a published property. Therefor you will not be able to find it back in the object inspector.

Are you saying that you can't access the checked property at runtime for a TCheckGroup component ?

[J-G]

Note that Checked is not a published property. Therefor you will not be able to find it back in the object inspector.

??????     In that case where can I find it  ??   are there any other components with 'unpublished' properties?   if so how do I find them?

Are you saying that you can't access the checked property at runtime for a TCheckGroup component ?

I've now added the property to my code  - viz.

Code: Pascal  [Select][+][-]

1.   for i := 0 to 6 do
2.     if repeats.checked[i] then
3.       R := R + (1 shl i);
4.  

and at least it compiled  - I'll assume that it will give me the result I expect but may report back later 

[molly]

Note that Checked is not a published property. Therefor you will not be able to find it back in the object inspector.

??????     In that case where can I find it  ??   are there any other components with 'unpublished' properties?   if so how do I find them?

If you take a look at the online documentation of TCheckgroup here, then you'll notice that you can only see a whole bunch of properties there. If you look a bit closer you might be able to notice that these properties are all listed under the 'class section' named published.

Published properties are properties that are visible (and manageable) by using the object inspector. Sometimes it makes no sense to manage certain properties using the object inspector so the property does not get published.

If you click on the ancestor class link of TCheckgroup (named TCustomCheckGroup) which leads to this page, you can see there are some methods and properties listed under the 'class subsection ' named public. (including your 'missing' items property).

All public methods and properties as well as all published properties are accessible from other units. There are also private and protected sections that can be part of a class. More information about this can be read here (objects) and here (classes, for the published section visibility)


In case you are using Lazarus as editor an quick alternative method of seeing all the methods and properties is by writing the name of your component, e.g. MyCheckGroup then press the dot. If you wait a moment a window will popup that list all those things that you can currently access (so also other methods you added to your form, but also the properties and methods of the class that your variable MyCheckGroup is part of. e.g. also all the ancestor classes it inherited things from). You can force the popup window by pressing ctrl+space right after you wrote the dot.


edit:
i forgot to answer the part 'are there any other components with 'unpublished' properties? "

Yes, there are many. There are even classes that do are not components that you can use (and because they are not components you can't use the visual designer to place them on your form). Tstringlist is such an example.

[bzman24]

small example:

Code: Pascal  [Select][+][-]

1.  
2.   for i := 0 to Pred(CheckGroup1.Items.count) do
3.   begin
4.     if CheckGroup1.Checked[i]
5.     then ShowMessage('Item with index ' + IntToStr(i) + ' is checked')
6.     else ShowMessage('Item with index ' + IntToStr(i) + ' is not checked');
7.   end;
8.  
9.  

Isn't this the same as:

Code: Pascal  [Select][+][-]

1.  
2.   for i := 0 to CheckGroup1.Items.count -1 do
3.   begin
4.     if CheckGroup1.Checked[i]
5.     then ShowMessage('Item with index ' + IntToStr(i) + ' is checked')
6.     else ShowMessage('Item with index ' + IntToStr(i) + ' is not checked');
7.   end;
8.  
9.  

if so, which is the better or preferred way to code such operations?

Thanks,  BZMan

[J-G]

If you take a look at the online documentation of TCheckgroup here,

When I'd read as far as this I clicked the link and the reasons quickly became obvious !  but I'm pleased you took the trouble to spell it out for me.

Some details of your previous answer to my queries also became apparent 

Now you've told me twice I might understand and remember.

I can only hope that there are other 'numpties' out there that may well read threads that I start and avoid the embarrassment that I heap upon myself 

The concept of 'Objects' and 'Ancestry' is slowly being forced into my grey matter!

Incidentally - The result for 'R' in my code did prove to be as expected  -  once I'd initialized R to zero!!

[molly]

Isn't this the same as:

Yes, the outcome is the same.

if so, which is the better or preferred way to code such operations?

I do not think there is a better or preferred way of doing things (*)

For me it is a personal preference. I simply hate those dangling -1's +1's, -2's, etc. in my code. Seeing such numbers doesn't say anything to me, while Pred(xxx) means explicitly that i meant the predecessor of the value. Seeing all the mistakes being made (here on the forums as well) with regards to dynamic arrays, this is one of the better solutions instead of using absolute values.

(*) in case you wondering why i did use the minus one in the other loop: Topic Starter had issues with that in the past as well so, i showed both ways in the hope he understands the underlying hint

[bzman24]

Molly,

Thanks.  Something new learned again. 

[J-G]

[...]
Isn't this the same as:
[...]
if so, which is the better or preferred way to code such operations?

Thanks,  BZMan

One of the early lessons I learned ( in the 1980s ) was that if a special operator had been written  - such as  Inc, Dec, Pred ...  it had been done for a reason and that was usually one of efficiency or, more likely, speed.

I would therefore always use the operator.

I see Molly has replied whilst I've been cogitating and her reasons are equally valid 

[bzman24]

I have been using the "dangling -1's +1's, -2's, etc." as Molly calls them, but I see what you are saying.  As I stated, the more time I'm on here the more I learn.  Thanks for the advice.

[J-G]

Just noticed your Edit Molly and now know what TS means    I've been trying to work that out for the past month !!

It seems that I don't always follow my own advice either

[molly]

I can only hope that there are other 'numpties' out there that may well read threads that I start and avoid the embarrassment that I heap upon myself 

The concept of 'Objects' and 'Ancestry' is slowly being forced into my grey matter!

No problem at all.

You do not have to feel too embarrassed as you simply can't know all individual properties and methods from every component or class from mind.

If you pay attention to question asked on (delphi/pascal/lazarus) forums (but this is also true for modern languages such as c#, java)  you'll notice that many questions are related to how one can accomplish something with this or that component or class, usually indicating someone isn't fully aware of all available properties/methods.

Even i do not know them all from mind, and sometimes have to spend some time researching and understanding a component/class to understand how something could be accomplished the easiest or the best way possible.

The more often you use a certain component, the more familiar you get with it which, in the end, fills your brain to such extend that you do not have to peek into the help-files anymore.

... and then you start installing more/other components (from 3-th party) and you can start all over again :-)

Being able to use a visual designer more or less hides all the inheritance stuff etc from you but, also offers the opportunity to get familiar with a certain component without the need to read tens or sometimes hundreds of help-pages.

At a certain point in time you start asking yourself questions on how these components are build-up and how they work or perhaps you want to accomplish something with it that doesn't have an easy answer. At that point one usually starts researching the component/class and its ancestors. Then you start understanding inheritance and in case not possible by default, modify an existing component to do what you want it to do.

It takes time to learn all my dear padawan