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!

Row or column position is off the screen

Status
Not open for further replies.

dmusicant

Programmer
Mar 29, 2005
253
US
I get this rather frequently when I run one of my apps. The screens were FPW 2.6a generated, and I presume the errors are due to that. I'm running the app with VFP 9.0. I think it may happen more when I click things quickly. When it happens I have to restart the app. I run it from VFP itself, not from a compiled version, i.e. I run a PRG which goes into the other code, which includes an SPR or two. Usually, I display on 23" monitors that run at 1920 x 1080. I don't know that my actual display has anything to do with this. Thoughts? Thanks!
 
Yes, the display has a lot to do with it. I got this error a lot with a FoxPro 2.x app. before I rewrote it in VFP. Those buttons are defined differently than VFP command buttons.
What would happen is users would change their font size from 'Regular size' (100%) to 'Medium' or 'Large' in the display settings. That made some captions on buttons not fit on the button any more.


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
I suppose I should create a VFP screen for this app. There's a lot of embedded code in the FPW screen, I'd have to lift it and put it in the VFP screen. Wish there was a simpler way to do it, it might be tricky to get all the FPW screen functionality ported over to a VFP screen. Seems to me that the paradigms are pretty different. Getting it to work OK would be something of a project. Funny thing is I'm not changing fonts and screen res. It bombs not constantly, but maybe 5% of the time I run the app. I think it happens when I try to run things too fast.
 
Yes, the two platforms are totally different and there is a lot of conversion time involved. But if you're going to keep the app around for a while it can be worth it.
In the meantime though you could try changing the size of some of the buttons or the captions. Might make a difference.


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
Make sure you have FoxFont available at run time. FPW "figured out" screen positions based on font metrics inside FoxFont whether YOU used it or not, and if it's missing there's no telling what font it'll use as substitute. Those algorithms will still be with you if you're running a FPW "screen" inside VFP.
 
Dan, I just this minute saw your post here. I just checked on this machine, the one where I have experienced the errors, at least most recently. It has FoxFont Regular and FoxPro Window Font Regular installed in Control Panel/Fonts.

I had spent the last 1/2 hour or so modifying the FPW screen whose SPR has been sporadically bombing. The last bomb gave this error:

The text below in the SPR was highlighted:

@ 29.846,38.833 SAY "Pack tables" ;
FONT "MS Sans Serif", 13 ;
STYLE "T"

That "Pack tables" is a label next to a button. Well, there are around 20 such labels on the screen next to either individual buttons or (in one case) a vertical set of buttons. Why it picked out "Pack tables" I don't know. Several of the labels are quite a few more characters than the 11 there. I figured, based on Dave Summers' comments that I might work around the problem by reducing the size of the font from 13 to a smaller size. I was going to make it 12 (custom) but decided to go with the next smallest non-custom, which is 11. I regenerated the screen (after saving the previous version!), and will see if the errors disappear.

Might it help if I pick a font other than MS Sans Serif?

 
Yes, MS Sans Serif is probably the worst of all choices because it isn't TrueType.

This problem is compounded by the fact that it's the default font used by FoxPro for Windows, a choice made before Microsoft acquired the company and never changed because by the time the problem was recognized they were well on their way to obsoleting the product with VFP.
 
Thanks, Dan. So what would you recommend for those labels? FoxFont? Any True Type font? I'm fond of Arial. Would FoxFont be a better idea? The changing of it isn't trivial, there are about 25 separate labels. Thanks!
 
Personally, I would start with making a copy of your .SPR and change (one at a time) the font names, sizes, @...SAY positions, anything else display based that you can think of using a global search and replace. Then beat the h_ll out of it testing, clearing, redrawing, ... without doing actual file manipulation. Or if you need to, use some test files on that particular screen. See if you can break it that way. When you get a combination figured out, go back and change the .SCX and regenerate it, or make the same changes in the live .SPR.


-Dave Summers-
[cheers]
Even more Fox stuff at:
 
Arial is VFP's default and has caused no problems. It's what I always tried to use in FPW.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top