Bug #6607
OCX: Implement comparison of OCX object references with 0 (zero) integer
0%
History
#1 Updated by Vladimir Tsichevski almost 2 years ago
- Subject changed from OCX: Implement comparison of OCX widget references with 0 (zero) integer to OCX: Implement comparison of OCX object references with 0 (zero) integer
In OE, it is possible to test if an COM object is valid by comparing object references returned by COM calls with 0 (zero) integer value. Non-null value means reference is valid.
In FWD, such comparison always fails, since COM objects are not integers (they are either @handle@s or @comhandle@s).
I see two solutions for this problem:
- update the FWD comparison runtime function to let it handle this special case
- handle the problem at the conversion time: in this special case, and replace the 0 integer literal by the unknown literal
?
.
#2 Updated by Hynek Cihlar almost 2 years ago
Vladimir Tsichevski wrote:
In OE, it is possible to test if an COM object is valid by comparing object references returned by COM calls with 0 (zero) integer value. Non-null value means reference is valid.
In FWD, such comparison always fails, since COM objects are not integers (they are either @handle@s or @comhandle@s).
I see two solutions for this problem:
- update the FWD comparison runtime function to let it handle this special case
- handle the problem at the conversion time: in this special case, and replace the 0 integer literal by the unknown literal
?
.
What if a non-constant expression is used instead of 0? How about a non-zero number literal?
#3 Updated by Vladimir Tsichevski almost 2 years ago
Hynek Cihlar wrote:
Vladimir Tsichevski wrote:
In OE, it is possible to test if an COM object is valid by comparing object references returned by COM calls with 0 (zero) integer value. Non-null value means reference is valid.
In FWD, such comparison always fails, since COM objects are not integers (they are either @handle@s or @comhandle@s).
I see two solutions for this problem:
- update the FWD comparison runtime function to let it handle this special case
- handle the problem at the conversion time: in this special case, and replace the 0 integer literal by the unknown literal
?
.What if a non-constant expression is used instead of 0? How about a non-zero number literal?
In OCX, the zero comes from the C null pointer value, which is commonly used to denote "no value". Any other integer value is a C pointer, the value of which should not be interpreted by 4gl. I do not expect the value will ever be returned by expression, but we can emit convert-time warning in case a handle is compared with an expression returning integer.
#4 Updated by Hynek Cihlar almost 2 years ago
Vladimir Tsichevski wrote:
Hynek Cihlar wrote:
Vladimir Tsichevski wrote:
In OE, it is possible to test if an COM object is valid by comparing object references returned by COM calls with 0 (zero) integer value. Non-null value means reference is valid.
In FWD, such comparison always fails, since COM objects are not integers (they are either @handle@s or @comhandle@s).
I see two solutions for this problem:
- update the FWD comparison runtime function to let it handle this special case
- handle the problem at the conversion time: in this special case, and replace the 0 integer literal by the unknown literal
?
.What if a non-constant expression is used instead of 0? How about a non-zero number literal?
In OCX, the zero comes from the C null pointer value, which is commonly used to denote "no value". Any other integer value is a C pointer, the value of which should not be interpreted by 4gl. I do not expect the value will ever be returned by expression,
I agree this won't be a frequent pattern. But still if it is formally valid 4GL code we should conform to that. Greg, what do you think?
#5 Updated by Greg Shah almost 2 years ago
But still if it is formally valid 4GL code we should conform to that.
Yes, let's solve this once.