HttpFilterProc C++ declaration conversion to PowerBASIC

[Scott Wolfington]

Here is the C++ declaration.

DWORD WINAPI HttpFilterProc(
  PHTTP_FILTER_CONTEXT pfc,
  DWORD notificationType,
  LPVOID pvNotification
);

Possible PowerBASIC conversion?

FUNCTION HttpFilterProc ALIAS "HttpFilterProc" (
         pfc AS HTTP_FILTER_CONTEXT PTR, _
         BYVAL NotificationType AS DWORD, _
         pvNotification AS DWORD PTR ) EXPORT AS DWORD

Also, what does a C++ PVOID data type convert to in PowerBASIC?

Thanks for any help you can offer.

Regards,
Scott

------------------
Scott Wolfington
http://www.boogietools.com



[This message has been edited by Scott Wolfington (edited September 15, 2004).]

[Richard Angell]

From the help file, C/C++ defined types (SDK types):
LPVOID 32-bit pointer (ANY) [PTR]

Looks like you are on the right track.

------------------
Rick Angell

[Scott Wolfington]

Thanks Richard. Is an LPVOID the same as a PVOID? I'm treating them the same for now. Also, do I really need the ByVal in front of the NotificationType variable (I saw that suggestion in another post)?

Regards,
Scott


------------------
Scott Wolfington
http://www.boogietools.com

[Richard Angell]

Scott,

Both are generic pointers to undefined datatypes (or functions), however one of the C/C++ gurus should have a better explanation of any differences than I have found.

------------------
Rick Angell

[Tom Hanlin]

pvNotification is a pointer to a variable of one of a variety of data types.
I'd probably be inclined to define it as "pbNotification AS ANY", although
"BYVAL pbNotification AS DWORD" is also a reasonable fit.

The LP prefix indicates "Long Pointer", meaning "far pointer", which is a
leftover from 16-bit code. All pointers are the same size in 32-bit Windows.
LPVOID = PVOID.

Yes, you need the BYVAL in front of notificationType. Parameters in C are always
passed BYVAL. The way you pass BYREF, in C, is simply to pass a BYVAL pointer
to the item.

------------------
Tom Hanlin, PowerBASIC Staff
Opinions expressed may not be those of my employer or myself

[Scott Wolfington]

Thanks Tom. I get an error message when I try compiling with "pvNotification AS ANY". It says "undefined TYPE". ??

Scott



------------------
Scott Wolfington
http://www.boogietools.com

[Scott Wolfington]

Here's another related question...

Link To MS Website: http://msdn.microsoft.com/library/de...er_context.asp

Here is the TYPE declaration of the pfc variable that gets passed into the function above. Which conversion looks more accurate?

C++ Version
-----------

typedef struct _HTTP_FILTER_CONTEXT {  
   DWORD cbSize;  
   DWORD Revision;  
   PVOID ServerContext;  
   DWORD ulReserved;  
   BOOL fIsSecurePort;  
   PVOID pFilterContext;   
   BOOL GetServerVariable;  
   BOOL AddResponseHeaders;  
   BOOL WriteClient;  
   VOID * AllocMem;  
   BOOL ServerSupportFunction;
} HTTP_FILTER_CONTEXT, * PHTTP_FILTER_CONTEX;

Saw the conversion below in another post on the forum.

TYPE HTTP_FILTER_CONTEXT
     cbSize                     AS DWORD
     Revision                   AS DWORD ' 
     ServerContext              AS DWORD ' PVOID  
     ulReserved                 AS DWORD ' TRUE   
     fIsSecurePort              AS DWORD ' BOOL   
     pFilterContext             AS DWORD ' PVOID
     lpGetServerVariable        AS DWORD ' BOOLS
     lpAddResponseHeaders       AS DWORD ' BOOLS
     lpWriteClient              AS DWORD ' BOOLS
     lpAllocMem                 AS DWORD ' BOOLS
     lpServerSupportFunction    AS DWORD ' BOOLS
END TYPE                                           '

But, doesn't this one seem more correct? Does it matter?

Type HTTP_FILTER_CONTEXT
     cbSize                     As DWORD
     Revision                   As DWORD    
     ServerContext              As LONG     ' PVOID  
     ulReserved                 As DWORD    ' TRUE   
     fIsSecurePort              As LONG     ' BOOL   
     pFilterContext             As LONG     ' PVOID
     GetServerVariable          As LONG     ' BOOLS
     AddResponseHeaders         As LONG     ' BOOLS
     WriteClient                As LONG     ' BOOLS
     AllocMem                   As LONG     ' BOOLS
     ServerSupportFunction      As LONG     ' BOOLS
End Type

------------------
Scott Wolfington
http://www.boogietools.com



[This message has been edited by Scott Wolfington (edited September 16, 2004).]

[William Burns]

Scott, it will not matter which you use because the outside program that is passing the data will have its own data structure to overlay the data, so the outside program does not know or care about the difference of Long verses Dword in your program. (since LONGs and DWORDs are both 32 bit variables) However if you are doing comparisions on the data, obiously it does matter to your program, but as long as your program is setup correctly to consitantly treat that field the same, it should not matter.

But I do think several of those fields you listed as Longs would make more sense as Dwords because they are pointers. Longs will work for pointers as well, but it might be confusing to think of some of the highest addresses as negitive numbers...


------------------
"I haven't lost my mind... its backed up on tape... I think??"

[This message has been edited by William Burns (edited September 16, 2004).]

[Scott Wolfington]

Thanks William. I'll keep them at DWORDS then. Hopefully I can get this function to work properly.

Regards,
Scott



------------------
Scott Wolfington
http://www.boogietools.com

[Richard Angell]

You probably noted that some of these are function pointers, and for
that reason sticking to DWORD for those would let you have more readable
code in testing such, if you need to write them, with CALL DWORD.

Personally, I would stick with the DWORD too.

------------------
Rick Angell

[Tom Hanlin]

BOOL is most accurately translated as LONG but, it doesn't much matter.

AS ANY is only for DECLARES. If you're creating the function in PB,
use BYVAL xxx AS DWORD to receive the resulting pointer.

------------------
Tom Hanlin, PowerBASIC Staff
Opinions expressed may not be those of my employer or myself