FoxPro for Windows evolved from a 16 bit DOS product, and does not interact with
the Windows operating system in the same manner that a "true" Windows application does. When Microsoft
released Windows 95, FoxPro developers (and users) around the world
became painfully aware of some of these differences. The problems on this page affect all
FoxPro for Windows products (2.5x, 2.6x) and exist in any 32 bit operating system
(Win95/98/2000/NT). A more accurate title for this page would be "Running FoxPro for Windows
Applications in a 32 bit O/S". Note that none of these problems/solutions apply to FoxPro DOS,
even if running inside a Windows environment.
Fortunately, these problems were mostly cosmetic, and the solutions/workarounds
were easy to implement. The primary concerns were:
- The FoxPro Icon is displayed in the Explorer for a distributed application.
- The FoxPro 2.6 Icon is displayed in the Title Bar and Task Bar.
- The FoxPro 2.6 Icon is displayed periodically in a screen's Title Bar.
- The Close Button is always disabled.
- Screens with a bordertype of System cannot be restored after being minimized.
Shortly after the release of Windows 95, Microsoft provided a document entitled
"Running
FoxPro 2.6
Applications in Windows 95", which gave explanations and some
workarounds to these five problems.
We'll take a look at all these problems, the solutions recommended by Microsoft,
and explore some additional options that were not mentioned in the Microsoft document.
- The FoxPro Icon is displayed in the Explorer for a distributed application.
- The FoxPro 2.6 Icon is displayed in the Title Bar and Task Bar.
- The FoxPro 2.6 Icon is displayed periodically in a screen's Title Bar.
These first three problems are all related to icon displays, and are therefore
purely cosmetic. The simplest solution is to ignore the problem, and in some cases
this may be your best option. For those who wish to tackle the mystery of the
persistant Fox Icon, an understanding of how FoxPro handles icon resources is required ...
When you create a Windows executable (.exe) with FoxPro 2.x, by default there is
no icon embedded into the file. Therefore, any Windows application that
uses icons to represent files (Program Manager, Explorer, etc.) will simply display a default
icon - the familiar blue "Program Manager" box.
When the user runs this application,
a FoxPro icon will appear in the Title Bar, and also in any Windows process that
displays icons of running programs (Task Manager, Task Bar, etc). This FoxPro icon comes from the
"FOXW2xxx.ESL" library file that the executable uses. You can easily
view this icon by changing the ESL file name to *.exe, and Windows will then display the
internal icon. (In fact, this ESL file
is the actual executing program. Your FoxPro application merely acts as a loader
that launches the ESL, and then provides the xBase object code for it to run.)
By using the "AddIcon.app"
supplied with the Professional (or Distribution Kit) versions of FoxPro, you can
embed an icon into your exe file, and Windows will display that icon instead
of the default blue box icon in Explorer, etc. This embedded icon is for file display
purposes only, and never gets displayed during program execution. Think of
it as nothing more than a picture attached to your file name - it only gets displayed
when an application looks at the directory listing.
In order to provide a custom icon for your application, you
need to specify the icon file in your "MODIFY WINDOW SCREEN ..." clause, and then "include"
it (as type: FILE) in your project. This will build the specified icon file
into your executable, and will make it available for all display purposes while
your application is running.
The important point to understand is that there is absolutely no connection
between the icon embedded with "AddIcon.app" and the icon used by
your application. Your application will still display the Fox icon that is
located inside the ESL file - unless you specifically define a different icon.
But we now have three separate locations that FoxPro can store an icon:
- Inside the FOXW2xxx.ESL file (used by default)
- "Included" in your exe with Project Manager (to customize your title bar)
- "Embedded" into your exe with AddIcon (used for filename display only)
To complicate matters even further, the 32 bit operating system introduced a new icon size, the
16x16 icon. This miniature icon is used for most display purposes
in Windows 95 and above, and is generated on-the-fly if needed (i.e. if an
application only contains a 32x32 icon). The original icon specification
defined a 32x32 icon, and this icon had a file size of 766 bytes.
By using easily available icon editing tools, you can create an enhanced icon,
containing both a 32x32 and a 16x16 image. This enhanced icon file will have a
file size of 1,078 bytes. You may safely embed this dual-size
icon into your executable using "AddIcon.App", and Windows will display
the appropriate sized icon depending on its needs. These two icon images do not even have to look
similar to each other, but keep in mind that they are only used for file name display purposes.
Unfortunately, the icon that you specify with "MODIFY WINDOW ... ICON FILE ..." can only be a
single sized (32x32) icon. This is the icon that you "include" in your project, and is the one
displayed on your application's title bar. Windows will automatically resize
your 32x32 icon down to the required
16x16 size when it displays the image, but the end result will most likely be a hideous blur.
The best way to create
a usable icon is to design it first as a 16x16 image, then expand it to 32x32 before including it in your project. This
will give you better control over the appearance of the reduced image.
When you're ready to build your executable, you need to "include" the scalable 32x32 icon
(the one referenced in your "MODIFY WINDOW ... ICON FILE ..." statement), in your project,
then you build your exe
and use AddIcon to embed either the scalable (32x32) icon, or a dual-sized icon. Don't forget that
AddIcon needs to be run any time you rebuild your executable.
In theory, this should allow your application to properly display your desired icon.
But you'll soon notice that the Fox icon (from FOXW2xxx.ESL) keeps popping up from
time to time in your app. Most noticeably, it will appear on the title bar when the
application is first launched, and will remain there until the user clicks on the title
bar with the mouse. At this point your own icon will be displayed, but
the Fox icon will reappear from time to time during program execution.
The only complete way to eliminate this problem is by replacing the icon in the
ESL with the same icon you included in your project (and embedded in your exe).
Microsoft neither recommends
nor supports this solution, and the AddIcon app will not work for this purpose.
There are plenty of free (and shareware) icon utilities available, and I have
successfully used several of them to replace the ESL icon, with no ill effects.
This solution allows you to completely eliminate the random Fox logo that will
otherwise appear in your title bar.
- The Close Button is always disabled.
... but at least the button is dimmed, informing the user that it's inactive.
There is no "proper" solution to this problem, and none offered by Microsoft.
The closest thing to a workaround is to trap the mouse click with an
"On Key Label LeftMouse" statement, and determine if the mouse was pointing
to the "Close" button. This is not 100% accuarate, since FoxPro can't tell if
the mouse was on the close button or directly below it. And the button remains
dimmed, making it appear that the button won't work. But I use that technique
in all my personal apps, and now they shut down quite easily by clicking on
(or directly below) the dimmed out close button. It gets to be quite addictive.
- Screens with a bordertype of System cannot be restored
This problem will occur any time you define a window with
the "MINIMIZE" option, without also including the "GROW" option.
Once the user minimizes this window, there is no way to restore it to the
previous size.
If you really need the minimize option, you can simply
add the "GROW" option and your windows will be fully operational.
The normal purpose of "GROW" is to allow a window
to be stretched by dragging the border. This is rarely usable, since
any window involved in an active READ cannot be resized regardless of the setting of "GROW".
If you include both the "MINIMIZE" and "GROW" options in your window definition however,
your users will be able to minimize and restore the window as normal.