dcsimg
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 37

Thread: Consternation over Small Font / Large Fonts

  1. #16
    Join Date
    Feb 2002
    Location
    Minnesota USA
    Posts
    35
    Quote Originally Posted by Cimperiali
    Wait a second:


    That is: how many twips to make a pixel? Unless you are comparing different
    kinds of system -like Os400 where character is the smallest unit for monitor vs
    pc ibm compliant , where it is pixel - that should be the same for whatever
    resolution you set. That is : at 600x400, you still have a pixel = around 15
    twips as at 800x600,....What changes is the size of screen, not the
    proportion between pixels and twips....[or was this the point of your post?]

    Twips is a unit of distance measurement. 1440 twips makes an inch.

    I think you miss the point I make about Microsoft's half baked implementation of the twips/pixel thing. On my 21" monitor I run 1600x1200 pixel layout and the twips numbers are 15 twips per pixel. I can switch the monitor to 800x600 and the raster size stays the same size. This means that my pixel density has just been reduced to half of its original amount in both the X & Y dimensions. Like wise my real DPI (dots per inch) is half what is used to be. My Twips/Pixel should have increased to 30 but is stays at 15!!

    Here is an interesting monkey wrench to throw into the gears however. Say I was working on a digital type display such as an LCD panel where a pixel cannot change size as they do on my CRT? Then we have a whole different senario!!

    Michael Karas

  2. #17
    Join Date
    Feb 2002
    Location
    Minnesota USA
    Posts
    35
    Quote Originally Posted by Cimperiali
    About independent screen resolution forms, you could look at this, if you
    did not already:
    http://support.microsoft.com/default...b;EN-US;182070
    where you can read something about fonts, and take some suggestments
    as per measures that are not perfect

    About a matter you can have when trying to get screen dimensions, I suggest
    you to read this:
    http://support.microsoft.com/default...b;en-us;253940
    where you can find a way to get measures when they do not want to be taken...
    I had read both of these Microsoft documents this weekend. It is largely the idea in the first one where the "design time" form size is captured into the code as a set of constants that I was able to finally get a properly scaled screen to work between various target machine configurations. I mentioned this in a posting above. I just have a bit of a dislike of having to embed these constants into the program like that. It seems that it would be so much better to be able to obtain those numbers from the form properites at run time.....but alas there is no way to achieve this.

    The system metrics information from the API do not seem to me to be any direct help either. What we really need to know is the algorithm that Microsoft uses in the Visual Basic 6 forms load routine to change the Form.Width and the Form.Height numbers from their design time values. If we knew the scheme then it is possible that the SystemMetrics data would help to let us roll back the translations made by the Visual Basic forms loader.

    Michael Karas

  3. #18
    Join Date
    Feb 2002
    Location
    Minnesota USA
    Posts
    35
    Quote Originally Posted by WizBang
    That's why I suggested making the change in Form_Load. Then you woudn't have to think about it. Although, leaving it in pixels makes it more convenient when using API calls. Of course, I'm no fan of twips, but this thread makes me think to avoid it all together.

    Is there some reason you need twips, either at design time or run time? (not that we know it solves the problem as yet)
    WizBang: The design time environment in VB always works in Twips as near as I know. It is not particularly feasible to change the scale mode of the form properites at design time to solve the fundamental problem I am dealing with here. By the time one's code gets to the Form_Load() event the VB6 form processor has already changed the Me.Height and Me.Width when the run time Twips/Pixel settings are different from the design time values. The VB6 loader also changes the Me.ScaleWidth and Me.ScaleHieght values to match the Me.Width and Me.Height numbers when the scale mode is set to Twips. So....no help there.

    I still need to run a test where I set the design time scale mode to pixels instead of twips and see if there is a change of behaviour between the development environment and the target environment. I suspect that there will be no change of behavior. After all the Form.Width and the Form.Height numbers always remain in twips and the scale stuff is mostly a way for VBs engine to do math instead of in the users program.

    Michael Karas

  4. #19
    Join Date
    Nov 2002
    Location
    Baby Land
    Posts
    646
    As far as I know the Width and Height property is the window size of the form including the titlebar and the border of the form, while the ScaleWidth and ScaleHeight is the internal size of the form (the client area of the window without the titlebar and border).

    Judging from the figures you gave, 9744x7344, then you have an extra 12 pixels added to the Width and height property. Perhaps you could test the ScaleWidth and ScaleHeight to see whether it also grow by 12 pixels. Usually the client area is constant while the Non client area is changing according to user settings.

    I cannot test this because I was unable to reproduce the behaviour on my WinXP.
    On my machine I got constant value for the Non client area (ScaleWidth and ScaleHeight, but the Width and Height is changed by 3 pixels) whether I use Normal or Large font setting.
    Last edited by Luthv; August 18th, 2004 at 02:06 AM.

  5. #20
    Join Date
    Dec 2001
    Posts
    6,332
    Quote Originally Posted by MJ_Karas
    Did you go to the advanced screen properties and change the Display Font Size?
    Yes, I did.

    Please try this simple example. Compile it as is and see how it works for both font sizes.
    Attached Files Attached Files
    Please remember to rate the posts and threads that you find useful.
    How can something be both new and improved at the same time?

  6. #21
    Join Date
    Dec 2001
    Posts
    6,332
    I think perhaps this is more like what you want. It allows you to simply place controls on the form in the usual manner, and it will automatically resize and reposition them according to the design time ratios. It **should** work in either twips or pixels, but I can't say with any certainty what will happen if you change the font size while the app is running. My guess is it would throw things off if it is in twips.
    Attached Files Attached Files
    Please remember to rate the posts and threads that you find useful.
    How can something be both new and improved at the same time?

  7. #22
    Join Date
    Feb 2002
    Location
    Minnesota USA
    Posts
    35
    Quote Originally Posted by Luthv
    Judging from the figures you gave, 9744x7344, then you have an extra 12 pixels added to the Width and height property. Perhaps you could test the ScaleWidth and ScaleHeight to see whether it also grow by 12 pixels. Usually the client area is constant while the Non client area is changing according to user settings.

    I cannot test this because I was unable to reproduce the behaviour on my WinXP.
    On my machine I got constant value for the Non client area (ScaleWidth and ScaleHeight, but the Width and Height is changed by 3 pixels) whether I use Normal or Large font setting.
    In my case the target applications run full screen with no borders, no title bars, and of course the control button boxes are all turned off and gone with the title bars. The appliction is being designed this way because the screens are meant to work more line a POS type application with a touch panel over the LCD display. When configured this way the form size and the scale size values track 1::1.

    You may have however hit on something regarding the extra 12 pixels. It could be that there is some kind of small bug in the VB6 forms processing loader that does not take into account all of the form features that I have turned off.

    In my application the user is unable to change the screen size at run time or to re-configure Windows under the application.

    Michael Karas

  8. #23
    Join Date
    Feb 2002
    Location
    Minnesota USA
    Posts
    35
    Quote Originally Posted by WizBang
    I think perhaps this is more like what you want. It allows you to simply place controls on the form in the usual manner, and it will automatically resize and reposition them according to the design time ratios. It **should** work in either twips or pixels, but I can't say with any certainty what will happen if you change the font size while the app is running. My guess is it would throw things off if it is in twips.
    I'll try out your little form app later today and post back here in the next 24 hours what the result was. Thanks for sharing your test with us.

    Michael Karas

  9. #24
    Join Date
    Feb 2002
    Location
    Minnesota USA
    Posts
    35
    Quote Originally Posted by MJ_Karas
    I'll try out your little form app later today and post back here in the next 24 hours what the result was. Thanks for sharing your test with us.

    Michael Karas
    WhizBang:
    I loaded your little applett and played with it a little. Functionally it works great on either machine environment.

    However.....On my 1600x1200 small fonts machine I adjusted the form size so that the scale mode size set at Pixels was ScaleWidth=500 and ScaleWidth=300.

    I then took the same project & form file to the 800x600 large fonts machine and did a breakpoint in the Form_Load() routine. I found that the Me.ScaleMode was still set to pixels. Also the Me.ScaleWidth had been changed to 625 and the Me.ScaleHeight has been changed to 375. So at least for using VB6 under Win2K there is still no change to the stuff I have been commmenting about.

    The real problem all along for me has been that the design time size I was working with was meant to map directly to a full screen 800x600 that most of my target machines run with. When it is mapped this way the screen comes up (if dynamic scaling is not done in the Form_Load() routine) then the screen image blows up way bigger than the full screen. Since I have no borders, title bars, control boxes, or resize buttons it is not possible to engage the user in re-fitting the screen.

    I still need to try to find out why the Me.Width and Me.Height are getting changed from their design time values.

    Michael Karas

  10. #25
    Join Date
    Dec 2001
    Posts
    6,332
    Interesting. Did you try the same thing in twips? Although I'm not so sure that it means anything to load the actual project into vb on the machine with large fonts. Heres why:

    I just did a small test. I tried to set the form size to something larger than the size of the screen, but vb doesn't allow it! Now, I'm wondering if you are setting the form to maximized at design time. If so, then perhaps this is effecting how the size of the form is adjusted. It might be worth setting the form to normal, and do the maximizing in the Form_Load.
    Please remember to rate the posts and threads that you find useful.
    How can something be both new and improved at the same time?

  11. #26
    Join Date
    Feb 2002
    Location
    Minnesota USA
    Posts
    35
    Quote Originally Posted by WizBang
    Interesting. Did you try the same thing in twips? Although I'm not so sure that it means anything to load the actual project into vb on the machine with large fonts. Heres why:

    I just did a small test. I tried to set the form size to something larger than the size of the screen, but vb doesn't allow it! Now, I'm wondering if you are setting the form to maximized at design time. If so, then perhaps this is effecting how the size of the form is adjusted. It might be worth setting the form to normal, and do the maximizing in the Form_Load.
    Setting the scale units to twips generated the same results. I also made an EXE and ran the program on the target that way and got the same results.

    I do not "maximize" the form at design time. It is left set to normal and I scale it to the desired size at run time in the Form_Load() routine. I did not defer the scaling to the Resize() routine like you did becasue I have no need for real time user drag type resizing. I just shoot to full screen, without borders and title bars, for use under a touch screen (where incidently the drag operations is next to impossible with a finger anyway).

    In the examples I first talked about here I had made the forms at design time be 800x600 equivalent size under the 15 twips per pixel environment. The VB form stores the actual form properities in the Size and Length properites in twips units at 12000x9000. At the target machine where the environment is 12 twips per pixel the form has the "appearance" of looking like it is actually 1000x750 pixels which is of course bigger than the target 800x600 environment. As I reported before the run time form size is scaled back to 9744x7344 twips.

    You may have hit upon something in guessing that the VB form processor does not like a form size bigger than the screen size......but 800x600pixels with 12 twips/pixel is 9600x7200 twips...smaller than the size VB scaled my form back to.

    This was the reason I tried to set your small applet to less than the size of the target screen. As I indicated I set it for 300x500 pixels (the equivalent in twips) and then when I ran it on the target environment the equivalent pixel size was changed to 625x375. Of course your applet's form has a border and title block so the VB form loader may be doing some other unexplained things whilst it goes about trying to change things....much to my continued consternation.

    Please keep in mind that I have worked out a system to scale the form so I can get on with my project. That required embedding some constants into the VB source code to track the original total form size so I can scale the controls in ratio to the original form size and not the changed Me.Width and Me.Height values I get at run time in the Form_Load() routine. As I stated before I do note that the size of all the controls on my form are still at their unmodified design time sizes in the initial Form_Load() event.

    I see from your little applett that you are saving the size of all the controls into an array in Form_Load() and then deferring any scaling to the re-size event. I did not look closely enough yet at the applet at run time on my target machine to see if the reported sizes of all the controls are at their original design time sizes/locations or if they have been changed. (If they have been changed then maybe I need to figure out what is different from what I am doing). After all if the reported size/position of the controls had been changed originally in my program so that it had tracked the changes in the reported form size itself then I would not have had the consternation I was suffering with....and I could have avoided the detail to embed the design time size constants into mu VB source code.

    If I get time later today I'll look at the above details and report back here.

    In the mean time are you interested in looking at a simplified version of my source code?

    Michael Karas

  12. #27
    Join Date
    Feb 2002
    Location
    Minnesota USA
    Posts
    35

    Discovery

    I just came to learn something I did not before realize. This discovery may change everything !!

    I see that when the Scale.Mode of the form itself is changed from twips to pixels that the sizes of all the controls in the design time properties sheets are changed to pixel sizes!!! Dah! How did I miss this before???

    So now I need to go re-work my form scaling along these lines. It may be that using Me.ScaleWidth and Me.ScaleHeight as the form size at Form_Load() is the essential difference that I have missed. All along I have been using Me.Width and Me.Height.

    I'll make these changes and see if it allows me to get rid of the embedded constants in the VB source code.

    Michael Karas

  13. #28
    Join Date
    Jul 2000
    Location
    Milano, Italy
    Posts
    7,726

    keep us updated

    This thread is extremely interesting.

    Keep us updated on final solution.

    Cesare
    ...at present time, using mainly Net 4.0, Vs 2010



    Special thanks to Lothar "the Great" Haensler, Chris Eastwood , dr_Michael, ClearCode, Iouri and
    all the other wonderful people who made and make Codeguru a great place.
    Come back soon, you Gurus.

  14. #29
    Join Date
    Dec 2001
    Posts
    6,332
    Quote Originally Posted by MJ_Karas
    ...I see that when the Scale.Mode of the form itself is changed from twips to pixels that the sizes of all the controls in the design time properties sheets are changed to pixel sizes!!! Dah! How did I miss this before???

    So now I need to go re-work my form scaling along these lines. It may be that using Me.ScaleWidth and Me.ScaleHeight as the form size at Form_Load() is the essential difference that I have missed. All along I have been using Me.Width and Me.Height...
    You're kidding, right? Well, this is why I stated some of the various things I did. Now, with the ScaleWidth and ScaleHeight in mind, it might be beneficial to re-read this thread and see if you get anything out of it which you hadn't before. Also, in case you are not aware, the resize event will fire when the form is loaded. The example I posted takes the sizes before the resize event, and even if the form size isn't what it is supposed to be, the ratio of the form and the controls should not be changing, so it won't matter if the form size isn't right. This is why I asked if the form was being maximized at Form_Load, because it lets vb set the size and the resize event can handle the controls, since it is AFTER the form is done resizing.
    Please remember to rate the posts and threads that you find useful.
    How can something be both new and improved at the same time?

  15. #30
    Join Date
    Jul 2000
    Location
    Milano, Italy
    Posts
    7,726
    Quote Originally Posted by WizBang
    You're kidding, right? Well, this is why I stated some of the various things I did
    Let's wait, WizBang...
    ...at present time, using mainly Net 4.0, Vs 2010



    Special thanks to Lothar "the Great" Haensler, Chris Eastwood , dr_Michael, ClearCode, Iouri and
    all the other wonderful people who made and make Codeguru a great place.
    Come back soon, you Gurus.

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)