>>The DECLAREs will occur exactly once, when the object is instantiated from the class; if the object is scoped globally to the app (either added to a common VFP object like _SCREEN via ADDOBJECT(), or created as a PUBLIC variable, then you can simply check if the object exists and create it if it doesn't:
>
>This method has one weakness: any CLEAR DLLS as well as any other DECLARE of the same function but with different name/paras/return_value will break it. EVen if it works today with the existing code, nobody can be sure that future code (in-house or third-party) will not break it.
>
>So, DECLARE any dll function where/when it is used. The overhead is minimal. The advantage is, as always, solid code.
>
You're preaching to the choir here! If you take a look at all three of my downloadable files here on UT, you'd see that's exactly what I do.

The important problem here in all likelihood is to only call the initialization entrypoint once, and wrapping the API use within an object accomplishes that - if the object is scoped globally and doesn't get released or (or the parent doesn't do a RemoveObject), the visible presense of that object within the app, does accomplish this task. I've never seen a situation where redeclaring an API call in DECLARE...DLL did anything bad, but since I don't know the specifics of the .DLL in question, I'll let the guy who's got the docs tell me the conditions of contest!