Very clever, no doubt, thanks for taking the time to explain it to me.

But we are far from the ease of use of Codemine or better .NET WinForms. Why use bits for a functionnality that will change the position of at most 100 controls on a form ? I think even 486 can do it fast without using bits. And it's even probable that the speed of the video card is more important than the efficiency of the code.

>
>Tell us about your 8 bit solution. I don't think it matters that much to have 10 or 8 bits, but I'm curious about your solution.
>
>
>You have to observe that the valid values of Anchor are 100:
>

>10 Horizontals X 10 Vertical.
>

>
>Now you apply Shannon theory and 7 bits are sufficients.
>
>But because any Axis have two sides,
>a redundant but structured syntax require 2 bits for any sides.
>Now the solution is simple to found.
>

>bits 0..3 V axis -> bits 0,1 Top  bits 2,3 Bottom
>bits 4..7 H axis -> bits 4,5 Left bits 6,7 Right
>

>If you observe the David BuildAnchor OptionGroup and two checkbox for
>"H/V Center Relative" ( values 256,512 ) you see these bits grouping.
>( VFP9 Hor/Vertical Fixed Size are mistaken definitions because
>Anchor = 1 is a Vertical Fixed Size also, etc ... )
>
>Example:
>

>1            is "Top Absolute" = VFP9 1
>2            is "Top Relative" = VFP9 16
>3+3*4 = 0x0F is "Vertical Center Relative" = VFP9 512
>...
>

>
>With this choice you have removed all mutual conflicts,
>and a Hex rapresentation is more readable.
>
>You can remember all VFP9 conflicting combinations ? No
>
>With this you remember this,
>every couple of bits relative to a side can have values 0,1,2; and for every axis you can set the value 15 ( all bits ). Stop
>
>
>If you want increment the number of sides anchor positions you increment
>the bits for sides.
>
>Now i use a 4 bits per sides on my VFP8 anchor implementation,
>with more options,
>and then i wish a 4 or 8 bits per sides on VFP9 anchor.
>
>Fabio