Microsoft FoxPro
|
>The Report Toolbar does not show up in an EXE using Modify Report to enable the report building
Mike Lewis below shows how the FOXUSER.DBF/FPT controls whether the Toolbar shows up or not. You can do the steps he outlines, then copy the FOXUSER files to REPOUSER.DBF/FPT. Then SET RESOURCE TO REPOUSER before modifying the report, then Set Resource back to FOXUSER when done.
Rick Shaddock
VFP developers sometimes like to give their users access to the report designer at run-time. For the most part, this is no more difficult than executing a MODIFY REPORT command from within an executable. Too often, though, the report designer will appear correctly, but the related toolbars will be nowhere to be seen.
In general, to control the visibility of toolbars at run-time, you use SHOW WINDOW and HIDE WINDOW. For example:
HIDE WINDOW "Standard"
to hide the standard toolbar, and
SHOW WINDOW "Standard"
to make it visible again.
Unfortunately, these commands only work if the toolbar has already been opened during the current session. If it hasn't, VFP generates error 1714 (Window not defined). As you've got no way of programmatically opening the toolbars in the first place, these commands won't solve the problem.
Nor can you give the user access to the standard Toolbars dialogue from within an executable. It's true that you can create a menu with the Toolbars prompt on it, but this will be greyed out when you run the program.
The solution turns out to be quite simple. To understand it, keep in mind that the current toolbar status - that is, the visibility and location of the toolbars, and whether they are docked or floating - is stored in the VFP resource file. The resource file is in fact two files. By default, they are named FOXUSER.DBF and FOXUSER.FPT and can be found in the directory from which you launched the application.
With that in mind, here are the steps needed to ensure that the report designer toolbars are always visible at run-time:
From now on, the user will be able to move the toolbars around, dock and undock them, and even close them. But because the resoure file is read-only, these settings won't be saved when the application exits, so the toolbars will always revert to their initial status when the application starts.
One last point. Be sure to remove the read-only flags on the original copies of the two resource files (that is, the copies in your VFP directory). If you don't, all the toolbars and windows in the development environment - including the command window, browse window, property sheets, etc. - will revert to their default settings whenever you launch Visual FoxPro.
Mike Lewis Consultants Ltd. January 2001
In Reply to: Re:
Standalone executable version posted by Eric den Doop on :
: : What are the files to be distributed with the standalone EXE created in vfp6 ? And
where should (path) be copied it ?
: : Please reply!
: Search a bit more down on this webboard. Lots of posts about this stuff.
The only files needed with a standalone EXE is the three
VFP6*.DLL into the C:\windows\system and it's a good
idea to have CONFIG.FPW in the working directory. I found you need SCREEN=OFF in order for
the toplevel form
to get immediate focus upon startup.
If you use anything like comm (MSCOMM32) or other OCX related stuff, you have to make sure you include them with the DLLs.
vfp600.dll, vfpenu.dll, vfpole60.dll
FoxPro ODBC Driver
This worked for me:
- Browse the registry to HKLM\Software\Policies\Microsoft\Windows\Installer
Create: DisableMSI Type: REG_DWORD value = 0 (0 should allow you to install it was originally 1)- Browse to HKEY_CLASSES_ROOT\Installer\Products\
Search the list for the product that is causing the error.. delete the folder in the products folder… this may also correct your error.
