I have an application built in Foxpro 2.5 for windows.

At numerous places in it input is taken by defining say/get inside a
window deffinition. When this application is run on a system having
Windows XP - Default themes - the controls inside the window disappear
when Mouse comes over one of them.

Have to fix it any sugestions are welcome.

I'll assume you're running this 2.5 code in VFP because this is a known
issue.

In your startup program, issue _Screen.Themes = .f.

Dan

Tanveer wrote:

But the client wants to have this feature in this application .. What
is the best way to achieve this ? Is there any tool which reads window
deffinitions and stuff like say/get and ports them in a Form .. My Wish

There used to be a converter from FPW to VFP (and it may still ship with the
product--I haven't looked), but if I recall properly it created a WindowType
that YOU CANNOT CREATE FROM SCRATCH that runs in a special "compatibility
mode" and has the same problems you're having now.

You'll just have to re-create those forms if the client wants Themes. Often,
if you explain this to them they suddenly don't want themes so badly. ;-)

Dan

Tanveer wrote:

Dan Freeman schrieb:
And it it buggy - I had to fix a few issues when moving a very large app
with 150 work screens and about 200 minor screens (not counting help
screens) because some of the FPW-screen attributes were not ported
correctly.

*IF* the screens you ported look okay, you can build "normal" vfp forms
from the ported forms. That *only* makes sense if there is a common
method of switching forms and field validation/change involved. If you
can isolate such behaviour, the task it not as daunting as it seems at
first. Don't switch over in haste - I created a parallel version in one
release, fixed minor issues when the "old" one was released and on the
next release brought out the new one. That way I already had strategies
for the minor issues (mostly small layout fixes in checkboxes and option
groups) that I had not seen myself, the testing team found less issues
and nearly all fixes were done during the beta's: the developers had an
option to discuss all issues on the last days of the each beta and
compare to the current version, which had those errors fixed <g>.

That way the tasked considered impossible by this companies employees
was done at a third of the cost they had estimated themselves. I used
some of that budget to enhance functionality and clean up the sources -
with the fast error fixing it looked great <g>.


regards

thomas

Where can I find it ?

It's called CONVERT.APP and if it's assigned to the system variable _CONVERT, it
will automatically be invoked when you open a FPD or FPW screen in VFP. It's
supplied in all versions of VFP I have installed - 5.0 -> 9.0.

Rick

"Tanveer" <tanmalik (AT) hotmail (DOT) com> wrote