Possible DLL version?

[myearwood1]

Hey Christian

If you could release your library as a DLL, would that mean I could potentially ....

DeleteFileEx.prg LPARAMETERS tcFileName DECLARE INTEGER DeleteFileEx IN VFP2C32.DLL RETURN DeleteFileEx(m.tcFileName)

to avoid having to SET LIBRARY TO?

[ChristianEhlscheid]

Hello, theoretically yes, but that's not an endeavor I'm willing to go through. I'd have to rewrite every function because the parameter handling between the an fll and a normal dll with DECLARE'd functions is fundamentally different. And there are certain types that can't be passed as parameters at all, e.g. memo fields. I also don't see any advantage, SET LIBRARY is simple. Load the FLL at the startup of the app or component and release it in the app cleanup code, or event don't release it at all. That's how we handled it in my old firm, never has been an issue.

[myearwood1]

I'm not disagreeing with you, nor trying to get you to do it. I understand and accept your decision.

I just want to make my thinking clear to you. The aggregation of things into libraries of any kind is fundamentally flawed IMO. If all I want to do is use your DeleteFileEx function, having to load the entire library - and that goes for VCXs, procedure files etc - is impeding my productivity. I usually create a tiny prg and have it declare the DLL or in your case, open the FLL and then defer to the intended function directly. In effect, I percolate the C++/c# code up to where my app can directly call it.

Even instantiating the FileSystemObject is less convenient than what I'm describing. To GetFileAttributes from the Windows API is easy and I don't need

LPARAMETERS lpFileName
DECLARE INTEGER GetFileAttributes IN kernel32 STRING lpFileName
RETURN GetFileAttributes(@lpFileName)

I can call it anytime I need to check a file attribute and know I don't have to push and pop any existing ON ERROR, nor load the FSO, nor set library. The declare is encapsulated into GetFileAttributes.prg. It is done only once. If the declare is released, this code will reload it automatically.

[ChristianEhlscheid]

Hello Mike,

"The aggregation of things into libraries of any kind is fundamentally flawed IMO" The whole operating system is build on that principle where related functionality is compiled down to a dll, sorry but I don't get the argument.

The whole idea behind VFP2C32 was to relieve people of having to do all that DECLARE stuff and sometimes difficult or even impossible parameter passing to API functions and increase their productivity, it's not always trivial (as in the GetFileAttributes case) for FoxPro programmers to deal with all those edgecases and necessary datatype conversion when calling API functions, You'll essentially have to learn C/C++, which kills productivity since you're dealing with technical details instead of the problem at hand. The library was intended to bridge this gap.

Since you're bringing it up again that SET LIBRARY is somehow problematic, I don't know your specific circumstances, that's why I can't follow your argument. It's a dependancy problem, instead of finding a way to load many functions on the fly (which takes tremendous work), i would rather make sure that all functions are available all the time instead. In a compiled program that's not a problem. I think gofish runs inside VFP during development, so a developer could unload the library resulting in follow up errors, I don't know a good solution to this issue besides documenting the fact.

[myearwood1]

I use the tools as I find them or ask they be improved. Here's a better example. This is something I'm trying to donate to GoFish when they clean up their tempfiles, it crashes.

I have a folder of temp files. There are multiple versions of FoxPro running so there are files that a single instance cannot delete. I put 50,000 files in that folder. The app I inherited never cleaned up the temp folder. The other day I found a machine with thousands of tempfiles accumulated over the years due to crashing FoxPro.

I used DirX and therefore ADirEx to build a cursor.

I have a deletefile.prg like this LPARAMETERS m.lpFileName DECLARE INTEGER DeleteFile IN kernel32 STRING @lpFileName RETURN DeleteFile(@m.lpFileName)

This code erases all 50,000 files in 6.4 ~ 6.5 seconds. The ADIR function, even in vfp9 can fail with Too Many Variables - which on error cannot trap.

select DeleteFile(alltrim(filename)) as nDeleted ;
    from c_temp ;
    having nDeleted<>0  ; 
    into cursor c_NotDeleted nofilter

My point here is the Windows API deletefile works excellently. It is is not, I can rely on programs like vfp2c32. I don't want to think about DeleteFile. The .prg installs the one I want, and then my FoxPro code only ever has to call DeleteFile directly, all thought of libraries etc is not required. I cannot see how libraries benefit me as a programmer at all.

[ChristianEhlscheid]

Hello Mike,

there are some wrappers like DeleteFileEx in the library that probably don't provide much value over the native API, but 98% of the functions in the library do provide a substantial value since they are not easily done in native VFP code or are technically impossible to implement in VFP at all - like ADIREX and many more.

I don't compel people to use my library, I've kindly donated it to the FoxPro community for free, with all the sourcecode included, and the feedback I received from the members of the community was positive overall.

I still do provide support by fixing bugs, or making small enhancements. But if a particular function doesn't fit your specific use case and an API function directly does what you need, by all means use the API directly.

[myearwood1]

Absolutely. You provided fantastic value to my DirX. As I said, I'm just reaching for mutual understanding. You are amazing. I am grateful for the chat. I honestly prefer to use your library as much as I can. :)

[myearwood1]

I greatly prefer functions give cursors than arrays, and case in point, ADIR in vfp9 is crashing in GoFish, so I'm trying to bridge the gap.