Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Rudimentary VFP 9 form issue

Status
Not open for further replies.

dmusicant

Programmer
Mar 29, 2005
253
US
Yes, I'm rusty, so rusty in Visual Foxpro. The code I deal with on a daily basis I wrote in FoxPro 2.6a for Windows. However, I run it in Visual Foxpro 9.0, in the development environment. I don't normally create an APP with the code, much less generate an EXE. I don't distrubute this stuff to anyone, I just use it for myself.

I've found that running this code has been problematical in that the FPW 2.6a opening screen, to which the application always returns after whatever activity goes on... that screen often fails to correctly redisplay (when code returns me to it) and I get error messages. So, on advice from folks here, I created a Visual FoxPro form that includes AFAIK all the code needed to mimic the FPW 2.6a screen that I have been running. It works, well for some stuff, see below. The way I ordinarily launch this application (from which I can launch the other things I use regularly) is to run a PRG from config.fpw. That PRG sets pathing and a few other things and then launches the main app. That app used to be a PRG, which is named d.prg. I substituted this call in the pathing PRG that's called in config.fpw:

DO form dform

It launches. A quibble I have is that the Command Window appears along side it. It's like an apparition or elephant in the room, as it were. I can ignore that. That's not exactly the problem. A problem is that when I click a certain button on the screen which launches one of my most frequently used applications I get "Object dform is not found." If I click [Ignore] the application launches. I don't get that message when I launch DO form dform from the Command Window, however for some reason.

A lot of the code I run requires the main FoxPro screen to be in the foreground. Things are written to the screen with @SAY/GET type commands. These cannot appear on the main form, that has to disappear while those functions are running and that's not always happening. Even when the Foxpro main window is the active window, the characters written to it can be too large, such that not all the information fits on my display. These functions are interactive reports to the FoxPro main window with some GETs.

How can I sort out these vexing behaviors? I'm thinking that there may be several ways to do this. Thanks for help.
 
FP 2.x screen programs always ended in a READ, in other words a wait state. Not so with VFP forms. They instantiate and then control returns to the command window.

You can solve that by launching your form from a program that ends with READ EVENTS. (And include CLEAR EVENTS somewhere in the form.)

READ EVENTS keeps you "in" your running code and will likely solve any "not found" errors caused by your code ending and things going out of scope.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top