Getting the screen resolution as the system user

[mikejs]

This is probably more of a windows problem than a purebasic one, but I'll ask here in case anyone has run into it...

I have a PB program which generates desktop wallpaper, either for the user, or for the pre-login desktop. If the program is run interactively as a user with appropriate privileges, both the user and prelogin wallpaper can be generated and set just fine.

However, for various reasons, I need to replace the pre-login wallpaper once a day, and do so before the first user of the day comes up to the machine. So, I've tried running my program as a scheduled task, under the SYSTEM account, purely for the purpose of replacing the pre-login wallpaper.

When my program is run this way, DesktopWidth and DesktopHeight return different values for the screen resolution. In the case of my test machine, there is a single monitor connected via DVI, running at 1280x1024. DesktopWidth and DesktopHeight return 1280 and 1024 in normal use by a logged in user. When run by the scheduled task, they return 1024 and 768 respectively, even though the pre-login environment is 1280 x 1024. This results in a wallpaper of the wrong resolution being stretched to fit. (All on Win7 32bit. I've not tested on other OSs, as Win7 is where I need it to work.)

So, there seems to be something different about running as a scheduled task and/or as the system account. The only question is what is that difference and how do I find out the real screen res from that environment? Anyone run into this and have any words of wisdom?

The only thing I've thought of so far is a workaround - record the real resolution when a user is logged in, and use that, rather than looking it up on the fly, but that seems a bit hacky.

[happer66]

This is not an answer to your resolution question, but if you're doing the oembackground approach for the logon wallpaper you should be able to save several images with different resolutions and windows will pick the best suited one (depending on AR):
backgroundDefault.jpg (Default if no other suitable images are found (likely AR dependant)
background768x1280.jpg (0.6)
background900x1440.jpg (0.625)
background960x1280.jpg (0.75)
background1024x1280.jpg (0,8) (zero point eight became a smiley? )
background1280x1024.jpg (1.25)
background1024x768.jpg (1.33-)
background1280x960.jpg (1.33-)
background1600x1200.jpg (1.33-)
background1440x900.jpg (1.6)
background1920x1200.jpg (1.6)
background1280x768.jpg (1.66-)
background1360x768.jpg (1.770833-)

the same 256(?)KiB restriction applies to all images iirc.

[mikejs]

Thanks for this

It's actually (partly) because of problems with that mechanism that I'm trying to do things this way.

Win7 doesn't look for a jpg with a name matching the current resolution - it has a list of resolutions to look for, and if there isn't an exact match it tries to find one matching the aspect ratio, and if still nothing matches it falls back on backgroundDefault.jpg. Which would be fine except we have some monitors that run at 1680x1050, which isn't one of the resolutions it looks for. However that is an aspect ratio it looks for (1.6), so it usually picks a much smaller jpg and scales it up, which looks horrible, even if backgroundDefault.jpg is the right resolution.

So, what I was hoping to do was ensure that backgroundDefault.jpg was the only file present, and that it was the right resolution in the first place. (And that it's <256KB.)

The other reason for doing it this way is that I'm, planning on showing additional information on the pre-login bitmap, such as whether there are any bookings in that room today. (These are student computers in a university environment.) This is why I need to replace the pre-login wallpaper each day, before the first user of the day shows up, so that they see correct info before they log in. This all works, except for reading the current screen res from within a scheduled task that runs as SYSTEM.

Meanwhile, I've dug into the windows API to find other ways of getting the screen res, and these also return incorrect values when used inside that scheduled task but work fine when run as a normal user, so it's not PB at fault here, just windows being weird. Looks like recording the resolution elsewhere and not working it out on the fly in the scheduled task is the way to go.

[IdeasVacuum]

Looks like recording the resolution elsewhere and not working it out on the fly in the scheduled task is the way to go

I think that is the only way you can be certain that it is always correct, not at all 'hacky'.