Project

General

Profile

Bug #6607

OCX: Implement comparison of OCX object references with 0 (zero) integer

Added by Vladimir Tsichevski almost 2 years ago. Updated almost 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:

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:

  1. update the FWD comparison runtime function to let it handle this special case
  2. 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:

  1. update the FWD comparison runtime function to let it handle this special case
  2. 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:

  1. update the FWD comparison runtime function to let it handle this special case
  2. 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:

  1. update the FWD comparison runtime function to let it handle this special case
  2. 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.

Also available in: Atom PDF