how to find out if windows is in classic mode

[Nifrabar]

Hi!

In my app I offer users the possibilty to have a form fill up the full screen.(Both form and controls width and height are multiplied based upon actual form size and current available screen size). Code for this is published in the book 1001 things you always wanted to know about VFP.

This works fine but when running in non-classic style it seems that forms show a border which is wider than the classic one. Due to that I need to do a correction.

Q:
How can I find out if windows is running in classic mode ?

-Bart

 

[Olaf Doschke]

I don't know, but sysmetric(3) and sysmetric(4) return 8, if I have aero style and 4 in classic mode.

So if the code you go already makes use of sysmetric(3) for border frame widths, then there's some flaw in the formula still. Why don't you post how you set width and height?

Actually form.windowstate = 2 (maximised) should take care of the max size of a form anyway, what does not work with that?

Bye, Olaf.

 

[Mike Lewis]

Bart,

Rather than trying to determine if you are running in Classic mode, it's better to avoid hard-coding the heights and widths of the various screen elements, and to determine these programmatically.

We discussed this topic the other day in another of your threads.

After all, it's not just a question of Classic vs non-Classic. There are possible themes that a user can choose that will affect this issue; and who knows what other settings might come along in the future.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

True Mike,

To make myself clearer: I don't suggest using sysmetric(3) and sysmetric(4) to detect classic vs aero design, but use them for including the frame width into the formula.

Mike also already showed in thread184-1674297, that the api function SystemParametersInfo offers a bit more than sysmetric(), so in regard to other elements contributing to the form size, this might help you to fully compute the space available for your form, but that should solely be made by taking all the current metrics into account and nothing else, then you don't have to worry about which design mode is active.

Bye, Olaf.

 

[Nifrabar]

Hi!
Here is the updated code from 1001 things used to determine the hor and vert ratio.
If I found a way to determine llClassicmode this would solve my problem.
But if you think I'm on a wrong way, well pls point me to it.

*FrmMaximize
LPARAMETERS tnHeight, tnWidth
LOCAL loControl, llClassicMode, lnHCorrect, lnWCorrect
WITH Thisform

llClassicMode = .T.

IF llClassicmode
	lnHCorrect = 16
	lnWCorrect = 8
ELSE
	lnHCorrect = 0
	lnWCorrect = 16
ENDIF 
	
	*** Determine the ratio needed to maximize the form
	*** depending on screen resolution and store it to form properties
	.WidthRatio 	= (_screen.width - lnWCorrect ) / tnWidth
* 50 down below is toolbarheight. Still to be converted by code 
	.HeightRatio 	= (_screen.height - 50 + lnHCorrect -SYSMETRIC(9) ) / tnHeight&& wintitle;menu;toolbar

	IF .WidthRatio > 1 OR .HeightRatio > 1
        .Top	= IIF(.AutoCenter  ,SYSMETRIC(22)/2-(.Height * .HeightRatio)/2 - SYSMETRIC(9)*2,0)
		.Left 	= IIF(.AutoCenter  ,SYSMETRIC(1)/2 -(.Width  * .WidthRatio) /2 ,0)
		.Width 	= .Width 	* .WidthRatio
		.Height = .Height 	* .HeightRatio
		*** And resize each control contained in the form
		FOR EACH loControl IN .Controls
			.ResizeControls( loControl )
		ENDFOR
	ENDIF
ENDWITH

-Bart

 

[Nifrabar]

In addition to the above:
Parameters tnHeight and tnWidth are the design values of the form which need to be resized.

HTH
-Bart

 

[Olaf Doschke]

Why don't you initially say you are using some kind of resizer?
Do yourself a favour and perhaps use mwResize instead.

If you still want to mend your code, well, then obviously you need sysmetric(3)*2 for lnWCorrect no matter what mode. And I'd say HCorrect is wrong to be 0 in aero mode, but should simply be sysmetric(4)*2.

The constant 50 in _screen.height - 50 + lnHCorrect -SYSMETRIC(9) is also suspicious to be replaced by something else depending on sysmetrics(). If that is for a toolbar, they can also differ in height and you can actually adress them to determine their current height or if they are docked at all.

Bye, Olaf.

 

[Nifrabar]

Olaf,
Sorry for any inconvenience but I started the threat with phrase:

In my app I offer users the possibilty to have a form fill up the full screen.(Both form and controls width and height are multiplied based upon actual form size and current available screen size).

For the records : this code has been tested with
- Windows XP
- Windows XP classic mode
- Windows 7
- Windows 7 classic mode
All works as expected.

