Jose,
I use Socket Tools by Catalyst and their seems to be conflicts that I am
not able to figure out how to fix. I ran across this statement and wonder
if you can comment.
"The Catalyst Website talks about NOT linking with the Microsoft WinSock API
routines because of duplicate function names. It appears that the Jose
Roca's includes use the Microsoft Winsock API and do get included in a
compile with FF 3.5."
http://forums.catalyst.com/viewtopic.php?f=3&t=1463
http://www.catalyst.com/
I only need Socket Tools for the ability to use FTPS and HTTPS file upload and download protochol.
Do you have any suggestion for alternate FTPS and HTTPS tools?
If you don't want to include WinSock, then add %WIN32_LEAN_AND_MEAN = 1 before any #INCLUDE.
José,
Thanks for the suggestion but I am not having much success.
I keep running into conflict type error messages. Try to fix one and
then get a different error message.
I created a very simple FF35 project that just opens a form.
It just includes the Catalyst SocketTools include files.
This is asking a lot, but could you take a look and see if the
SocketTools Include can somehow be made compatible with
your API files. I am at a lost to know what to do. I am hoping
you can spot a simple solution.
Attached is the FF35 project and the SocketTools Include files.
And a screen print of the last error message.
Well, you asked for a way of not including WinSock, based in I don't know which rumours...
Remove %WIN32_Lean_And_Mean = 1 and rem
'TYPE SYSTEMTIME
' wYear AS WORD
' wMonth AS WORD
' wDayOfWeek AS WORD
' wDay AS WORD
' wHour AS WORD
' wMinute AS WORD
' wSecond AS WORD
' wMilliseconds AS WORD
'END TYPE
in CODEGEN_CTTEST_CSTOOLS7INC_MODULE.inc file.
That's all, folk!
We define SYSTEMTIME because it's used in several of our structures and functions. It looks like a fairly simple change we can make with our include file to avoid this issue with yours:
#IF NOT %DEF(%SYSTEMTIME_DEFINED)
%SYSTEMTIME_DEFINED = 1
TYPE SYSTEMTIME
wYear AS WORD
wMonth AS WORD
wDayOfWeek AS WORD
wDay AS WORD
wHour AS WORD
wMinute AS WORD
wSecond AS WORD
wMilliseconds AS WORD
END TYPE
#ENDIF
Another solution is to remove it and add #INCLUDE "Win32Api.inc" in your file. The conflict comes because I use explicit alignment in structures, not the default BYTE alignment.
For anyone interested, when converting C/C++ headers, you need to be careful when it comes to structure alignment in PowerBASIC because there are some differences. For example, with the SYSTEMTIME structure, in C/C++ it doesn't matter if you use use #pragma pack to set 1, 2, 4 or 8 byte alignment (the default); the structure is always 16 bytes in size. In PB, using those alignment qualifiers produces different sizes (and incompatible alignments). For example:
#pragma pack(4)
typedef struct _MYSYSTEMTIME
{
WORD wYear;
WORD wMonth;
WORD wDayOfWeek;
WORD wDay;
WORD wHour;
WORD wMinute;
WORD wSecond;
WORD wMilliseconds;
}
The sizeof() that structure is 16 bytes with 4-byte alignment. It would be the same if you used #pragma pack(1) or #pragma pack(8). However, you can't use PB's TYPE member alignment in the same way as #pragma pack, or you'll run into problems. For example:
Type MYSYSTEMTIME DWORD
wYear As WORD
wMonth As WORD
wDayofWeek As WORD
wDay As WORD
wHour As WORD
wMinute As WORD
wSecond As WORD
wMilliseconds As WORD
End Type
The size of that structure in PB would be 32, not 16, because it's aligning each member on a 4-byte boundary (what the PB documentation says it will do), but that does not correspond to how #pragma pack actually works in C/C++ where specifying an alignment larger than the natural alignment of a type does not change the type alignment.
Bottom line, you cannot use the #pragma pack directive as an indicator of what qualifier should be used for structure alignment in PB. Unfortunately they work differently, and the two are not compatible. Most structures in the Windows SDK uses #pragma pack(8), with some notable exceptions like the multimedia API, but if you tried to put QWORD modifiers on those TYPE defintions in PB, virtually all of them would be the wrong size. Just something to be aware of.
Edit: And having emoticons enabled in this post made it interesting to read. ;)
This is why, in my headers, each and every one of the more than 7800 structures that they contain have been checked with the results of M$ C++ compiler.
For example, this one:
' // Size = 48 bytes
TYPE GESTUREINFO QWORD FILL ' Must be 8 byte aligned
cbSize AS DWORD ' UINT // size, in bytes, of this structure (including variable length Args field)
dwFlags AS DWORD ' DWORD // see GF_* flags
dwID AS DWORD ' DWORD // gesture ID, see GID_* defines
hwndTarget AS DWORD ' HWND // handle to window targeted by this gesture
ptsLocation AS POINTS ' POINTS // current location of this gesture
dwInstanceID AS DWORD ' DWORD // internally used
dwSequenceID AS DWORD ' DWORD // internally used
ullArguments AS QUAD ' ULONGLONG // arguments for gestures whose arguments fit in 8 BYTES
cbExtraArgs AS DWORD ' UINT // size, in bytes, of extra arguments, if any, that accompany this gesture
alignment__ AS DWORD ' // To keep 8 byte alignment
END TYPE
Must be 8 byte aligned. QWORD FILL does it, but the last (same behaviour than DWORD FILL, by the way). So I have needed to use a filler member at the end.
QuoteThis is why, in my headers, each and every one of the more than 7800 structures that they contain have been checked with the results of M$ C++ compiler.
Jose, Jose this is just unbelievable how much effort you have been putting into this!