Screen Program Loses Focus 1

[Stoomis]

After I run a screen program and click off of it to say the command window I cannot regain focus to the screen. This is extremely frusterating. Any ideas?

 

[rgbean]

I'm not really sure what the situation is. Can you provide some more information?
1) FoxPro DOS or Windows?
2) Version? (1.0, 1.1, 2.0, 2.5b, 2.6a)
3) Development Environment or Runtime?
4) IF FPD, are you running under Windows?
5) IF FPD, what memory model are you running?
6) What OS?
7) Is the "screen" the FP one, or one you wrote in code or with the Screen designer?

Rick

 

[Stoomis]

FoxPro DOS 2.6a in the developement environment. My OS is Windows 2k. The screen is the .PRG file created by FoxPro. What do you mean by memory model?

 

[Nigel Gomm]

could it be that by deactivating the screen the READ is terminating but you don't release the window so it appears to still be there ?

 

[rgbean]

FPD doesn't run that well in the OS's that aren't really DOS based - Win NT / 2000 / XP. You'll often see that FP will grab 100% of the processor and nothing else runs until you "kill" FP.

Make sure you have a MEMLIMIT in it's CONFIG.FP file - it seems to help for some situations. Since FoxPro DOS or Windows can't use more than 16MB, I use
MEMLIMIT = 60, 2048, 16384.

Some people have had luck with TameDOS -

http://www.tamedos.com/tame/tamehome.htm

when running DOS
programs in 2000 / XP in particular.

Rick

 

[Stoomis]

I checked it anyway but as I suspected this is not a memory issue. After the generated screen pops up I cannot go back and forth from the generated screen to the view or command windows. Is this just a limitation of the program?

 

[rgbean]

Ah, I think I understand! FPD is not an end user Event Driven Model. All forms are Modal - meaning that it normally needs to be closed before you can access another screen. (A modal screen can start another modal screen, but you need to close the second before returning to the first.) This is simply the DOS way of doing one thing at a time. While the FoxPro environment was always a windows-like event driven model, it's really difficult to create applications that work this way in FPD. If you want this capability, move up to VFP.

Rick

 

[Stoomis]

Rgbean,

I was afraid of that. This makes it difficult to see field relationships. But thank you anyhow.

 

[JRB-Bldr]

"This makes it difficult to see field relationships"

Everything that Rick says above is absolutely true, but there still might be a hope for you.

There are a number of ways to show concurrent field relationships in FPD and FPW.

Plus your FPD screens are not restricted to being Modal.

And, lastly, using a tool like GENSCRNX might work to display multiple browse windows each showing separate related tables on a single screen.

Perhaps continuing on with your explanation of how and what you want to display on-screen will help us provide you with an answer that is supportable in FPD.

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com

 

[Stoomis]

Okay here goes. What I want is to be able to see where the information in a screen relates to the information in a table. This should be possible with the view but you cannot switch between both of them. I am working with a screen which I did not create and I am trying to understand the relationship between the memory variables it refrences and the fields in the table.

 

[JRB-Bldr]

My first question is - are you trying to do this in the Development environment or do you want it to work this way in the LIVE mode?

Next question relates to - "to see where the information in a screen relates to the information in a table" ??

Do you mean that you need an Incremental Browse which locates records matching partial input into a field? In which case you might want to look at JKEY.

Or are you merely looking for a records whose field content fully matches user input? Thereby using a SEEK or LOCATE.

In a LIVE mode, the easiest way would be to utilize GENSCRNX to have both the GET field and the BROWSE window contained in a single User Screen.

In the Development mode, you should be able to use the TRACE window to BREAK & Suspend entry, Browse the needed table to check results, and then RESUME.

I hope that this helps, if not continue giving us input on where/how to better focus our responses.

Good Luck,


JRB-Bldr
VisionQuest Consulting
Business Analyst & CIO Consulting Services
CIOServices@yahoo.com

 

[ghunaima]

There is a simple way to pause a screen temporarily & then to resume its processing. simply define a key label to suspend your processing, (Command: ON KEY LABEL F9 SUSPEND) before running the screen. Then when screen is running press F9 key anytime & your program got suspended temporarily, now you can go to Command prompt & can see that all your memory variables & open files are available there so you can check. Issue RESUME command to continue processing if you want or CANCEL command to close the procedure.