possible bug with SHBrowseForFolder & questions

[post from old forum]

I just switched my code over to pelles. I have a couple of questions:
The below code compiles correctly in other compilers.
In pelles you get errors trying to free the memory used by SHBrowseForFolder.

question 1:
How can I free the memory?
i tried including these to header files

Code: [Select]


#include <shlobj.h>
#include <OBJIDL.H>
static LPITEMIDLIST pidl;
static BROWSEINFO bi = {0};

pidl = SHBrowseForFolder ( &bi );
if(pidl!=0)
{
// get the name of the folder

if ( SHGetPathFromIDList ( pidl, gptmp->tdir ) )
{
SetDlgItemText(hwnd,IDM_PRINT,gptmp->tdir);
FillListView(GetDlgItem(hwnd,IDM_SECUR),gptmp->tdir);

}

// free memory used
IMalloc * imalloc = 0;
if ( SUCCEEDED( SHGetMalloc ( &imalloc )) )
{
imalloc->Free ( pidl );
imalloc->Release ( );
}
pelles errors on imalloc->Free ( pidl );


error: Left operand of -> has incompatible type 'int'
error: Found 'int' expected a function.
error: Left operand of -> has incompatible type 'int'
error: Found 'int' expected a function.
}

Question 2:
In pelles fpos_t is defined as:

Code: [Select]


typedef struct fpos_t {
long off; /* system dependent */
mbstate_t wstate;
} fpos_t;


I cannot find any documentation on the web where fpos_t is defined as a struct.
Usually it is:
typedef long fpos_t;

Is fpos_t.off the position in the file?
fpos_t pos;
...
fgetpos(stream,&pos);
...

Question 3:
I would like to be able to use muliple compilers. Because of question 1 and 2,
What code can I insert to tell that I am using the pelles compiler?

zzen

[post from old forum]

Q1: This is a C compiler (not C++) so you must use the C syntax:
pMalloc->lpVtbl->Free(pMalloc, pidl);
not
pMalloc->Free(pidl);

Q2: The C99 standard says this about fpos_t: "which is an object type other than an array type capable of recording all the information needed to specify uniquely every position in the file."

...and...

"Each wide-oriented stream has an associated mbstate_t object that stores the current parse state of the stream. A successful call to fgetpos stores a representation of the value of this mbstate_t object as part of the value of the fpos_t object..."

...and possibly more...

Yes, fpos_t.off should be the position/offset in the file.

Q3: The preprocessor symbol __POCC__ (that's _ _ POCC _ _) can be used. It's value is the current version, right now 274.

Pelle