Please be a little patient. Within just a few days, a huge number of Windows API samples, from simple function calls to complete functional applications, will be released to the public. We are talking about 1300+ function calls and 600+ code samples, with documentation and comments, everything free to be used by anyone. I am working on the final details just now, when it's released we will make a public announcement.

>Hi all,
>
>I have a piece of quite useful code, a plain windows-API-based case-sensitive replacement for both getfile and putfile that definitely covers a need here: a light, non-COM-based solution. I do not remember the originator of this code. So I cannot credit the author But I have attached the code base.
>
>This VFP encapsulation of GetOpenFileNameA and GetSaveFileNameA IN comdlg32.dll does the job offering what is needed for a neater get/pufile in VFP in a clean way:
>

>SET PROCEDURE TO api_getfile.prg ADDITIVE
>oDialog = CREATEOBJECT("API_dialog")
>oDialog.showdialog()
>

>With a hosts of functionality available as clean object properties (file extension choice list and various presentation style and input checks). Only ONE single issue but a serious one: memory leaks!
>
>I understand that encapsulating C/C++ data structures from VFP is a challenge. When I review code with VFP instructions such as:
>
>

>DECLARE INTEGER GetSaveFileNameA IN comdlg32.dll AS _FFC_SAVEFILENAME STRING @
>DECLARE INTEGER GetOpenFileNameA IN comdlg32.dll AS _FFC_GETFILENAME STRING @
>DECLARE INTEGER malloc IN msvcrt.dll AS _FFC_MALLOC INTEGER
>DECLARE free in msvcrt.dll AS _FFC_FREEMEM INTEGER 
>DECLARE INTEGER memcpy in msvcrt.dll AS	_FFC_MEMCPY2 STRING @, INTEGER , INTEGER
>DECLARE INTEGER memcpy IN msvcrt.dll AS _FFC_MEMCPY  INTEGER , STRING @, INTEGER
>

>... Well VFP could lose track and memory. It definitely does here!!
>
>Should anyone with an expertise on this stuff VFP-API interop have an idea on how to patch the stuff, you are quite welcome. My last C-coding session; early 1990s on Watcom-VFP integration.... Well that's some years ago. I am certainly leaking memory too! And my early 1990s expertise on the subject is down to nothing:-)
>
>Any pointer on the code attached is welcome.
>
>Regards to you all, Daniel
>
>PS: I am not really looking for a replacement via COM-based solutions or other heavy solutions :-)