Store the value of Checkbox

[balazsszekely]

Hi guys,

I have 16 checkBoxes, each representing a bit(0-unchecked, 1-checked). I can store all the values in 2 bytes:
   Bin(1111 1111 1111 1111) = Dec(65535) = Hex(FFFF).
The fpc "Word" data type is exactly 2 bytes. So far so good.

To make a long story short, for objective reasons(it's beyond my control), I cannot change the data type, yet somehow I must store the value of 1-4 more checboxes. Is this possible somehow? Because nothing comes to my mind right now. I know what I'm asking is not too realistic...it's like sitting 5 people to 3 chairs.

regards,
GetMem

[taazz]

Depends heavily on the value grouping. Are there values that can be grouped together in to two groups in a way that when a group is active the other group's values must always be either checked, unchecked or invalid?  If not (I assume it is not) then there is no reason important enough to stop you from using 32bits instead of 16bits.

[celyo]

Hi,

Do you need mask search? If not, word is just 2 bytes, char + char - you can use character encoding like 'A-Z' + 'A-Z' -> this is something like  30-decimal number system

[x2nie]

"Talk is cheap. Show me the code." --Linus Trovald

[balazsszekely]

@x2nie
"Talk is cheap. Show me the code." --Linus Trovald

What code do you want to see? It's a logic problem. Next time please think twice before you speak.

@celyo
Do you need mask search? If not, word is just 2 bytes, char + char - you can use character encoding like 'A-Z' + 'A-Z' -> this is something like  30-decimal number system

Thank you for your suggestion, but you totally misunderstood the problem. There is no mask search and no chars.

@taazz
Depends heavily on the value grouping. Are there values that can be grouped together in to two groups in a way that when a group is active the other group's values must always be either checked, unchecked or invalid?  If not (I assume it is not) then there is no reason important enough to stop you from using 32bits instead of 16bits.

Thank you taazz! Unfortunately the checkboxes are totally independent so there is no possibility for grouping. You came to the same conclusion, basically it's impossible to store the values in 2 bytes.

[x2nie]

@x2nie
"Talk is cheap. Show me the code." --Linus Trovald

What code do you want to see? It's a logic problem. Next time please think twice before you speak.

You asked about technical detail. And you want it be solved by a conceptual design?

[balazsszekely]

@x2nie
Stop infesting this thread with smartass comments, if you have some constructive ideas you're welcome, if not please go somewhere else.

[molly]

I have 16 checkBoxes....
The fpc "Word" data type is exactly 2 bytes. So far so good.

To make a long story short, for objective reasons(it's beyond my control), I cannot change the data type, yet somehow I must store the value of 1-4 more checboxes. Is this possible somehow?

Nope. It is not possible to store 20 individual bits inside a word. Unless, as taazz suggested, they can be grouped (e.g. some combinations cannot occur). But then, using a word is pretty cramp.

Could you add the 'extra' 4 bits to another additional variable, and use the first word to express that your code requires to read that variable when a certain combination/vale is met ? e.g. current checkbox 16 bit would then indicate that it needs to read from the other value when it is set, otherwise ignore the extra variable.

[balazsszekely]

@molly

Thank you! I came to the same conclusion yesterday, but I thought maybe there is some clever xor/and/or operation that I'm not aware of. Yes I will solve this, by adding an extra byte, but this requires to redesign the whole application(not coded by me). 

[x2nie]

@x2nie
Stop infesting this thread with smartass comments, if you have some constructive ideas you're welcome, if not please go somewhere else.

Ha ha ha!


Well, it seem, first, I must apologize if I hurt you. I really don't like to do that.
Next, I need to explain why i did that.
You know from the first post of this thread that what you want is about impossible.
But my "smartass" motto was : Impossible = I don't know the way.
So, AFAIK I am in your side in though of : there is must be a way to do.
Then, the solution should be in detail = case by case, there is no general solution for all problem.


Well, okay, it is fine if you can't show the code. please don't be emotional, AFAIK it is going to pure technical.


ACtually I have already had similar problem during development some part of SynEdit.
I added a longword (32 bit) member to the synedit-codeinfo, where each bit is one level flag of whether a line is in neck of procedure.
It was going harder when there is a need to sum of created procedure between $ifdef ... $else.
This situation, longword / word is not an option, because what the really needed is integer (or byte, at least).
So I added an dynamic array of byte.
But it failed when there is another need to quick compare of two codeinfo, array cant be direct comparing.


My latest choice is string: string can be just compared, string is array of char (another byte).
But it wouldn't be enough, because in some real code, the amount of procedure created between $ifdef .. $else may beyond the byte range ( > 255).


So, you know, the solution is probably very depends on the actual code. case by case.
(evil is in detail  )
Now, I don't want to see the code.


I you can accept an advice, please don't think too bad about people, we might lost a chance to know whether people still think good about you.

[molly]

@GetMem
fwiw:
usually when i do that sort of thing, i always attempt to use the largest possible type that's available, so that additional bits can be added later on and then 'or' off the non used bits. (i ran into your situation one too many).

If i have absolutely no clue how many bits would be required in the future (sometimes you can tell), i use a string as that can be of variable length and offers more flexibility.

Although i have no clue about your existing implementation, i do would like to advise to not expand with a byte. Instead i would advise (and of course when possible) to use the first word to indicate using your additional solution, and use a Qword for your solution, containing all the (previous) settings (so rewrite all reference to the previous used word and use your new qword).

PS: be careful with which value/bit to use to indicate that you need/want to use the extra bits (or newly implemented solution), as perhaps things can cause havoc in existing code. The perfect solution would be if you are able to ignore the original word all-together and replace with using a qword. The next best thing would be to use a value/bitcombination in the existing word that can _never_ occur (but i understand that this is not always possible).

[x2nie]

I have some ideas.


1. if your word data is wrapped together with string, there are a hole (hacked solution).
The idea is to append checkboxvalues into the string, with delimiter char.

let say, you have a record (or data table row fields) :

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

1. myRec = packed record
2.   name : string; // Customer Name
3.   options : word; //checkboxes value.
4. end;

1.a) on saving:

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

1.  rec.name := rec.name + #0 + inttostr(longword_checkboxvalues)
2.  //or
3.  rec.name := rec.name + #0 + inttostr(additional_byte_checkboxvalues);

1.b) on displaying:

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

