Recent

Author Topic: Store the value of Checkbox  (Read 17946 times)

balazsszekely

  • Guest
Re: Store the value of Checkbox
« Reply #15 on: January 05, 2016, 12:14:03 pm »
@molly, @taazz
Let me explain a little bit further. Let's say a user checks the following checkboxes: "1010 1100 1100 0010", then press the OK button. The resulting value will be 44226:
Code: Pascal  [Select][+][-]
  1. var
  2.   LoByte, HiByte: Byte;
  3. begin
  4.   //conversion  
  5.   CheckBoxes := 44226;
  6.   LoByte := Lo(CheckBoxes);
  7.   HiByte := Hi(CheckBoxes);
  8.   ShowMessage(IntToHex(LoByte, 2) + sLineBreak + IntToHex(HiByte, 2));//displays C2 and AC
  9. end;

After ShowMessage, I will have two hex values(without the $) basically 2 strings, each string's length is 2.  Now this 2 string eventually will become part  of a larger string(serial number) and the total length of serial number must be constant. That is my problem not actually the word variable. Hope it's clear now.

x2nie

  • Hero Member
  • *****
  • Posts: 515
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Store the value of Checkbox
« Reply #16 on: January 05, 2016, 12:39:30 pm »
Nice. (I wonder why you didn't tell me that you are working in such fixed-length serial number).


do you know, serial number can be expanded by allowing such more char combination?
16 bit = ['0'..9,A..'F' ] * 4 ='0000' ~ 'FFFF'
2 string with each 2 char width = '0000' ~ 'ZZZZ' // 'z' == 'Z'


meaning: you have already had more bit for serial number purpose! >:D


if it serial number, it really better if it has more wide range of probabilities.


maybe, you can add more large possibilities by allowing insensitive char : 'z' <> 'Z'.



« Last Edit: January 05, 2016, 12:42:21 pm by x2nie »
When you were logged in, you can see attachments.
Lazarus Github @ UbuntuCinnamon-v22.04.1 + LinuxMintDebianEdition5

molly

  • Hero Member
  • *****
  • Posts: 2330
Re: Store the value of Checkbox
« Reply #17 on: January 05, 2016, 12:45:36 pm »
thank you GetMem,.

Hope it's clear now.
Well, tbh not really (sorry as i realize that must work frustrating for you), but at least the plot thickens  :D

x2nie, has a valid point as you seem to be using only hexadecimal number for serial number.

Even if you would only allow for the last 2 chars of that serial number to be able to input/store a..z characters, you would have solved your problem  :)

balazsszekely

  • Guest
Re: Store the value of Checkbox
« Reply #18 on: January 05, 2016, 01:17:38 pm »
@molly
What exactly it's not clear? Maybe I can explain it better.

@x2nie
I cannot use anything else then HEX, I must keep the compatibility with the older version.

molly

  • Hero Member
  • *****
  • Posts: 2330
Re: Store the value of Checkbox
« Reply #19 on: January 05, 2016, 02:16:20 pm »
It is still a bit unclear for me, as you seem to describe the problem from the opposite end :-)

Not a problem perse, depending on your view (and code in front of you  :D )

Am i correct when stating that the serial number correspond with locking/unlocking a certain amount of features in the program (represented by your checkboxes/bits), or at least something similar to that extend ?

You like to extend those existing features by adding 4 more newly introduced features/bits ?

These features are directly 'linked' to the serial number

You cannot extend the length of the serial number,  because that would break backwards compatibility ?

You cannot use g..z characters because you believe that to break backwards compatibility as well ?

If the answers to all those questions above are answered with yes, then you got yourself a (more or less self-inflicted) problem :-S

FWIW: The serial number _can_ be extended with g..z characters, but existing serials numbers would not be able to profit from those new features/unlockables unless a new serial number is obtained.

Existing serial numbers could still be used when having implemented serials extended with g..z chars, but with the same restriction as mentioned before -> no new features/bits for old serials (unless you unlock them by default for those serials).

In hindsight, it is a very bad idea to 'link' a certain amount of bits/features _directly_ to a serial number this way, as it is too restrictive (as you most likely have noticed yourself).