*FrmMaximize
LPARAMETERS tnHeight, tnWidth ,tnToolbarHeight
LOCAL loControl, llClassicMode, lnHCorrect, lnWCorrect, lnToolbarheight
WITH Thisform
	lnWCorrect = sysmetric(3)*2
	lnHCorrect = sysmetric(4)*2
	lnToolbarheight = tnToolbarHeight
	
	*** Determine the ratio needed to maximize the form
	*** depending on screen resolution and store it to form properties
	.WidthRatio 	= (_screen.width  - lnWCorrect ) / tnWidth
	.HeightRatio 	= (_screen.height - lnHCorrect -lnToolbarheight -SYSMETRIC(9)) / tnHeight 

    .Top	= IIF(.AutoCenter  ,SYSMETRIC(22)/2-(.Height * .HeightRatio)/2 - SYSMETRIC(9)*2,0)
	.Left 	= IIF(.AutoCenter  ,SYSMETRIC(1)/2 -(.Width  * .WidthRatio) /2 ,0)
	.Width 	= .Width 	* .WidthRatio
	.Height = .Height 	* .HeightRatio

	*** And resize each control contained in the form
	FOR EACH loControl IN .Controls
		.ResizeControls( loControl )
	ENDFOR
ENDWITH

Anyway thanks to Olaf and Mike for spending time on this item which, as a result, solved my initial problem.

-Bart

 

[Olaf Doschke]

Both form and controls width and height are multiplied based upon actual form size and current available screen size.

Ok, this actually describes what a resizer module does, but it's harder to understand. Admitted, it's not a very long and winding description, but still i didn't get in the first place.

All you need is mwresize. I mention it once more, because of it's ease to use it: You drag an mwresize class on a form, add one line of code and it does the resizing automatically.

You find it at

http://www.ios.mu/prolib/VFP/mwResize50.zip

and it's nicely documented. In your special case of a form starting maximised, look into the zz_readme() method of the resizing class for what to do instead of setting windowstate=2

mwresize also can especially care about grid columns and activex controls, I don't know what the code from 1001 things does about these controls.

Besides: If your problem is a form maximised does grow over your toolbar, then simply dock the toolbar and the form will not overlap with it.

Bye, Olaf.

 

[Nifrabar]

Thanks for info.
Originally I search the net but could noy find a valid location to download mwResize from.
I tried and indeed a very handy resizer.
Going to dig further into it.
Thanks again!
-Bart

 

[Mike Lewis]

Bart,

I know this doesn't address your original question, but I must say that I would never use the resizer that was published in 1001 Things.

The main reason is that it blindly resizes every control in both directions. When you resize a form, you usually want to resize any edit boxes, grids, list boxes and images both horizontally and vertically. That's fine. But you will probably resize text boxes and combo boxes horizontally, but not vertically. Most other controls, like command buttons and labels, should not be resized at all.

The 1001 Things resizer is more like a zoom control than a resizing control. That's not what users expect. After all, why should a command button increase in size just because you are resizing the outer container? That doesn't happen in any other application I know of.

Also, I don't see the point of programming a resizer at all now that we have anchors. Is there any reason that you are not using anchors (assuming you have VFP 9)?

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

Mike,

true, also mwREsize is rather a zooming tool, including to rasie font sizes. That's what people sometimes rather want or are satisifed with.

Bye, Olaf.

 

[Nifrabar]

Mike,
I got the request from my users to get a kind of zoom-facility same as now-a-days in every office-appication is present.
As I have not been aware of the mwResize tool I used the one published in the 1001 book which solved my problem.
But mwResize is far better!

And yes, I do have VFP9. But did not take the opportunity to use the anchors.
Might also be a good solution but not sure how this deals with e.g. font-sizes.
-Bart

 

[Mike Lewis]

I disagree that users generally want to zoom rather than resize. And this kind of zooming is not a feature of other applications.

To illustrate, load Microsoft Word. Make the window fill half the screen. Look at the buttons on the menu bar or toolbar. Now maximise the window. The buttons don't double in size. But that's what the 1001 Things resizer does.

If the user does want the buttons and similar controls to be larger, the correct action is to change the screen settings in Control Panel. It shouldn't be the responsibility of the application.

I agree that users might want to view and edit text in a larger font size. I've nothing against that. But you don't achieve that by resizing the text's container. Again, look at Word. If you want to increase the font size, you don't resize the window.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Nifrabar]

Mike,
I fully agree on what you state but....
The client decides (more or less) what we have to produce.
And in this case my client prefers this way of zooming while many of his users are 65+ and they love the bigger controls.That's why they want the zoom-option.
Referring to the 1001 zoom facility, allthough I didnot test yet, it's quit easy to give controls an additional property which might act as a flag for resize yes/no.
But now that Olaf gave me the correct link to mwResize I will further use that one.
-Bart

 

[Mike Lewis]

The client decides (more or less) what we have to produce.

Well, that's a clinching argument.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy