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 Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
screen size in foxpro 2.6 for windows 4
- Thread starter kimsue
- Start date
-
1
- #2
Kimsue,
Unfortunatly, in FPW there is no "Resize" event, or the ability to control Objects "Size" properties progrmatically. You would need to open each screen, and reasize all of the objects yourself to you liking in a 800x600 pixel format. (It's a drag...)
Wish I had a better answer for you. The only other option is a port to VFP, and unless you've got the time to re-write most of your application, it's probably not a real viable solution.
Best Regards,
Scott
Please let me know if this has helped![[hammer]](/data/assets/smilies/hammer.gif "[hammer] [hammer]")
Unfortunatly, in FPW there is no "Resize" event, or the ability to control Objects "Size" properties progrmatically. You would need to open each screen, and reasize all of the objects yourself to you liking in a 800x600 pixel format. (It's a drag...)
Wish I had a better answer for you. The only other option is a port to VFP, and unless you've got the time to re-write most of your application, it's probably not a real viable solution.
Best Regards,
Scott
Please let me know if this has helped
- Thread starter
- #3
Thanks for your input, Scott. I have purchased Visual Foxpro 7.0, but am somewhat concerned that Foxpro is soon to become a language of the past. Any opinions here? I am assuming Visual Foxpro has the capablity of resizing screens based on the resolution setting???
Kimsue,
Ahhh, the old "Will Fox Last" debate... It's funny, I've been working in Fox since just before it was purchased by Microsoft, and when they bought it, everyone said, "That's it! The next version will be the last..." Then, in 1994, I attended the DevCon VFP convention in Phoenix, where they released VFP 5, and everyone said "That's it! Fox is dead, this will be the last version." Then, I went to DevCon again in San Diego, a year later, where they didn't have a "New version" release, and everyone said, "Microsoft's going to Developer Studio, and VFP will be left behind... 6.0 will be the last version..." And then, this year, Version 7.0 was released, and they pulled it back out of .NET, and of course, everyone is saying, "VFP 7 will be the last version". Well, for such a dead language, Microsoft is certainly going to a lot of trouble to keep making new, and better versions. Version 8 is now under development, and will likely be out in another year's time. I see the move pulling VFP out of .Net a great move. VFP never really belonged in Dev Studio to begin with. This also allows us "VFP" users to get new versions without having to wait for 6 tools to be updated before a new release is done (as is the case with .NET).
Now, I say all this, having after all my time with Fox, finally switched to VFP just this year, with the release of 7.0, because I figured, VFP is not just a flash in the pan. I could be wrong, and 8.0 could be their last version, but at I figured I couldn't go on much longer say, "That's it, it's going to be the last version..." without sounding like one of those people who say, "The world will end tomorrow". You know, I woke up this morning, and the world was still here.
That's my opinion on the issue. Having made the leap myself recently to VFP, (and yes, it was a little painful, and took a little while), I now find myself really asking, "What took you so long?"
Cheers.
Best Regards,
Scott
Please let me know if this has helped
Ahhh, the old "Will Fox Last" debate... It's funny, I've been working in Fox since just before it was purchased by Microsoft, and when they bought it, everyone said, "That's it! The next version will be the last..." Then, in 1994, I attended the DevCon VFP convention in Phoenix, where they released VFP 5, and everyone said "That's it! Fox is dead, this will be the last version." Then, I went to DevCon again in San Diego, a year later, where they didn't have a "New version" release, and everyone said, "Microsoft's going to Developer Studio, and VFP will be left behind... 6.0 will be the last version..." And then, this year, Version 7.0 was released, and they pulled it back out of .NET, and of course, everyone is saying, "VFP 7 will be the last version". Well, for such a dead language, Microsoft is certainly going to a lot of trouble to keep making new, and better versions. Version 8 is now under development, and will likely be out in another year's time. I see the move pulling VFP out of .Net a great move. VFP never really belonged in Dev Studio to begin with. This also allows us "VFP" users to get new versions without having to wait for 6 tools to be updated before a new release is done (as is the case with .NET).
Now, I say all this, having after all my time with Fox, finally switched to VFP just this year, with the release of 7.0, because I figured, VFP is not just a flash in the pan. I could be wrong, and 8.0 could be their last version, but at I figured I couldn't go on much longer say, "That's it, it's going to be the last version..." without sounding like one of those people who say, "The world will end tomorrow". You know, I woke up this morning, and the world was still here.
That's my opinion on the issue. Having made the leap myself recently to VFP, (and yes, it was a little painful, and took a little while), I now find myself really asking, "What took you so long?"
Cheers.
Best Regards,
Scott
Please let me know if this has helped
-
2
- #5
Just one additional point. Since people are still obviously using and developing with FP products last updated in 1992 (and before!), even if VFP 8.0 was the last version, that means that we could still be actively using it 12-13 years from now (2014-2015). I'm not sure I'll be around that long!
Rick
Rick
infinitelo
Programmer
- Mar 7, 2001
- 319
just a thought: maybe we should get together and create a free foxpro project for free dos(or lynux). since m$ is done with it and all surley bill wont mind.
-
1
- #7
Kimsue:
I use two different screens which are sized according to the resolution being used. The programme detects the resolution using this bit of code
IF SYSMETRIC(1) = 640 AND SYSMETRIC(2) = 480
DO lukemast.spr
ELSE
DO lukemas2.spr
ENDIF
Of course you have to design a screen for each possible resolution. Tedious but effective.
I use two different screens which are sized according to the resolution being used. The programme detects the resolution using this bit of code
IF SYSMETRIC(1) = 640 AND SYSMETRIC(2) = 480
DO lukemast.spr
ELSE
DO lukemas2.spr
ENDIF
Of course you have to design a screen for each possible resolution. Tedious but effective.
kimsue
centering the screen usually makes things look better but a more sophisticated solution is to redefine or resize window in the setup code either (can use variables, expressions and can make use of functions such as Scols() )to make whatever size window you want. You will need to make sure the window has a name (rather than have system name). Then add activate window (so that following will be written in the right place).
Filling the window with fields etc is a bit harder .... (and needs a bit of patience) .... from the SPR file copy code for items to be resized into the setup and insert *RESIZE adjacent to each font, box size etc.
RESIZE=iif(scols()=640,1,1.25)
eg @ 3.769,0.400 GET xxx ;
SIZE 1.000*RESIZE ,11.200*RESIZE ;
DEFAULT " " ;
FONT "MS Sans Serif", 8*RESIZE ;
PICTURE "@K"
RESIZE=1 for 640 screens and 1.25 for 800 screens.
Finally, delete the copied items from the screen builder and recompile.
Have proved that the above works and don't expect any problems with more complicated items (but watch out)
Ted
centering the screen usually makes things look better but a more sophisticated solution is to redefine or resize window in the setup code either (can use variables, expressions and can make use of functions such as Scols() )to make whatever size window you want. You will need to make sure the window has a name (rather than have system name). Then add activate window (so that following will be written in the right place).
Filling the window with fields etc is a bit harder .... (and needs a bit of patience) .... from the SPR file copy code for items to be resized into the setup and insert *RESIZE adjacent to each font, box size etc.
RESIZE=iif(scols()=640,1,1.25)
eg @ 3.769,0.400 GET xxx ;
SIZE 1.000*RESIZE ,11.200*RESIZE ;
DEFAULT " " ;
FONT "MS Sans Serif", 8*RESIZE ;
PICTURE "@K"
RESIZE=1 for 640 screens and 1.25 for 800 screens.
Finally, delete the copied items from the screen builder and recompile.
Have proved that the above works and don't expect any problems with more complicated items (but watch out)
Ted
Kimsue
further to mine (prev message)the resize equation should be
RESIZE=iif(sysmetric(1)=640,1,1.25)
also you will need to add the "*RESIZE" to the locations ie above should have
@ 3.769*RESIZE,0.400*RESIZE GET xxx
if you are using non-scalable font (such as MS sans serif) you may end up with an unexpected (non-proportional) size
Ted
further to mine (prev message)the resize equation should be
RESIZE=iif(sysmetric(1)=640,1,1.25)
also you will need to add the "*RESIZE" to the locations ie above should have
@ 3.769*RESIZE,0.400*RESIZE GET xxx
if you are using non-scalable font (such as MS sans serif) you may end up with an unexpected (non-proportional) size
Ted
If you develop in 640, change the 800.00 to 640.00
In the main program:
MODIFY WINDOW screen FONT "MS Sans Serif", 8 STYLE "N"
CLEAR
PUBLIC GUIf
GUIf = ( SYSMETRIC(1) / 800.00 ) * ;
( 5 / FONTMETRIC(6,'MS Sans Serif',8) )
then change
@ 4.857,11.758 GET m.nField ;
SIZE 1.000,11.200
to
@ 4.857*m.GUIf,11.758*m.GUIf GET m.nField ;
SIZE 1.000*m.GUIf,11.200*m.GUIf
tedbain, does multiplying the FONT point size actually work? I guess 8 goes to 10 fine, but ???
Steven S
Professional Foxpro developer for DOS/Windows/Unix platforms since 1989.
clogic@yahoo.com
Steve
we're both partly wrong.
Multiply font size but not field/box size because latter depends on font size. Box size actually depends on Fontmetric so solution not always exact.
Also your approach needs modification if it has to deal with a range of font types, styles and sizes
Ted
PS think subject was a dead horse before I first wrote.
we're both partly wrong.
Multiply font size but not field/box size because latter depends on font size. Box size actually depends on Fontmetric so solution not always exact.
Also your approach needs modification if it has to deal with a range of font types, styles and sizes
Ted
PS think subject was a dead horse before I first wrote.
Long ago, I achieved auto-resizing by modifying GenScrnX (FoxPro's screen generator) to include scaling code in every @GET and @SAY. It wasn't hard to do (a day or so as I recall) but - sorry - I no longer have the code! It certainly would be quicker than porting lots of apps to VFP. Another solution would be to write an app to modify the project files but it would probably take longer to write and you would need to cater for subsequent code changes as every recompile would restore the original size settings.
- Status