VFP 9.0 - If I unmaximize VFP it disappears entirely... have to kill the process 1

[dmusicant]

Just noticed this today. I usually run VFP maximized. Just now I have use for dealing with several apps at once, so I want to have VFP not maximized. But when I click the box to the left of the X, instead of getting a non-maximized window, VFP disappears entirely. I can find no way of dealing with the situation short of killing the VFP.exe process. When the app appears to have focus (although I cannot see it) typing this sequence has no apparent effect:

_screen.visible=.t. [ENTER]

What might be at play here and how can I fix this behavior?

 

[dmusicant]

So, I do some searching on the internet and see a page where it suggests this command

_screen.windowstate=0

I go to a command window and enter that. What could go wrong? That's supposed to set it not maximized, not minimized but "normal." However, what happened is that VFP again simply disappeared and I had to kill the process. Bonkers.

 

[Olaf Doschke]

Your normal state window position might be off screen.

Set _screen.left=0 and _screen.top=0 before going into normal mode.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Mike Lewis]

I agree with Olaf. This is the most likely explanation. But it should be a one-off problem. VFP stores the size and position of _SCREEN in the resource files between sessions. So once you have restored it to a reasonable size and position, it should remain there. You would have to have explicitly moved it off the screen before maximising it. Have you perhaps got some code in a startup program that does that?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Olsson]

When that happens to me it can be almost any application but the remedy is the same: Shift+right-click on the icon. Choose first "reset" (or non-maximize) if it isn't grayed out. Then Shift+right-click again and choose "move". Use left-arrow until the window is in screen, then press Enter. This always helps me, but you maybe must tweak this to your own needs.
Hope this helps (someone anyway).

 

[Mike Lewis]

Dan, that's good to know. In Windows XP, you could just click on the icon (as opposed to Shift+RightClick) to open the menu (the one that shows Move, Size, Minimize, etc). I thought that had disappeared for good in later version, replaced by the "jump list". I hadn't realised it was still there. Thanks.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Dan,

indeed I often am frustrated about the "move" option, as you have to know what to use to move and still guess where you have to move to.

It's not the first time within the past few weeks I cross this same problem from different posters on different forums and that general solution always evades me as I learned my lesson from a presentation session in a docked notebook placing apps on the presentation desktop and not getting them back into the notebook home desktop you will easily find apps off screen.

Multi-display setups also are now more complex and could even have the main screen in the middle of three screens or some corner of a 2x2 setup. And a beamer always can be a temporary further screen involved. It's easy to forget to pull back your windows into the main screen before closing them, but if you know that it helps avoiding the problem. The main screen, usually the leftmost, the one with the start button of the taskbar is always the one that's available in any situation. Putting application windows in normal mode into the main home desktop assures you also see them back there no matter what changed in the displays between starts.

But Microsoft could add a simple option for this situation. In the context menu of the minimized applications or taskbar representation of active applications they should put an option: Move to current display, that's all people want.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[dmusicant]

I just came back to this thread a few minutes ago because I again wanted to use my VFP 9 app (written in FPW 2.6a) not maximized and it would just disappear and I'd have to kill the process. Glad to see answers! Thanks!!!

Well, I tried Olaf's suggestion:

_screen.left=0
_screen.top=0

Basically this fixed the problem. I have no idea what might have caused the problem in the first place. The app is written to work in VFP and FPW 2.6a. In a setup PRG called from config.fpw, this is the only command for screen:

IF UPPER(VERSION())='VISUAL'
_SCREEN.Themes = .F.
ENDIF

 

[Olaf Doschke]

Hi,

It is a Windows feature, not just VFP, to record the normal state Window position when you exit.
That's when the offscreen position could result. It's usually on screen at the time.
So you might never find anything in your code.

You could do the opposite and add exit code that explicitly puts the screen into (0,0) position and window state Normal before exiting. Instead of quitting in maximized state. And when you start VFP and it runs maximized, that automatically stays in the current desktop screen. The stored position for the normal state only reveals itself when you put it to the normal state. On that I'm sure and that's why the window seems to slip away when you change state. It already was loaded at that position, this is just irrelevant while in maximized state. So that position doesn't need to be the result of any code of the current VFP session or the start or a bug with the the state change, it could come from the previous exit.

Anyway, it doesn't matter why the position is off. Once you're on a single display situation the (0,0) coordinates must work for _screen. If you have two displays you might just end up on the one you don't expect, but I doubt you find a configuration where (0,0) is an off-screen position.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name