If what i wrote is more or less something to your current situation (and in case it concerns end-user serial numbers), i would opt for redesigning the serial number system and corresponding feature bits once (and do it properly), and re-issue new serial numbers. It is possible to distinct between old and new situation in your program, so that existing (old) serial numbers are still applicable/valid as well as accept new serial numbers (to be able to unlock the new features).

In addition to re-issuing serial numbers, you could opt to write a small program for that, so that users can enter old serial number and see their new serial number, also for the programmer to make sure to not re-issue serial numbers that are already 'occupied'.

In case not speaking about end-user serial numbers, then please consider redesigning the whole lot anyways.

Up til now i assumed this project was not your own, in which case the 'burden' for re-issueing serial numbers is for someone else (might perhaps make the decision easier for you), but please feel free to correct me when wrong.

In any case, someone was not thinking clear when designing/implementing this stuff, and right now it seems there are so many restrictions applied that things can't be solved in an easy way.

Unfortunately i currently believe that one way or another you need to deal with that first before being able to continue. Unless what i wrote is way off :fingers-crossed:

x2nie

  • Hero Member
  • *****
  • Posts: 515
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Store the value of Checkbox
« Reply #20 on: January 05, 2016, 02:32:02 pm »
@x2nie
I cannot use anything else then HEX, I must keep the compatibility with the older version.
Very nice, so you will only deal with the earlier "word" problem (16 bit fixed length), then.


Okay, the next idea is what Zip does (at least AFAIK).
I didn't really know what are deflate, inflate, etc. But, they will help you more in detailed technique.


Here we are talking about  get benefit of such pattern of bit:


1. we can split all bits into groups.
    let say, you can split each of 4 bits: 1010 1100 1100 0010 // = 4 group of 4bit
    or 5 bits : 1 01011 00110  00010 // = 4 group of 5 bit
    (or whatever as needed later).


2. make constants of known pattern. Below pattern should be applied if you choose 5bit of pattern length.
   patternFirst = {'00001'} $1;
   pattern02 = {'00010'} $2; etc...


3. check if a pattern is repeated twice or more.
    save it in a few bits. let say this info need 2 bit
   this way, this additional repetation bit info will decrease the maximum length (16 - 3 = 13)
   but you can play with this yet unused 13 bit.
   
4. the amount of known pattern will take place into account.
    let say your known pattern constant amount is 32   { = 5bit}, you have 13 - 5 = 8 bit unused.


let take all together:
* picked pattern = 3 group of 5 bit each.


* pattern repetitive ................ = 3bit
* known pattern = 32 pattern = 5bit
-----------------------------------------------+
* used bit=...............................= 8
* total bit ................................= 16
---------------------------------------------- -
* unused bit.............................= 8


so for such actual number [00010 00010 00010 00010], will be stored as [  011 00010]
explanation right to left:
00010 = 2 = second pattern = 00010
011 = 3 = the '00010' repeated three times: as first and second and 3rd


let name it SCHEME#1


Well, this situation:
+ you have a range of well recognized (parse-able) bits.
+ you have a large ( 8) unused bit
+ you lost another range of non-parse-able 16bit numbers.


Nice, 8 used bit + 8 unused bit. !


The trick is we use 8 unused bit for our other format.
Remember, above is just first format.
8 unused bit = 256 format.
(How complex it would be?)
You need to repeat the first step for creating another new scheme.


In real world, it wouldn't be that large, maybe you only need 16 scheme (4bit).
each scheme can have different parsing (bit allocation).
If so, there are only 4bit fixed being allocated for scheme flag for any 16bit numbers.
other than this 4bit is parsed depends of scheme used.


