Announcement

Collapse
No announcement yet.

Win32Api.inc error

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael Mattias
    replied
    My point is the same one i've been trying to make for years: There is no such thing as a "word for word" or "verb for verb" or "function for function" interchange between different computer languages, and that the best way to effect a port is to engage one's brain instead of trying to find an easy glide path in some set of table data.

    The LONG/DWORD thing is complicated by the fact that in PB/DLL versions thru 6x, LONG and DWORD comparisons using IF or SELECT CASE were 32-bit comparisons; in 7x those comparisons changed to signed comparisions. (ie., what used to work did so no more). (FWIW, SELECT CASE AS LONG still does 32-bit comparisons).

    e.g, in your example above: Windows is documented to an integer of value 0xFFFFFFFF; you may either use a PB DWORD and compare against &hFFFFFFFF???, or a PB LONG and compare against -1&. Either is correct; neither is wrong.

    MCM

    Leave a comment:


  • Kev Peel
    replied
    Originally posted by Michael Mattias View Post
    The original SDK code shows a DWORD (unsigned double-word) should be used when coding in 'C'.

    And while I have exactly zero examples, I would swear on a stack of Bibles there are portions of the SDK documentation which assume you are using a Microsoft-brand 'C' compiler.

    Far better IMO to use any 'code' provided in the MS-Documentation as a secondary source of info, instead relying on the text descriptions of parameters and return values.
    No, it means that an unsigned double word should be used if the compiler supports it. I am simply perplexed at why this is so hard for you to understand.

    As for LONG vs DWORD, one example is that INVALID_FILE_ATTRIBUTES is "FFFFFFFF". Try and squat that into a LONG and equality tests go out the window.

    Leave a comment:


  • Roger Garstang
    replied
    I'm still confused why there is a claim that a <> compare will fail when comparing a LONG and a DWORD. < or > by themselves would fail since DWORD wouldn't be negative or a HIGH DWORD would be a negative value to a LONG, but <> should work fine...or am I missing something here?

    Leave a comment:


  • Michael Mattias
    replied
    The original SDK code shows a DWORD (unsigned double-word) should be used...
    The original SDK code shows a DWORD (unsigned double-word) should be used when coding in 'C'.

    And while I have exactly zero examples, I would swear on a stack of Bibles there are portions of the SDK documentation which assume you are using a Microsoft-brand 'C' compiler.

    Far better IMO to use any 'code' provided in the MS-Documentation as a secondary source of info, instead relying on the text descriptions of parameters and return values.

    Leave a comment:


  • Richard Angell
    replied
    Both

    Sending it to PB makes sure that it gets attention there.

    Posting it here as well gets more comment and work-around options that can help to deal with the situation one believes is incorrect. Of course to ilusrate why one believes it is incorrect, the official MS SDK documentation online could be linked both here and in the e-mail.

    Leave a comment:


  • Theo Gottwald
    replied
    Whats the normal and best way with these things?
    Sent it to the PB-Support via E-Mail or post it here?

    Leave a comment:


  • Aleksandr Dobrev
    replied
    BTW, this APIs should be corrected too

    wrong:
    Code:
    DECLARE FUNCTION GetCompressedFileSize LIB "KERNEL32.DLL" ALIAS "GetCompressedFileSizeA" (lpFileName AS ASCIIZ, lpFileSizeHigh AS LONG) AS LONG
    
    DECLARE FUNCTION GetFileSize LIB "KERNEL32.DLL" ALIAS "GetFileSize" (BYVAL hFile AS DWORD, lpFileSizeHigh AS LONG) AS LONG
    
    
    DECLARE FUNCTION GetMenuItemID LIB "USER32.DLL" ALIAS "GetMenuItemID" (BYVAL hMenu AS DWORD, BYVAL nPos AS LONG) AS LONG
    
    
    DECLARE FUNCTION ResumeThread LIB "KERNEL32.DLL" ALIAS "ResumeThread" (BYVAL hThread AS DWORD) AS LONG
    
    DECLARE FUNCTION SetFilePointer LIB "KERNEL32.DLL" ALIAS "SetFilePointer" (BYVAL hFile AS DWORD, BYVAL lDistanceToMove AS LONG, lpDistanceToMoveHigh AS LONG, BYVAL dwMoveMethod AS DWORD) AS LONG
    
    DECLARE FUNCTION SuspendThread LIB "KERNEL32.DLL" ALIAS "SuspendThread" (BYVAL hThread AS DWORD) AS LONG
    
    DECLARE FUNCTION TlsAlloc LIB "KERNEL32.DLL" ALIAS "TlsAlloc" () AS LONG
    should be:

    Code:
    DECLARE FUNCTION GetCompressedFileSize LIB "KERNEL32.DLL" ALIAS "GetCompressedFileSizeA" (lpFileName AS ASCIIZ, lpFileSizeHigh AS LONG) AS DWORD
    
    
    DECLARE FUNCTION GetFileSize LIB "KERNEL32.DLL" ALIAS "GetFileSize" (BYVAL hFile AS DWORD, lpFileSizeHigh AS LONG) AS DWORD
    
    DECLARE FUNCTION GetMenuItemID LIB "USER32.DLL" ALIAS "GetMenuItemID" (BYVAL hMenu AS DWORD, BYVAL nPos AS LONG) AS DWORD
    
    
    DECLARE FUNCTION ResumeThread LIB "KERNEL32.DLL" ALIAS "ResumeThread" (BYVAL hThread AS DWORD) AS DWORD
    
    DECLARE FUNCTION SetFilePointer LIB "KERNEL32.DLL" ALIAS "SetFilePointer" (BYVAL hFile AS DWORD, BYVAL lDistanceToMove AS LONG, lpDistanceToMoveHigh AS LONG, BYVAL dwMoveMethod AS DWORD) AS DWORD
    
    DECLARE FUNCTION SuspendThread LIB "KERNEL32.DLL" ALIAS "SuspendThread" (BYVAL hThread AS DWORD) AS DWORD
    
    DECLARE FUNCTION TlsAlloc LIB "KERNEL32.DLL" ALIAS "TlsAlloc" () AS DWORD

    Leave a comment:


  • Kev Peel
    replied
    Not sure what the argument is here?

    The original SDK code shows a DWORD (unsigned double-word) should be used. Since the constants were recently updated to DWORDs, so should the PB translations of function prototypes. Note we are talking about function return values, and not parameters, where it doesn't matter if a DWORD or LONG is used.

    Your code is simply a workaround to a fundamental issue with the PB translations. I, and probably others, simply would like to see it fixed one day, though I expect it would be a huge undertaking with a whopping 3 MB of definition files to sift through.

    Last edited by Kev Peel; 24 Oct 2007, 01:59 PM.

    Leave a comment:


  • Michael Mattias
    replied
    >According to the Win32 docs,

    You found Win32API docs with the examples in PowerBASIC syntax?

    Where?

    (See also: This whine's time has come)

    MCM

    Leave a comment:


  • Kev Peel
    replied
    > Is the return type of the function wrong?

    According to the Win32 docs, yes it is.

    Leave a comment:


  • Michael Mattias
    replied
    Is the return type of the function wrong?

    Or is the explicit casting to DWORD of the INVALID_FILE_ATTRIBUTES constant wrong?

    Actually, neither is "wrong;" they are however "incompatible."

    FWIW I gave up on doing 'raw' equality tests with anything in the supplied Windows headers files precisely because of the willy-nilly "let's make all LONGs DWORDs 'upgrade' " in those files a couple of years ago. I 'd use...
    Code:
    ' compare long with DWORD
    MACRO EQ32(a,b) = (BITS???(a)=BITS???(b))
    
       IF Eq32(GetFileAttributes(szfile), %INVALID_FILE_ATTRIBUTES) THEN ...

    Leave a comment:


  • Dominic Mitchell
    started a topic Win32Api.inc error

    Win32Api.inc error

    The return type in this defintion is wrong
    Code:
    DECLARE FUNCTION GetFileAttributes LIB "KERNEL32.DLL" ALIAS "GetFileAttributesA" (lpFileName AS ASCIIZ) AS LONG
    It should be
    Code:
    DECLARE FUNCTION GetFileAttributes LIB "KERNEL32.DLL" ALIAS "GetFileAttributesA" (lpFileName AS ASCIIZ) AS DWORD
    The current defintion causes code like the following to fail
    Code:
    IF GetFileAttributes(szFile) <> %INVALID_FILE_ATTRIBUTES THEN
Working...
X