Position is off the screen

[mmerlinn]

I have a strange problem that is driving me nuts.

The program has been working well for years and continues to work well. However, if I rebuild the APP, one of the screens called by the APP throws a "Position is off the screen." error EVEN IF NO CHANGES ARE MADE TO THE SCREEN.

When I compare the old version to the rebuilt version EVERY object position is UNCHANGED. But the newly rebuilt version will not work.

I have examined the SCT and found that EVERY position there is within the defined screen as they should be. And every position in the SPR is exactly the same as in the SCT as well as exactly the same in both the old and rebuilt versions. I have examined the calling program looking for anything that might affect the called screen, but find nothing there.

I have examined copies going back a year and have the same exact problem with all of them. When run unchanged, they work. When rebuilt, they don't work.

I have dozens of screens and every one works except one, even when rebuilt.

Needless to say, I need to find the problem and fix it. Manually changing the table associated with this screen is a royal pain especially since I have over a hundred thousand changes to make. And without updating the program, I have no choice but to manually change the table. Manually could take over a year while with the computer helping I can do it in about two weeks.

Can anyone point me to something that might fix the problem? Or point me in a direction so I can solve the problem myself? Or give me some idea how I can pinpoint where this is going wrong?

Using FP 2.6 on a Mac.

mmerlinn

http://mmerlinn.com

Poor people do not hire employees. If you soak the rich, whom are you going to work for?

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Raymond

 

[Olaf Doschke]

No experience, but is the positioning depending on foxfont, perhaps? I vaguely remember the font having influence on computed positions.

Bye, Olaf.

 

[mmerlinn]

Update.

When I run the screen as a stand-alone program, everything works as expected. It only fails when it is called by another screen.

It appears that the screen is being built as a contained child within a smaller screen. However, I never use child screens so have no idea why this is happening. The same smaller screen calls several larger screens, but all of the rest work fine. I have examined my code looking for anything that would cause this screen to be treated like a child screen, but can find nothing in either the calling nor the called SCXs.

Is there a setting somewhere that I am missing that might cause a child/parent relationship between screens? Or is there something else I can look for?

The code defining this window is:

DEFINE WINDOW partloc ;

AT 0.000, 0.000 ;
SIZE 38.083, 52.000 ;
TITLE "Update Part Locations" ;
FONT "Geneva", 10 ;
FLOAT ;
NOCLOSE ;
SYSTEM ;
COLOR RGB(,,,0,255,0)​

mmerlinn

http://mmerlinn.com

Poor people do not hire employees. If you soak the rich, whom are you going to work for?

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Raymond

 

[Dan Freeman]

Olaf nails it.

"Position is off screen" is usually caused by Foxfont being missing. Even if you don't use it, Foxpro DOES use it to compute font metrics.

The other screwy font-related mishap comes from using a non-TT font (such as, unfortunately, FP's default).

 

[Olaf Doschke]

But wouldn't that also happen with the old executables?
Is foxfont needed at build time!?

Bye, Olaf.

 

[Dan Freeman]

It's a runtime problem, IIRC.

I've seen this kind of weird thing even if the font is present in the fonts folder but was never installed so it wasn't in the fonts control panel.

Fox 2.x is a little weird about deriving screen coordinates owing to its cross-platform background. They devised a translation layer so that one set of screen coordinates could address multiple different resolutions and different x/y ratios across platforms. The translation layer uses FoxFont. (Nobody was more happy than me to see this issue die with VFP!)

 

[Olaf Doschke]

Since this is about "FP 2.6 on a Mac" it's really hard to tell what to do with foxfont there to find out, whether it helps, mmerlinn, but surely worth a try.

Bye, Olaf.

 

[mmerlinn]

So, if this is a font problem, how do I go about fixing it? Where should FoxFont be located? Anything else I need to know to narrow this down? And like Olaf says, why should it affect only one screen and not others?

Most things related to Mac FP work the same as other versions, or are closely related, so usually, but not always, a fix for one also works for the Mac.

I wonder if making a different screen with new code and deleting the old screen would bypass this problem. Would not fix the underlying problem, but might get me down the road for the time being.

mmerlinn

http://mmerlinn.com

Poor people do not hire employees. If you soak the rich, whom are you going to work for?

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Raymond

 

[Dan Freeman]

I wish I could remember. It has been a number of years since I last worked with FPM on a version of Mac OS that would run it.

I just don't remember. Sorry.

But the principle does not change. The font must be registered in whatever registering system the OS provides. Perhaps you should ask in a Mac OS group?

 

[mmerlinn]

Ok. So FoxFont must be on the computer, but where?

There are no files, visible or invisible, anywhere on my Mac named FoxFont or anything close to it. And I do not ever remember seeing any, yet my programs have worked for years. Is the name of the file FoxFont or does it have some other name?

Also, as of now everything seems to work ok, and I did nothing other than rebuild the APP for the umpteenth time. I have no idea what happened or even if I did something different. The problem went away and I HAVE NO CLUE WHY. Which means the problem is NOT solved and may come back to bite me at any time.

mmerlinn

http://mmerlinn.com

Poor people do not hire employees. If you soak the rich, whom are you going to work for?

"We've found by experience that people who are careless and sloppy writers are usually also careless and sloppy at thinking and coding. Answering questions for careless and sloppy thinkers is not rewarding." - Eric Raymond

 

[DSummZZZ]

I ran into this issue a bunch of times with FPW when people would change their screen resolution.
What would happen is the user would change their screen fonts to "Large" instead of "Normal" and this error would pop up before the caption on a command button could overflow the command button.


-Dave Summers-

Even more Fox stuff at:

http://www.dave-summers.net/foxprolinks.htm

 

[Dan Freeman]

That's a different issue, Dave. It was caused by using the (sadly) default font, MS Sans Serif, which was not a TT font and didn't react well to resolution or font size changes. (And it also caused the mysterious "silly putty" effect when working in X-plat environments.)

mmerlinn, I wish I could remember specifics but it's a memory from 1990-ish. ISTR you could just copy foxfont.fon from a FPW installation to the Mac's Fons folder, but that could be a faulty memory.