in this stage, before parse anything, you need to check this 4bit.
Let say the first 4 bit value = $0000; the you do above (SCHEME#1) parsing.
if the first 4 bit = $0001; then you do SCHEME#2


Scheme#2, may use different group & split of the rest bit.
Scheme#3, will use completley different calculation
Scheme#n may use constant of 16bit values.

At this level,
for such actual number [00010 00010 00010 00010],
will be stored as [011 00010 0000]
explanation right to left:
0000 = SCHEME#1
00010 = 2 = second pattern = 00010
011 = 3 = the '00010' repeated three times: as first and second and 3rd

If you aren't satisfied with this stupid result, you can iterate through all available scheme, finding which result among them is less significant (less bit needed).
So you may compare them to get the best result.
It is specially needed to reduce bits needed, and in the same time to increase the amount of parse-able numbers.



-------------
That's all what I know about compression.
Remember, you have 16 SCheme (if you choose 4bit). So use your imagination to fill that very large possibilities.



Well, is it proof of concept? Yes. it is.
In the Scheme#1, it really take benefit of such pattern existed in bits value.
In the end, you will need to find which 16bit values are not catched by any schemes.
in this situation, your last scheme will just a map headed of one to one between number as index and the value it should return.


I think you need to learn deeply of what zip did, it is open-source, AFAIK. so good luck! 8-)
« Last Edit: January 05, 2016, 02:57:19 pm by x2nie »
When you were logged in, you can see attachments.
Lazarus Github @ UbuntuCinnamon-v22.04.1 + LinuxMintDebianEdition5

balazsszekely

  • Guest
Re: Store the value of Checkbox
« Reply #21 on: January 05, 2016, 02:59:45 pm »
First of, all I did manage to solve the problem by storing the extra values somewhere else. This is only a temporary solution though.

@molly
Quote
You like to extend those existing features by adding 4 more newly introduced features/bits ?
These features are directly 'linked' to the serial number
You cannot extend the length of the serial number,  because that would break backwards compatibility ?
You cannot use g..z characters because you believe that to break backwards compatibility as well ?
If the answers to all those questions above are answered with yes, then you got yourself a (more or less self-inflicted) problem :-S
All of the above it's true with a small correction: I didn't inflicted anything. I "inherited" a crappy, badly designed program. Now my boss wants me to do the magic trick, namely: add for more checkboxes(new features as you correctly stated) but without breaking the existing structure.

Quote
In hindsight, it is a very bad idea to 'link' a certain amount of bits/features _directly_ to a serial number this way, as it is too restrictive (as you most likely have noticed yourself).
I agree!

Quote
If what i wrote is more or less something to your current situation (and in case it concerns end-user serial numbers), i would opt for redesigning the serial number system and corresponding feature bits once (and do it properly), and re-issue new serial numbers. It is possible to distinct between old and new situation in your program, so that existing (old) serial numbers are still applicable/valid as well as accept new serial numbers (to be able to unlock the new features).
I agree again, I can do the redesing in a few hours, but my boss does not like the idea(don't ask me why).

@x2nie
That's a good idea. Believe it or not, I was thinking about a zip like system, I'm not sure it will work in all situation though. I will study the problem more.

molly

  • Hero Member
  • *****
  • Posts: 2330
Re: Store the value of Checkbox
« Reply #22 on: January 05, 2016, 03:53:08 pm »
All of the above it's true with a small correction: I didn't inflicted anything. I "inherited" a crappy, badly designed program. Now my boss wants me to do the magic trick, namely: add for more checkboxes(new features as you correctly stated) but without breaking the existing structure.
Ok i apologize if my chosen words sounded perhaps too harsh.

What i meant to say is that someone on this earth inflicted so much pain on him/herself (or company) that it is now bothering you.

I already suspected it was a work related assignment (as this kind of thing does not happen with programmers who know what they are doing, no offense intended there)

Quote
I agree again, I can do the redesing in a few hours, but my boss does not like the idea(don't ask me why).
I won't, but sometimes you have to be realistic.

I do got a few tricks on my sleeves to pester your boss though ;-)

Quote
@x2nie
That's a good idea. Believe it or not, I was thinking about a zip like system, I'm not sure it will work in all situation though. I will study the problem more.
Yes, it is indeed a good idea, but i do believe 16 bits is too cramp to be able to realize that for all possible bit combinations.

Other than that, do realize if you implement such solution from serial number point of view, that all serial numbers need to be re-issued as well. If using the same serials but 'decode' it to store in a matter as x2nie showed then certain serial numbers would have unlocked certain features that don't belong to that serial number (or you do not want unlocked for that serial number).

Which brings me to my sleeve:
Let's say you have 4*2 character combinations, e.g. aA bB cC dD.
If odd(a) and even(B) and not odd(c) and odd(D) then set new bit 0
something randomly chosen but not all the same combination for new bits 1,2 and 3 ;-)
You have 16 bits to chose from.

