Main

 
Running FoxPro 2.6 Applications in Windows 95
FoxPro
Resources
FoxPro
History
Survival
Guide
Functions &
Procedures
FoxPro
Library
Other
Stuff
############ ############ ############ ############ ############ ############

Running FoxPro 2.6 Applications in Windows 95


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:

  1. The FoxPro Icon is displayed in the Explorer for a distributed application.
  2. The FoxPro 2.6 Icon is displayed in the Title Bar and Task Bar.
  3. The FoxPro 2.6 Icon is displayed periodically in a screen's Title Bar.
  4. The Close Button is always disabled.
  5. 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.


  1. The FoxPro Icon is displayed in the Explorer for a distributed application.
  2. The FoxPro 2.6 Icon is displayed in the Title Bar and Task Bar.
  3. 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.


  1. 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.


  1. 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.



[ Top of page ]

[ Back to Survival Guide ]