Resolution Screen

Assuming you are on 10.2B or 11.x:

http://msdn.microsoft.com/en-us/library/system.windows.forms.screen.aspx

MESSAGE System.Windows.Forms.Screen:PrimaryScreen:Bounds:Width skip

System.Windows.Forms.Screen:PrimaryScreen:Bounds:Height

SESSION:WIDTH-PIXELS

SESSION:WORK-AREA-WIDTH-PIXELS

same for height of course.

Shouldn't it be a no-no to check for specific resolutions ?

I thought that resolution independent coding was best practice.

Of course, there may be compelling reasons ...

On 11 October 2012 14:50, Peter van Dam

Don't shoot the messenger

SESSION:WIDTH-PIXELS

SESSION:WORK-AREA-WIDTH-PIXELS

True - there are pure ABL functions. I always forget. We've been using the .NET ones because they allow to check the resolution of individual screens as well.

Shouldn't it be a no-no to check for specific resolutions ?

Criticizing without knowing the use case?

Many applications store window positions in the user profile. When restoring that the next time, I think it's best practice, if those stored location is actually on an available screen.

I don't want to code like those poor Infragistics Wizards that restore on the second monitor when there's only one available.

Thank you very much, guys!!

Yes , I'm working en 10.2b07 in .NET .

Criticizing without knowing the use case? 

nope. Hence the "they may be compelling reasons" .

Many applications store window positions in the user profile. When restoring that the next time, I think it's best practice, if those stored location is actually on an available screen.

True - but it would also work if the relative position was stored , not the absolute.

take this scenario. window is at x:400 , y:300 on a 1600x1200 screen

user now logs onto a 1024x768 screen, window is now not in the same relative position, despite having the same co-ordinates.

if you were to save the relative position (.25,.25) then the screen would be drawn in exactly the same relative position, regardless of the screen resolution

for #1 , it would be at 400,300

for #2, it would be 256,192

the benefit is that you don't need to check the resolution when restoring and the window will never be out of view.

the benefit is that you don't need to check the resolution when restoring and the window will never be out of view.

That's only part of the truth because you seem to ignore the size of the window. Some windows are resizable - others may not.

easy

for resizable windows, simply store the relative size as well and apply that on rendering.

for non-resizable, just position at the relative x:y (the top left of the window and titlebar will *always* be visible)

for non-resizable, just position at the relative x:y (the top left of the window and titlebar will always be visible)

Yes - the title may partly be visible. But that does not satisfy me or my customers.

jmls wrote:
Many applications store window positions in the user profile. When restoring that the next time, I think it's best practice, if those stored location is actually on an available screen.
True - but it would also work if the relative position was stored , not the absolute.
take this scenario. window is at x:400 , y:300 on a 1600x1200 screen
user now logs onto a 1024x768 screen, window is now not in the same relative position, despite having the same co-ordinates.
if you were to save the relative position (.25,.25) then the screen would be drawn in exactly the same relative position, regardless of the screen resolution
for #1 , it would be at 400,300
for #2, it would be 256,192
 
the benefit is that you don't need to check the resolution when restoring and the window will never be out of view.

This is an interesting approach Julian, I am going to look into this.

-peter

Yeah, getting a little picky here

a) if a window is resizable, then the whole window will be visible, and your argument is not valid.

b) if the window is fixed, let's take this contrived example, If you had a 800x600 non-resizable window on a 1600x1200 screen, positioned at 800:600 (ie. the window fits bottom right) and *then* logged onto a 800x600 resolution setting your window would still show over 50% of the contents, which is tad more than "partial".

If you didn't want to do that, then a single assign statement would be required to make the whole window visible.

Given that x and y are the positions of the window once placed relatively, then

assign x = x - max(0,x + window-width - session-width)
       y = y - max(0,y + window-height - session-height) *

and your whole window is shown. Of course, this will be broken if the window size is greater than the resolution, but as you or your customers never want to see a partial window, I expect this would never be an issue for you

c) Most windows would either be resizable (a) or small enough to fit into most resolutions without having to be moved to show full content. (we don't have any res less than 1024x768)

* yes, here we are accessing the session resolution, but never to check the size for any comparison (i.e. not saying if res is 800x600 then do something)

Given that x and y are the positions of the window once placed relatively, then

assign x = x - max(0,x + window-width - session-width)

y = y - max(0,y + window-height - session-height) *

Which is basically what we are doing.

But

a) It requires to know the screen resolution. So you've given yourself the use case you questioned in the beginning.

b) The world is a bit more complicated on multi-monitor systems (I use four in my office)