But seriously, you might want consider that when a serial number has already all 16 features 'unlocked' that it automatically unlocks the newly introduced features.

If i am correct and boss believes to introduce new features this way for which end-user has to pay (extra) to unlock then boss might want to reconsider not allowing you to redesign the whole lot -> this is a dead end as long as the serial is directly linked to the features (and applying current restrictions)

If you are really stuck, you could perhaps take a look at already issues serial numbers and see if there are combinations that aren't already issued (and abuse those bits, not issuing 'old' serials that use these bits). But that is a very slippery road, of which i would vote against (if even possible at all).

Better use a serial to unlock/decrypt a (provided) keyfile, and keyfile unlocking features in your program (can even be in combination with serial again for double check, but not directly linked anymore)

balazsszekely

  • Guest
Re: Store the value of Checkbox
« Reply #23 on: January 05, 2016, 05:58:53 pm »
@molly
Quote
Ok i apologize if my chosen words sounded perhaps too harsh.
Don't worry!

Quote
Yes, it is indeed a good idea, but i do believe 16 bits is too cramp to be able to realize that for all possible bit combinations.
My thoughts exactly! It might be possible though. I will try this and post the result.

Quote
Which brings me to my sleeve:
Let's say you have 4*2 character combinations, e.g. aA bB cC dD.
If odd(a) and even(B) and not odd(c) and odd(D) then set new bit 0
something randomly chosen but not all the same combination for new bits 1,2 and 3 ;-)
You have 16 bits to chose from.
This system would work very well, if I could replace the executable at client side. The new exe, would be able to detect the difference between the old/new serial type ...unfortunately that's not an option. The clients receive updates(new modules) through a plugin system and yes occasionally, on request, usually bug fix, the executable it also get replaced, but it could take a few years until all the clients(a few hundred) get a new version.

Anyway, I solved the problem by squeezing the extra data somewhere else in the serial. I was able to find some extra free space. I know it's a temporal solution and eventually, as new features are constantly developed, I will face the same problem again(or perhaps somebody else  >:D). At least I have some time to think about the ideal solution(if any).

@molly, @taazz thank you for your help
@x2nie I was wrong, you're a nice guy after all. I apologies and thank you for you help.

PS. This was my first and probably the last question on this forum. I like more to answer then to ask(10 times actually  :)).

shobits1

  • Sr. Member
  • ****
  • Posts: 271
  • .
Re: Store the value of Checkbox
« Reply #24 on: January 05, 2016, 06:58:12 pm »
if I understood it right:
you have 16 checkboxs and every checkbox is independent from others and can have any arbitrary value this mean you have 2^16 different states => you need at least 16bit or word type variable to hold all possible value.
now you want to add 4 new checkboxs, and if those new checkboxs are independent from the other 16 this mean you'll have 2^20  different states => you can't describe/store 2^20 in 16bits (unless there is relation between the bits - say at least each 5bits have a relation somehow.)

using compression won't help you either, you'll have to store a dictionary which surely will exceed the 16bit limit; one exception though, if you knew that those bits can always have some kind of pattern then you can hard code the dictionary and minimize the storage space required.

so to sum it up:
you can't store 20bits in 16bits space unless:
1- there are 4bits in relation with the other bits.
or
2- there is a constant known patterns to the generated bits, so you can hard code those pattern and use less bit to store them.
« Last Edit: January 05, 2016, 07:00:04 pm by shobits1 »

x2nie

  • Hero Member
  • *****
  • Posts: 515
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Store the value of Checkbox
« Reply #25 on: January 06, 2016, 03:48:54 am »

@shobits1 : +1 for you. I am glad you can describe things easily, It hard job for me with my limited english.

Anyway, I solved the problem by squeezing the extra data somewhere else in the serial. I was able to find some extra free space. I know it's a temporal solution and eventually, as new features are constantly developed, I will face the same problem again(or perhaps somebody else  >:D ). At least I have some time to think about the ideal solution(if any).
For honest, I see you as going to wrong direction by avoid extra char and use only hex [ '0'..'F' ]. Unless, you have hidden agenda. (and having hidden agenda is fine, thought).



