>>>Then I found the culprit - the section names in the ini file. For a while I was using chrtran(sys(1272,toObj), ".", "_"), but then I forgot the chrtran() in the font saving routine, and started getting both [formname.pageframe.page1.text1] and [formname_pageframe_page1_text1]. The recent version uses the former only. When I deleted the ini file, the new file didn't have any sections with underscores anymore... so that was it. I wrote a little routine which removes those sections, to purge the existing ini file in production, and voila, it all works.
>>>
>>>So, for you two guys, did I run into a bug, or just a limitation, or was I just sloppy? If it's a bug, is it a VFP bug or Windows API bug?
>>
>>Well, if you forgot the chrtran() in the font saving routine and ended up with sections that had the underscores - don't see how VFP or Windows can be to blame for that. Would of been nice if you would of got something a little more specific that the infamous c00005 error though.
>
>That's not the point - I had two sets of sections, one with dots and one without underscores. Now getprivateprofilestring should use only the one I pass as the parameter and shoudln't care if there's any other section, similar or not. Which it actually did for a while. Somehow I've pushed it to a tipping point where it was too much for this API. And the size of the ini was 20K when it was most bloated - nowhere near any magical number like 32K or 64K.
>
>And, mind you, getprivateprofilestring is not a recent invention by any means - it's at least 15 years old.

Ok I see your point. My GUESS is that its an API problem, but this is a GUESS.
Now if this was me, I probably wouldn't be using the getprivateprofilestring, but if I'd ran across this problem as you have I doubt I'd report the bug simply because you've found a way around the problem. Of cousre the 'proper' thing to do would report the bug.