1.  longword_checkboxvalues := strtoint( copy(rec.name, pos(rec.name, chr(0)), 10000);
2. //or
3.  additional_byte_checkboxvalues:= strtoint( copy(rec.name, pos(rec.name, chr(0)), 10000);
4.  
5.  
6.  
7.  labelName.caption := pchar(rec.name); //exclude the char(zero)
8. //or
9.  labelName.caption := copy(rec.name, 1, pos(rec.name, #0)-1); //exclude the char(zero)

You can use another char  instead of chr(0), (maybe you like to use #13,#7 whatever non-visual char) for safety of database storage.

tell me if it doesn't work.   I have more strange solutions

[balazsszekely]

@x2nie
1. You did not hurt me
2. I can accept an advice anytime
3. Apparently you're not a smart ass after all, which is good. Sorry about that!

Ok. Let's press the reset button and forget everything. 
I attach a small demo application which describe the problem visually. Feel free to play with it, check as many checkbox you like. The bottom line is: in the end, you will find a value(word data type), displayed in the "Decimal" editbox(see screenshot). This value is stored as two separate bytes, with the help of Lo and Hi commands.  Later from this two bytes I can reconstruct the checkboxes(which one is checked, which one is not). To achieve this, I use some shl and xor operations. This worked very well until now,  the problem is I have to store up to 4 more checkboxes, without changing the data type. Under normal circumstances, this would be a trivial task, but with the constrain is impossible or so I thought yesterday. To be absolutely sure I opened this thread. Apparently @taazz and later @molly almost instantaneously understood the problem and replied as I expected. That's why I was a little bit irritated by your response. Again sorry!

[molly]

@GetMem
Yes, i understood the problem because i've dealt with such bitf*ckers that thought they were smart to save a few bits, leading to these kind of troubles when things need to be expanded.

But, my curiosity got the best of me 

Also, so that we're on the same page (not to offend).

The restriction of using a word is given, you cannot change it and you need to add 4 bits.

Do these 4 bits interact with the previous 16 bits ? e.g. do you need to create a number that now need to consist of 20 bits instead of the old sized 16 bits ?

And if so, do you have a problem combining these extra 4 bits to form a 20 bit number (and vice versa extract those 20 bits again is seperate 4 and 16 bits again) ?

Are you also restricted using only a word inside your code (can't imagine, but stranger things have happened), or can you use a longword/qword/string for the internal (in your code) representation of those 20 bits ?

[taazz]

So as I thought the problem is not how its kept in memory but your problem is when you save those now you will have to break compatibility with existing files. If I'm right the solution is simple. Start a new group of bit values which is appended in the file in a way that does not break compatibility or makes reading them back harder. For example append them at the end of the file the old versions will never rich that data and the new version will just have one more read command.