Wiki Home

Vista Aero Issues


Namespace: VFP
An application with "true" Vista capabilities must support the Aero feature. I wanted to share our experiences with issues which arose when migrating to VFP 9 in order to achieve the Aero look. We also have a remaining unresolved issue for which some of you might have a solution.

Using the Desktop Property


First, we found that setting Show Window to 2 is not a workable approach to get Aero tranparency for an application where it is desireable to maintain a main VFP window. This is because these Windows have the same "weight" as the main VFP window and thus can be easily hidden behind the main window if the main window receives the focus. Furthermore top-level forms cannot be modal. A better approach is to set the DeskTop property of your base form class to .T.

It is a bit strange for the user to be able to move the application's windows anywhere on the Windows desktop, but this could just as easily be considered to be a feature, rather than a problem. It should be noted that DeskTop = .T. windows are "top dog" in the VFP world. They will be in the topmost display level versus all other windows, including those with Show Window = 2. We have not found a way to bring a non-DeskTop window to the foreground over a DeskTop window.

This leads to an issue with print preview, a feature which our clients use a lot. The default display appears behind all open windows. In VFP 6, we achieved the desired behavior by using DEFINE WINDOW xxx, ZOOM MAX and then REPORT FORM WINDOW xxx. This doesn't work with the Aero design because you cannot set the DeskTop property of the print preview window when it is created in this way. It is necessary to define a print preview window class which has the DeskTop property set to .T. and then to use Create Object to instantiate the window prior to issuing the REPORT FORM WINDOW command. You can also manipulate the size and location of this window prior to reporting by setting Top, Left, etc. properties.

Where we are stuck right now is with toolbars. There is no Desktop property for toolbars, so that, if they are undocked and free-floating, they can easily disappear behind other windows. This is true for the print preview toolbar as well as our main application toolbar. IF anyone has a suggestion on how to overcome this problem, I would love to hear from you. Plus, if you have other ideas and experiences with running VFP under Vista Aero it would be great if you would share them here.

Print Preview issues


Well, we have our application running under Vista Aero. It looks pretty good! But it took a lot of effort to make the print preview feature work in an acceptable manner. In order to overcome the toolbar layering problem mentioned above, we removed the toolbar and substituted a container anchored to the top of the preview window which has controls with the same functionality. This method has the disadvantage of the container scrolling off of the screen when the user scrolls vertically, but the user can right click to bring up a popup menu or use hot keys, e.g Z for Zoom. By the way, trying to maintain centering of the container by setting the Anchor property did not work consistently, apparently because there were just too many events linked to resizing being triggered or somesuch. We just added a 2-line method of our own to the form's resize event.

To implement these changes we had to modify the frxPreviewDesktop object as well as frxPreviewForm in the ReportPreview app in order to set the Desktop property, to add the contaner and to hook our new container controls into methods and events in place of the toolbar. In addition we had to modify the ReportOutput app so that messages and the progress bar display on top of other windows.

If you explore the source code for the ReportPreview app you will find comments that do not inspire confidence. And indeed there is some very quirky behavior with this VFP component. Preview window sizing and the placement of the scrollbars does not work reliably if the initially selected magnification is larger than the window. We have defaulted the display to "Whole Page" to get reliable behavior. We also (reluctantly) removed the multiple page display feature.

Is it worth all of this effort just to have Aero? That's a question only you can decide.

-- Jim Vahl

P.S. Here's a tip on how to easily get an object reference to the report object. For example, it only takes 2 lines to set the PrintJobname to whatever you want:

DO (_REPORTOUTPUT) WITH 1 	                        && instantiate a report object, 1 = preview
_oReportOutput(TRANSFORM(1)).PrintJobName = YourName    && use collection to reference the report object)


Insert these lines ahead of the REPORT FORM WINDOW command.

Other potential solutions:

Combo Box Issues

As you move your mouse over a dropped-down combobox, every line you touch becomes highlighted. This makes it difficult to tell which one is selected. It appears to be related to the Enabled property of the combobox. If you don't touch Enabled, you won't see this effect. If you set Enabled to .T., either in the Properties window or programmatically, you will. (Thanks to Paul Warnick for discovering the cause.) Although I haven't encountered this, Rick Strahl has blogged about a similar effect with shortcut menus.

The workaround, as blogged by Calvin Hsia , is to add the following two lines of code somewhere in your application, such as in your startup program:

DECLARE integer GdiSetBatchLimit IN WIN32API integer
GdiSetBatchLimit(1)


-- Jim Vahl, Doug Hennig
---
Category Vista Category Windows OS Category Windows API
( Topic last updated: 2008.11.05 04:43:43 AM )