Type casting PBDLL5.0

[Dominic Mitchell]

Maybe I am missing something here, but nParam and CINT(LOWRD(lParam))
in the following code snippet should be identical.

    LOCAL nParam AS INTEGER
    LOCAL lParam AS LONG
  
    lParam = MAKLNG(&HFFFE, &H201)
    nParam = LOWRD(lParam)          ' redundant nParam = CINT(LOWRD(lParam))
    MsgBox FORMAT$(nParam) + CHR$(13) + FORMAT$(CINT(LOWRD(lParam)))
                    |__                           |___ 
                        -2 (INTEGER)                   65534 (WORD not INTEGER)

The following scenario left me scratching my head for half a day because of the above.

    CASE %WM_SETCURSOR
      ' If Windows generates an error when the window is clicked
      IF (CINT(LOWRD(lParam)) = %HTERROR) AND (HIWRD(lParam) = %WM_LBUTTONDOWN) THEN
        ' If the window is disabled
        IF ISFALSE IsWindowEnabled(hWnd) THEN
          SetWindowPos ghWndDesk, %HWND_TOP, 0, 0, 0, 0, %SWP_NOMOVE OR %SWP_NOSIZE
        END IF
      END IF

[This message has been edited by Dominic Mitchell (edited May 21, 2000).]

[Semen Matusovski]

originally posted by dominic mitchell:
maybe i am missing something

exactly http://www.powerbasic.com/support/pb...ead.php?t=2249

dominic --
if you are so brave to work without register none, you can use , for example, cvi(mkl$ / or cvi(mki$

<font face="courier new, courier" size="3"><pre>
#compile exe
function pbmain
local lparam as long
lparam = maklng(&hfffe, &hfffd)
msgbox str$(cvi(mkl$(lparam))) + $crlf + str$(cvi(mkl$(lparam), 3))
end function
[/CODE]



------------------

[Dominic Mitchell]

Semen,
You missed my point. The two posts are not about the same thing.
CINT(LOWRD(lParam)) <-- type casting seems to fail here
nHittest = LOWRD(lParam) <-- but works here (nHittest is an INTEGER)

By the way the default for by code is always $REGISTER NONE.

------------------

[Semen Matusovski]

By the way the default for by code is always $REGISTER NONE.
[/QUOTE]

Can't say about PB DLL 5.0, but 6.0' help talks that default is #REGISTER DEFAULT, which requests automatic allocations of integer variables in all cases, and extended precision floating point variables located in a Sub or Function which contains no reference to another Sub or Function.


------------------

[Lance Edmonds]

Dominic, if you read the help file, you'll see that to use CINT(), the target expression must be within the legal integer range. In your example, the LOWRD() was 65534, which is well outside the legal range of a 16-bit integer.
Quote from the help file:

In each case, numeric expression must be within the legal range for the type of variable being converted to.

When the value is outside the legal range, the results are "undefined". It is up to you, the programmer, to anticipate and handle these types of programming errors correctly.

FORMAT$ seems to treat all target expressions as signed, regardless of the variable class, so you were not seeing what what was really happening in your code.

You could try handling it something like this:

IF LOWRD(lParam) = BITS???(%HTERROR) AND HIWRD(lParam) = BITS???(%WM_LBUTTONDOWN) THEN...

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Dominic Mitchell]

Lance,
That method does not work for me. The method that worked as I mention before is the
automatic type casting of PBDLL. I was expecting CINT to work as in automatic assignment
WORD(0, 65535) -> INTEGER(-32768, +32767).


------------------

[Bob Zale]

Originally posted by Dominic Mitchell:
Lance,
That method does not work for me. The method that worked as I mention before is the
automatic type casting of PBDLL. I was expecting CINT to work as in automatic assignment
WORD(0, 65535) -> INTEGER(-32768, +32767).

In that case, you should use the BITS%() function, as that is it's purpose.

Bob Zale
PowerBASIC Inc.


------------------

[Dominic Mitchell]

Thanks for the reply Bob.
I could not get BITS% to work as advertised in the help file. For example,
lParam = 65534
BITS%(lParam) returns 65534 not -2 as expected. BITS% and BITS?? seem to be
returning the same values, very odd.

------------------

[Lance Edmonds]

We have recently confirmed that there is a problem with BITS%() when the value is outside of the range of an integer... argh! The remaining BITS() functions are unaffected.

This problem will be corrected in the next update to the compiler, but in the mean time, my earlier suggestion of using a UNION to perform signed/unsigned conversion should work perfectly.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Dominic Mitchell]

Thanks for the update on BITS Lance. I decided to use assembler to handle
the unsigned to signed conversion of the different data types. Its more elegant.



------------------