IT-Consultant: José Roca (PBWIN 10+/PBCC 6+) (Archive only) > Windows API Headers

Using API Headers

(1/4) > >>

Gary Beene:
Jose,

Have you written an introduction to your headers?  I have a copy of the Help file, but it's more of a reference document. 

For example, to use the headers, what #Include statement do I use. Is there a "top level" #Include that will then incorporate all of the other *.inc files?  Or do I have to individually select which of your include files to incorporate, based on the requirements of each app?

Have I missed where on your site I should read for such summary information?

If I put both your includes and those from PowerBASIC into the Options/Compiler section of PBEdit, does the order matter (assuming that the "top level" includes are different)?  Is there a specific action I must take to avoid mixing the two sets of include files?

I think I know the answers to some of the questions I've asked, but I seem to have missed where I could have read the answers myself.

Gary Beene:
Hi Jose,

Along the same line of questioning ...

On the assumption that "win32api.inc" is the top level include for your API headers, can I rename it "jose_win32api.inc" without affecting anything?

If so, then I can tell at a glance which set of includes my app expects.

And if I do that, and keep both paths in the PB IDE compiler paths section, will there be no chance of mixing files between the two sets?

Paul Elliott:
Gary,

Why not make your own inc with that name and just include Jose's main include?
That way any updates will not change your file and you will always get the right include.

José Roca:
The main file to include is "windows.inc", but you ca also use "win32api.inc", which is a stub file that simply calls "windows.inc". "windows.inc" already includes the most often needed other includes. For the others, you need to add #include <something> manually. Of course, as suggested by Paul, you can create a stub file that begins with #include "windows.inc", followed with other files of you interest. Mind you, there are more than 1.800 files. If "windows.inc" included all of them, it will take forever to compile even the tiniest program. PB is quite fast, but parsing more than 70 MB... To know which file to add for a particular wrapper, the name of the include file is listed at the end of the page for the function of the help file. For the Windows API functions, it is listed in the MSD documentation. I use the same names, except mine have an .inc extension whereas the C++ headers use the .h extension.


--- Quote ---On the assumption that "win32api.inc" is the top level include for your API headers, can I rename it "jose_win32api.inc" without affecting anything?

--- End quote ---

This particular one, yes, because it is simply an stub file and it is not included by any other file, but don't rename any of the others or you will get file not found errors.


--- Quote ---If I put both your includes and those from PowerBASIC into the Options/Compiler section of PBEdit, does the order matter (assuming that the "top level" includes are different)?  Is there a specific action I must take to avoid mixing the two sets of include files?

--- End quote ---

They can't b mixed, or you will get conflicts.

BTW I'm working in version III of my headers in which I'm using the constant %USEPBDECL to allow people that has already code written using the PB headers for PB10 to compile them with my headers, if they need to use the additional functionality that they provide, by simply adding #DEFINE %USEPBDECL = 1 at the top of the program, before any #INCLUDEs.

For example:


--- Code: ---#IF %DEF(%USEPBDECL)
DECLARE FUNCTION URLDownloadToFileA LIB "UrlMon.dll" _
    ALIAS "URLDownloadToFileA" ( _
    BYVAL pCaller    AS DWORD, _
    szURL            AS ASCIIZ, _
    szFileName       AS ASCIIZ, _
    BYVAL dwReserved AS DWORD, _
    BYVAL lpfnCB     AS DWORD) AS LONG
#ELSE
DECLARE FUNCTION URLDownloadToFileA IMPORT "URLMON.DLL" ALIAS "URLDownloadToFileA" ( _
   BYVAL pCaller AS IUnknown _                          ' __in LPUNKNOWN pCaller
 , BYREF szURL AS ASCIIZ _                              ' __in LPCSTR szURL
 , BYREF szFileName AS ASCIIZ _                         ' __in LPCSTR szFileName
 , BYVAL dwReserved AS DWORD _                          ' __in DWORD dwReserved
 , BYVAL lpfnCB AS IBindStatusCallback _                ' __in LPBINDSTATUSCALLBACK lpfnCB
 ) AS LONG                                              ' HRESULT
#ENDIF

--- End code ---

PB is using DWORD instead of IUnknown and IBindStatusCallback because his includes have not inerface declarations, although in this case they could have used IUnknown inestead of DWORD.

I'm trying to minimize differences as much as I can.

For example, I was using:


--- Code: ---' // Size = 18 bytes
TYPE NAME_BUFFER BYTE
   name       AS STRING * %NCBNAMSZ   ' UCHAR   name[NCBNAMSZ]
   name_num   AS BYTE                 ' UCHAR   name_num
   name_flags AS BYTE                 ' UCHAR   name_flags
END TYPE

--- End code ---

and PB uses:


--- Code: ---' // Size = 18 bytes
TYPE NAME_BUFFER BYTE
   sname      AS STRING * %NCBNAMSZ   ' UCHAR   name[NCBNAMSZ]
   name_num   AS BYTE                 ' UCHAR   name_num
   name_flags AS BYTE                 ' UCHAR   name_flags
END TYPE

--- End code ---

Now, I'm using:


--- Code: ---UNION NAME_BUFFER_NAME_UNION BYTE
   name       AS STRING * %NCBNAMSZ   ' UCHAR   name[NCBNAMSZ]
   ' // For compatibility with PB includes
   sname      AS STRING * %NCBNAMSZ   ' UCHAR   name[NCBNAMSZ]
END UNION
' // Size = 18 bytes
TYPE NAME_BUFFER BYTE
   NAME_BUFFER_NAME_UNION
   name_num   AS BYTE                 ' UCHAR   name_num
   name_flags AS BYTE                 ' UCHAR   name_flags
END TYPE

--- End code ---

which allows to use both name and sname.

Of course, there are many irreconciliable differences that could only be solved by agreeing in which one is the most convenient to use and being adopted by both sets of includes.

There is also the problem that a good number of structures declared in the PB files are not properly aligned. I have checked each and every one of the near 8.000 structures included in my headers with the results given by the Visual C++ compiler, and ajusted them accordingly. So I'm confident that almost all (there is always room for errors) are correct.

Comparing the two sets is also allowing me to correct some minor mistakes in my headers.

Gary Beene:
Jose/Paul,
Thank you for the responses/suggestions.

I plan to go with renaming Jose's "win32api.inc" to "jose_win32api.inc".  I like avoiding having two files of the same name, and I like the visual clarification of which includes I'm using.  I can see, however, why Jose has the "win32api.inc" stub file - to prevent the need to change code when using different includes. In my case, I'm happy to have that constriction in order to clarify for myself which includes I used to develop/test the code.

But, I'm still not clear on this point:

--- Quote ---They can't be mixed, or you will get conflicts.
--- End quote ---
Is putting the two paths into the PBEdit Options section the same as "mixing" them? 

I would think it should not, as long as none of the respective includes are complete and have no missing, reference includes.

But, I can see that the mixing could occur if the first path (say, PB) was missing an expected include file and PBEdit then went to the 2nd path (where Jose's includes were placed) and found an include of the same name but not compatible with the PB includes.

Does this correctly describe how "mixing" would occur if both paths are placed in the PBEdit settings?

If so, then the correct approach seems to be to place only 1 path in the PBEdit settings, and completely replace it if I want to use the other set of includes.

Is this correct?

Navigation

[0] Message Index

[#] Next page

Go to full version