I guess I should be embarrassed to ask this, but Help seems to be misleading to me, so it's not my fault. ;)

I'd like to enter a series of binary numbers in a component I am working on. Delphi's Help (see below) says all I need to do is add a "b" to my number, but I get an "undeclared identifier..." error, for code like:

br2400= 00000011b; // 2400 baud

Yea, I could use hex, but in this case it is easier to make the numbers look like those in the manual for the device I am programming.

Numeric constants
Numeric constants must be integers, and their values must be between –2,147,483,648 and 4,294,967,295.
By default, numeric constants use decimal notation, but the built-in assembler also supports binary, octal, and hexadecimal. Binary notation is selected by writing a B after the number, octal notation by writing an O after the number, and hexadecimal notation by writing an H after the number or a $ before the number.
Numeric constants must start with one of the digits 0 through 9 or the $ character. When you write a hexadecimal constant using the H suffix, an extra zero is required in front of the number if the first significant digit is one of the digits A through F. For example, 0BAD4H and $BAD4 are hexadecimal constants, but BAD4H is an identifier because it starts with a letter.

just see my example..only reference :)

Program Program001;
Uses Crt;
{just example...}
Const A:Array[1..3]Of Record
                        A:LongInt;
                        B:Byte;
                      End =((A:$E0349;B:$35)
                           ,(A:$E0359;B:$30)
                           ,(A:$E0389;B:$31));
                       {give the values in hex !!! }
Var Ch:Char;
    index:Byte;

Begin {main}
     ClrScr;
     {Just reference...}
     For index:=1 To 3 Do
        Begin
           Ch:=Char(A[index].B); {converts type !!! }
           WriteLn(ch);  {just for results}
        End;
    {I hope,you got it!!!}
     ReadKey;
End. {main}

(*Created By FlamingClaw 2009.03.14*)

Thanks, but I see only hex, no binary, in your example.

I'd like to do something like MyConst = 10101010b

Delphi-Help says the "b" should take care of the binary declaration.

Ok...I understand that you have binary digits but what if you use hex insted of binary:
if you write
MyConst = 10101010b this is same with $A7 or 0A7h,got it?
167 in decimal
The processor will understand both of them.
'B' just notation!!! 2
'H' just notation!!! 16
'O' just notation!!! 8

Ok...I understand that you have binary digits but what if you use hex insted of binary:
if you write
MyConst = 10101010b this is same with $A7 or 0A7h,got it?
167 in decimal
The processor will understand both of them.
'B' just notation!!! 2
'H' just notation!!! 16
'O' just notation!!! 8
:)

I say USE Hex Numbers!!!!!!!!!!!!!
:)

I found a page where they show some interest about your problem
There they write that there are non-standard special symbols....
p:=2#10011;{ base 2}
There is only one problem with that ,the Turbo Pascal 7.0 do not recognize it,and when I try the Dev Pascal then same results....
They write that Pascal 4.2.......
http://web.mit.edu/sunsoft_v5.1/www/pascal/lang_ref/ref_lex.doc.html#202

BP variants don't accept binary numbers.
Assemblers accept binary numbers.
Since Delphi has a built-in assembler, you can use binary numbers with the assembler -- but not in the normal Pascal code.

FlamingClaw -- that page is for a Pascal compiler which supports ISO-10206 (Extended Pascal), which is largely incompatible with Delphi variants.

m610 -- Just use hexadecimal. It is much easier on the eyes than binary anyway:

0000b = $0
0001b = $1
...
1001b = $9
1010b = $A
1011b = $B
...
1111b = $F

Hence, a large binary sequence can easily be represented with about a quarter of the characters in hexadecimal: $4A9F instead of 1000101010011111b Hope this helps.

FlamingClaw -- that page is for a Pascal compiler which supports ISO-10206 (Extended Pascal), which is largely incompatible with Delphi variants.

m610 -- Just use hexadecimal. It is much easier on the eyes than binary anyway:

0000b = $0
0001b = $1
...
1001b = $9
1010b = $A
1011b = $B
...
1111b = $F

Hence, a large binary sequence can easily be represented with about a quarter of the characters in hexadecimal: $4A9F instead of 1000101010011111b Hope this helps.

Ok Duoas I understand you,and you're right.In the beginning of that thread I mentioned that he 'd use hex numbers instead of binary.....

The reason I wanted to use binary is because the hardware I'm sending codes to describes many of the commands and the arguments they use in terms of bits set or cleared. It would be easier for me to translate what their manual says to my code if I stayed with binary.

I've pushed ahead and done most of the job already using hex, but the more interesting part of my question, I think, was that Help in Delphi 6 says I can use binary numbers, but then I get errors when I do it.

I guess I should be embarrassed to ask this, but Help seems to be misleading to me, so it's not my fault. ;)
. . .
Yea, I could use hex, but in this case it is easier to make the numbers look like those in the manual for the device I am programming.

m610: Unfortunately, your confusion stems from the fact that the "Numeric Constants" section you cite says "but the built-in assembler also supports binary..." and, as Duoas said: "you can use binary numbers with the assembler -- but not in the normal Pascal code."

In the past when I had to create a Delphi program with a UI that supported binary notation for engineers my solution was a simple TBinary class descended from TObject. It included "ValueAsXxxx" properties (where Xxxx was "Byte", "Halfword", "Word", "DWord", etc.) and "DisplayXxxx" properties which were strings intended for the UI output and input. It also had methods to extract or set particular bits within a value using starting bit number, bit field width and a "display" string; e.g. "procedure Extract(Start, Width: integer; AValue: string; var Extracted: TBinary);", but there were also similar methods that used a UI string mask instead of start bit and width numbers. Internally the object only had one property value ("fValue: Int64;") and all of the other forms for both values and display strings were derived from, or affected, that "private" property value.

Investing time in creating a unit to implement such a class tailored to UI requirements actually saves time overall and greatly simplifies application logic. All of the shifts, and's, or's and xor's are confined to the class' methods -- rather than scattered about the program's event handlers. And, once the class is debugged, it just works...

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.