No scrollbar in EXE 2

[randymce]

I'm using VFP7 SP1, and setting up an editbox with a vertical scrollbar. It works great on my dev machine - both in the dev environment and the runtime exe. But the scrollbox disappears when the runtime EXE is run on other PC's.

I found this problem in the archived "thread1254-1063226", which pointed out that SP1 fixes this. Made sense to me, so I made sure the client had the latest VFP7R.DLL and VFP7RENU.DLL from my dev machine. Both are version 7.0.0.9262, with sizes 3,336k & 880k, respectively. I also made sure the MSVCR70.DLL is the same version -- 7.0.9466, size 336k, and that didn't help.

What am I missing? I even put these three DLL's in the same folder as the .EXE, and the scroll bar is still not showing up.

 

[robsuttonjr]

I would start by removing all Foxpro runtime versions from clients in question then reinstall as ADMINISTRATOR. Also, do you use a startup exe, ie an executable that determines latest compiled exe and runs it? If so you need to recompile your startup exe also.

Regards,

Rob

 

[randymce]

1. I already removed the VFP6 runtime - no other runtimes were installed.

2. No - I don't use a startup exe.

3. As far as installing as an ADMIN, you might be on to something here. I don't actually install or register any of the DLL's - never done anything special since Fox+ DOS & Mac days (been doing this a LONG time!) Just been copying the req'd runtime files to the proper dir (in this case, the Windows System32 folder.) Never had a problem with this method... until maybe now?

How would you recommend I "install" the runtime files?

 

[robsuttonjr]

1st go here and download the foxpro 7.0 sp1 runtime setup:

http://www.afpages.com/?cat=down

2nd login as administrator on one of the clients

3rd run the vfp 7.0 sp1 setup on client

4th try the program

5th post a response if this worked

Regards,

Rob

 

[randymce]

The vfp7sp1 installer you linked me to wanted to install the runtime in c:\program files\common files\microsoft shared\vfp (I cancelled the install.) When I looked at my dev machine, I had the latest files there already v7.0.0.9465 - which explains why the runtime worked for me.

The runtime files I'm using for the clients are v7.0.0.9262 (as I posted earlier.) The ones in the 'microsoft shared' folder are v7.0.0.9465.

No need for installers/admin login/etc - I just went to one of the clients, copied the vfp7r.dll & vfp7renu.dll v7.0.0.9465 files into the c:\winnt\system32 folder, and everything works like a charm.

Thanks for the assistance!

 

[robsuttonjr]

So was there an older dll in the system32 directory on the clients?

Regards,

Rob

 

[randymce]

Yes - but the key was that the 'primary' location for dll's in VFP5 & 6 was c:\winnt\system32. In 7 & 9 (and probably 8), Microsoft relocated the primary location to 'c:\program files\common files\microsoft shared\vfp'

It worked in the past because VFP seeks for runtimes in the multiple locations and it eventually finds them. What I didn't know was that even though the files I had in 'system32' were the same as the client PC's 'system32' - the reason only mine worked is because only I had the additional, newer runtime files, in the 'shared' location ... which didn't even exist on the other pc's - and which was referenced 1st by VFP when searching for runtime files.

I love it when it all comes together! Thanks again.

 

[robsuttonjr]

This was a good thread for me also since I hate an app that has to have something else done by mis tech's in order to be installed. I want to give someone a link to my program and it runs without anybody having to install anything, ocx, runtime etc. Up until now I have eliminated having to setup odbc datasource by using stringconnect and using a startup.exe which copies the latest compiled version of program x to the users local drive. I will now add to the startup.exe a process that checks to see if the latest runtime is installed to the users system folder then copy if missing. We helped each other here.

Regards,

Rob