Doug Glenn wrote in a message to All:

 DG>     Thanks in advance for all answers/critisism of the
 DG> previous code fragment. I did manage to figure out where
 DG> I was going wrong, ie: HAB HAB and so on, it dawned on
 DG> me that in actuality(correct me if I'm wrong),

The compiler interprets "HAB HAB;" to mean: make an object of
type HAB, previously defined with a typedef (in the OS/2 header files), and
name it HAB. The C language defines "name spaces" for different
sorts of labels, and the compiler is capable of sorting out some of this
stuff in an unambiguous way. However, some compilers will not allow this
particular use.

 DG> that it was assigning the lower case to the upper case call in
 DG> the libraries.

Actually, the OS/2 API functions you used are declared to be of type
APIENTRY, which means that they use the pascal calling convention in the
linker.  This means, in turn, that the function names are changed to all
upper case by the compiler, and are known as such to the linker.  When you
use all upper case to declare them, you are effectively using the functions
without a prior declaration from the OS/2 header files, since this is done
by the compiler and is case sensitive.  If you use the standard OS/2 header
files and call API functions with all upper case, then you will succeed in
linking them but the compiler may misinterpret the argument or return
types.

 DG> So I am now getting 1, or true on all function calls......

Note that these API functions do not have consistent return codes.
PrfOpenProfile() returns a handle of type HINI, and a return code of
NULLHANDLE indicates failure.  PrfQueryProfileSize() and PrfCloseProfile()
return true (non-zero) on success, or false (zero) on failure.

 DG> except for the puzzler... which is the following line(s):

 DG> strcpy(PSZAPP,"fis");
 DG> strcpy(PSZKEY,"prog_1");
 DG> test = PrfQueryProfileSize(hini, PSZAPP, PSZKEY, &PDATALEN);
 DG> printf("\nThe return code is %d", test);

 DG>     Its my understanding, that this should place in 'test'
 DG> the byte size of the key "prog_1". What it is doing is
 DG> returning 1....

No, the return value from PrfQueryProfileSize() is the completion code
indicating success or failure.  You are supposed to supply a pointer to an
unsigned long as the fourth argument to this API function, and the object
pointed to is filled in with the size value you are looking for:

   ULONG DataLen;
   test = PrfQueryProfileSize(hini, PSZAPP, PSZKEY, &DataLen);
   printf("\nData size: %lu", DataLen);

It is unconventional and confusing to name an object not of pointer type
something starting with the letter 'P,' although it is perfectly legal. 
You declared PDATALEN to be of type ULONG, which looks odd to a C
programmer, but it will work.  The whole point of so-called "Hungarian
notation" is to embed the type of the object into its name, in order
to enhance human readability.  That is, an object named
"pDataLen" would conventionally be a pointer to the data length,
an object named "pszApp" would conventionally be a pointer to a
string terminated by zero holding the application name, and so on.

 DG> whereas the key for that is "c:\test\blah blah"(not the actual  
 DG> key, but don't make me look it up ), somewhat larger than 
 DG> two bytes, it should be more along the order of a byte per char 
 DG> stored.  Using IMPD, all it shows recieveing is one. Now if I 
 DG> look at the value for PDataLen, it shows 18, which is more what 
 DG> I would have expected.

If PrfQueryProfileSize() is returning success, I would assume that 18 is
right. When you figure out how to call PrfQueryProfileData(), you can see
if it is right or wrong.

 DG> However in the example code in PMREF, it 
 DG> states the assignment is supposed to have the value. But we're  
 DG> talking about the same reference that shows in the syntax: 
 DG> rc=PrfQueryProfileSize(hini, PszApp, PszKey, PDataLen) vs 
 DG> rc=PrfQueryProfileSize(hini, PszApp, PszKey, &PDataLen) in the 
 DG> example code snippet. Note the & in the example which is 
 DG> missing in the syntax. (Oh what fun.)

Before you go criticizing the documentation, please understand that it is
right. In the documentation, pDataLen is declared as type PULONG, not as
type ULONG; this is why it has a name beginning with a 'p' by convention,
although this is by no means a requirement of the C language.  The OS/2
documentation presumes a certain level of knowledge about the C language,
and it would be impossible to do otherwise.  If you misunderstand the
documentation and then your code fails to work, what would you expect?

The documentation is telling you that you have to supply a pointer.  It is
up to you to make sure that the pointer actually points to something, and
that it points to the right thing.
 
-- Mike


---