Registering DLLs from XFRX with FoxPro

I talk with people who use it and love it.  I use another solution.

However, other than the program having trouble operating on some computers and not others, what more can you tell us about the nature of what isn't working and what it is you're trying to do when it doesn't work?

Hi Carl, I am still researching this but so far:
All computer are XP workstations on network servers.
XFRX requires msvcr71.dll, gdiplus.dll needs to be installed. The support libraries hndlib.dll, zlib.dll and xfrxlib.fll need to be included. I have all the files under my one directory. When I copy the directory to station 1 I get and error "xfrxlib.fll cannot be loaded." The documentation implies that msvcr71 and gdiplus are not installed.
I then attempted to register the dlls with regsvr32. I got the file was loaded but the DLLRegisterServer entry point was not found.
I then copied the directory to station 2 and the programn worked great!
Copied to station 3, "xfrxlib.fll cannot be loaded." . I got the IT manager to use admin rights to register the server, same error about the entry point not found.
Station 4 - works fine.
I have sent off an email to Martin at EQEUS about this. Though I would check over here for possible areas to check. Let me know what more information is helpful. Thanks

>> I got the file was loaded but the DLLRegisterServer entry point was not found.

That usually means that the DLL name was not entered in its case sensitive form.  Registering DLLs is case sensitive, unlike the rest of the manipulations we do in FoxPro.  So, try again and take extra care that things that should be upper case are upper and things that are lower case are lower.  :)  Then we'll go from there.

Cannot find entry point (DLL name) in the DLL with Visual FoxPro
http://support.microsoft.com/default.aspx?scid=kb;en-us;149431

I just got on the client's computer and checked the cases.
GDIPLUS.DLL returned: GDIPLUS.DLL was loaded but the DLLRegisterServer entry point was not found
The file does not appear to be a .DLL or .OCX file
msvcr71.dll  returned msvcr71.dll was loaded but the DLLRegisterServer entry point was not found
The file was not registered
While I have been programming this, I don't recall registering these on my work computers. One of them is a new Vista laptop and I know I did not register these files.....

I can copy files like msvcr71.dll and gdiplus.dll with a couple of other VFP runtimes and run an entire app right from there WITHOUT ever registering the DLLs into the registry.  In fact, I have all of that on a memory stick with a command window emulator program to do some quick and dirty stuff on a PC as long as they have a USB port.

Having said all that, if xFRX demands to look in the registry for what it needs, they will have to all be registered properly with case sensitivity in mind.

One thing to keep in mind is that in order for some DLLs to get properly rtegistered, the order they get registered in seems to be important with many of them assuming that msvcr71,dll is installed/registered first.  If msvcr71.dll is not already there, others seem to fail to register.  The sad part of this DLL hell is that msvcr71.dll is no longer considered a real system DLL and can be independently placed in many locations.  But, because you need to it registered for other DLLs to register correctly, you could be getting interference from other slightly different copies in different locations of msvcr71.dll.

Redistribution of the shared C runtime component in Visual C++ 2005 and in Visual C++ .NET
http://support.microsoft.com/default.aspx?scid=kb;en-us;326922

"To address this issue, the CRT DLL is no longer considered a system file, therefore, distribute the CRT DLL with any application that relies on it. Because it is no longer a system component, install it in your applications Program Files directory with other application-specific code. This prevents your application from using other versions of the CRT library that may be installed on the system paths."

VFP 9 Runtime Files
http://fox.wikis.com/wc.dll?Wiki~VFP9RuntimeFiles~VFP

BTW, my gdiplus.dll was all lower case.  You showed upper case above.  I don't know quite what to think about that.

I quickly scanned one PC here and I see six different versions of gdiplus.dll on it with three differebt spellings that make case sensitivity an issue when and if you want to redgister one or another.

gdiplus.dll
GDIPLUS.DLL
GdiPlus.dll

Crazy, huh?

I almost forgot to mention to you that gdiplus.dll does NOT have to be registered.  So, regardless of case issues with that file, that is not the culprit in your case.  It may well be that one of those other two you mentioned needs to be registered.  The fll one is a Fox DLL that is referenced from inside of FoxPro using a simple reference like SET LIBRARY TO xfrxlib.fll.  So, that seems to point to the remaining two DLLs, hndlib.dll and zlib.dll.