"We cannot solve our problems with the same thinking we used when we created them." --Albert Einstein
So, let see your problem in different point of view.
1. you have had customers with distributed serial numbers.
2. this sn shall also applicable of your later new released software.
3. now you need to add more options for your sn, in the same time the old distributed sn also need to be supported.
4. new options being added, is only available for newer sn. old sn wouldn't be changed.


See?
I think the solution you need is accepting new char beyond 'F', it will always backward compatible (but not future compatible).
Meaning: new customer that has new sn shall not use old software, but old customer still able to use new software.
See?


Quote
PS. This was my first and probably the last question on this forum. I like more to answer then to ask(10 times actually  :) ).
Yeah, whatever. But there is no obligation for such that rule. somebody still can ask without answering/helping other.
I mean, don't hesitate to ask no mater you able to help other or not, just ask when you wanted.


When you were logged in, you can see attachments.
Lazarus Github @ UbuntuCinnamon-v22.04.1 + LinuxMintDebianEdition5

shobits1

  • Sr. Member
  • ****
  • Posts: 271
  • .
Re: Store the value of Checkbox
« Reply #26 on: January 06, 2016, 09:17:08 am »
I think the solution you need is accepting new char beyond 'F'

Sorry, but I don't understand how using char beyond 'F' would help minimize the storage space requirement.
meaning using the current implantation the word type can hold 4 hex converted to string you'll get chars '0000'...'FFFF'
every 1 char require only 4 bits; and to expand beyond the 'F' you'll need an other bit that's 5bits for every char => the total length of the serial number will be shortened to 3 chars instead of 4 not only that but you will also lose one bit (one checkbox state).

going beyond 'F' will only change the representation of the serial number but will not add any space to hold more than 16 bits (checkboxs) and even worse can lead to leave some bits unused.

x2nie

  • Hero Member
  • *****
  • Posts: 515
  • Impossible=I don't know the way
    • impossible is nothing - www.x2nie.com
Re: Store the value of Checkbox
« Reply #27 on: January 06, 2016, 09:57:38 am »
I think the solution you need is accepting new char beyond 'F'
...
going beyond 'F' will only change the representation of the serial number but will not add any space to hold more than 16 bits (checkboxs) and even worse can lead to leave some bits unused.


Are you sure you don't want to say the opposite?
Is [0000 .. FFFF] = [0000 .. ZZZZ] ?
When you were logged in, you can see attachments.
Lazarus Github @ UbuntuCinnamon-v22.04.1 + LinuxMintDebianEdition5

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: Store the value of Checkbox
« Reply #28 on: January 06, 2016, 10:15:24 am »
I think the solution you need is accepting new char beyond 'F'

Sorry, but I don't understand how using char beyond 'F' would help minimize the storage space requirement.
meaning using the current implantation the word type can hold 4 hex converted to string you'll get chars '0000'...'FFFF'
every 1 char require only 4 bits; and to expand beyond the 'F' you'll need an other bit that's 5bits for every char => the total length of the serial number will be shortened to 3 chars instead of 4 not only that but you will also lose one bit (one checkbox state).

going beyond 'F' will only change the representation of the serial number but will not add any space to hold more than 16 bits (checkboxs) and even worse can lead to leave some bits unused.
You confusing two different persistent mediums, 1 the integer number that the hex value represents which as you already said it needs 4bits to convert one hex char to number. 2 the hex char size tha represents that 4 bits which is a byte long. What people are saying here is to use some other base conversion than hex that will allow him to save more value in the same 2 chars eg a base 32 conversion (instead of 16) will allow him to save twice as much info in this 2 chars.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

avra

  • Hero Member
  • *****
  • Posts: 2586
    • Additional info
Re: Store the value of Checkbox
« Reply #29 on: January 06, 2016, 10:47:58 am »
What people are saying here is to use some other base conversion than hex that will allow him to save more value in the same 2 chars eg a base 32 conversion (instead of 16) will allow him to save twice as much info in this 2 chars.
2^32 <> (2 * 2^16)
2^17 = (2 * 2^16)
;-)
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

 

TinyPortal © 2005-2018