Boolean values

, , ,
1

Imported from previous forum

2

There seemed to have been a discussion of Boolean types that require providing values other then Y/N.

http://www.fixprotocol.org/discuss/read/7118a889

I have a very simple question.

Is there a way to implement a boolean type Tag using a CheckBox Control alone if the wire value will have to be something other then Y/N?

3

There seemed to have been a discussion of Boolean types that require providing values other then Y/N.

http://www.fixprotocol.org/discuss/read/7118a889

I have a very simple question.

Is there a way to implement a boolean type Tag using a CheckBox Control alone if the wire value will have to be something other then Y/N?

Mikhail,

Thanks for the question. Indeed we had a lot of discussion at FIXatdl around the boolean type.

We made a clear distinction in FIXatdl between “on the wire” (strict adherence to FIX Protocol defined data types) and “on the UI” (more flexible to accommodate everything we found actually being used out there).

In the check box area we did look at tri-state - (yes, no, null) with “null” loosely defined. Typically “null” meant “No answer”. It was conveyed as gray or with opacity, or something like (empty/blank | green check-mark | red “X”)

Use-case example: search a list of used cars. Check box to limit if the car has a sunroof?
empty: show all cars
green check-mark: Only show cars WITH a sunroof
red “X”: Only show cars WITHOUT a sunroof

On the wire the variable might be:
True
False
[variable not sent]

If you can provide a specific use-case or two we may have guys who can pin things down for you.

Rick

4

There seemed to have been a discussion of Boolean types that require providing values other then Y/N.

http://www.fixprotocol.org/discuss/read/7118a889

I have a very simple question.

Is there a way to implement a boolean type Tag using a CheckBox Control alone if the wire value will have to be something other then Y/N?

Mikhail,

Thanks for the question. Indeed we had a lot of discussion at FIXatdl around the boolean type.

We made a clear distinction in FIXatdl between “on the wire” (strict adherence to FIX Protocol defined data types) and “on the UI” (more flexible to accommodate everything we found actually being used out there).

In the check box area we did look at tri-state - (yes, no, null) with “null” loosely defined. Typically “null” meant “No answer”. It was conveyed as gray or with opacity, or something like (empty/blank | green check-mark | red “X”)

Use-case example: search a list of used cars. Check box to limit if the car has a sunroof?
empty: show all cars
green check-mark: Only show cars WITH a sunroof
red “X”: Only show cars WITHOUT a sunroof

On the wire the variable might be:
True
False
[variable not sent]

If you can provide a specific use-case or two we may have guys who can pin things down for you.

Rick

Rick,

The use case is pretty simple let’s say that I have a tag for the algo(12345) which if set will allow the algo execution to use Dark Pools.

The valid values for this tags are: 0(default) and 1 with obvious meaning of 0 = No, and 1 = Yes.

So the most common sense and direct UI implementation of this setting would be a checkbox with a Boolean Parameter attached to it. However, if the underlying parameter is Boolean_t the only values for this tag I was able to produce were Y and N.

5

There seemed to have been a discussion of Boolean types that require providing values other then Y/N.

http://www.fixprotocol.org/discuss/read/7118a889

I have a very simple question.

Is there a way to implement a boolean type Tag using a CheckBox Control alone if the wire value will have to be something other then Y/N?

Mikhail,

Thanks for the question. Indeed we had a lot of discussion at FIXatdl around the boolean type.

We made a clear distinction in FIXatdl between “on the wire” (strict adherence to FIX Protocol defined data types) and “on the UI” (more flexible to accommodate everything we found actually being used out there).

In the check box area we did look at tri-state - (yes, no, null) with “null” loosely defined. Typically “null” meant “No answer”. It was conveyed as gray or with opacity, or something like (empty/blank | green check-mark | red “X”)

Use-case example: search a list of used cars. Check box to limit if the car has a sunroof?
empty: show all cars
green check-mark: Only show cars WITH a sunroof
red “X”: Only show cars WITHOUT a sunroof

On the wire the variable might be:
True
False
[variable not sent]

If you can provide a specific use-case or two we may have guys who can pin things down for you.

Rick

Rick,

The use case is pretty simple let’s say that I have a tag for the algo(12345) which if set will allow the algo execution to use Dark Pools.

The valid values for this tags are: 0(default) and 1 with obvious meaning of 0 = No, and 1 = Yes.

So the most common sense and direct UI implementation of this setting would be a checkbox with a Boolean Parameter attached to it. However, if the underlying parameter is Boolean_t the only values for this tag I was able to produce were Y and N.

I found an answer to my own question. Thank you.

Regards,

Mikhail