Thanks Carl,
I have to wait until Monday so I can access the client's PC. I am also hoping for Eqeus.com abou this issue. Can't go any further since the progrma runs on all the computers here. Will let you know. Thanks

No problem.  It could be Equeus specific, but I think the area to look at is narrowed down.

XFRXHow To Use It
http://fox.wikis.com/wc.dll?Wiki~XFRXHowToUseIt~VFP

PDF Creation - Files Needed to Run XFRX

XFXR.APP
HNDLIB.DLL
ZLIB.DLL

You must place ZLIB.dll and HNDLIB.dll in the directory where your compiled EXE resides. These files are not windows system files and should not be registered with the Windows system. IOW do not use REGSVR32 with these files.

XFXR.APP, HNDLIB.DLL and ZLIB.DLL are in the main directory of my program.  I don't think using XFRX is my problem since I can put the directory in 50% of the compaters and it runs beautifully. One issue is that the target computer MUST have WORD and EXCEL to create the .DOC and .XLS files. I don't need the WORD document, since I am already creating a .TXT file. For the EXCEL, I am creating a .CSV in the program so I don't worry about having the client install OFFICE to those computers

I certainly understand the MS Word requirement-- I have to have it as well to create DOc, RTF, or HTML output from the FRX input.

I have had issues with older versions of MS Word on a PC and I have had issues with multiple versions of MS Word on the same PC.

You brought up an interesting issue. I haven't checked the one workstation for Word. If Word is missing, would the "xfrxlib.fll cannot be loaded" error come up. Another thing on a different PC, the IT manager has strict guidelines. He restricts the PCs so the users can no go out to the internet without re-entering their password. So time ago I updated teh program to convert one database to a .xls file. That did not work. The only reason was it could not access Excel. It was minor so I did not look into it further. They might also be on Office 2007 or be networked that another program such as mine can't access Word..  

One of the places where I am attem,pting to install has a VERY sharp IT manager. he is sometimes difficult to work with since I am a vendor, But he does no his stuff. He had a tracer-type program to identify all files being called by my program. Looking at the errors the program could not access ad open MSVCP71.DLL. According to the docs, I have been using MSVCR71.DLL. I do have MSVCP71.DLL in my system32 of my working PC. I am going to copy that to my directory and see if that works!

For sure, that is the file that drives it all.

Martin just answered back. Since their version 12,  MSVCP71.dll is required. I am attempting to Get on a Webex with the client in SA and will check the other site tomorrow.

I thought it was a typo before.  But now I'm not so sure.

MSVCP71.dll is required?

Is that msvcP71.dll and not msvcR71.dll?

P is the version I need. I looked at the log and was only calling for msvcP71.dll

It worked in San Antonio. I am using their logo fro the reports, which is 3 Meg, so the program took a long time to upload the email. But I am sure the new MSVC file is it! I will wait to see if I can get the local station working before I close this out. Thanks Carl!

Great!   Those DLLs sure can wreak havoc.  We're just trying to get some database work done.  ;)

It's amazing how hard it is to find out what that one DLL is.  I can find sites to download it from all over the place.

Here's one simple blurb:
For Microsoft Visual C++ 2003, your program will be dependent on MSVCRT.DLL and MSVCP71.DLL

What are the C and C++ libraries my program would link with?
http://support.microsoft.com/kb/154753/en-us

Carl,
I ran into an issue in another site. The HTML had the graphic but changed my font and spaces. I copied the directory and ran the same program from my laptop and the graphic and font were fine! Any thoughts what to look for in that other computer.

I think I have found the solution on the fonts. XFRX is creating the HTML correctly, however our emails go through the company's email server where they add a legal disclaimer on every email. I think that is affecting the HTML since I proved XFRX is working. I sent out an email to Marshallsoft, the email generator and copied EQUES. Thanks for your help on this. Seems that MSVCP71.dll was the solution in this issue.

You're welcome and thanks for recognizing my efforts at helping you.

Yes, those e-mail "filters" can create problems for all of us.  I use the full features of HTML and post a message to a list server and all of my effort to use the capabilities of HTML with fonts for emphasis and a small graphic are laid to waste when they post the message as Plain Text.  Blech.  It's like wasting perfume on desert air.