WORKAROUND: Screen.PrimaryS creen.WorkingAr ea

[Arcer P]

Situation 1 (erroneous):
TaskBar changes
Screen.PrimaryS creen.WorkingAr ea still returns the old rectangle

Situation 2 (OK)
TaskBar changes
Form Quits and Reloads
Screen.PrimaryS creen.WorkingAr ea returns the new rectangle

How to correct the 1st situation?

[Jay B. Harlow [MVP - Outlook]]

Arcer,
What do you mean by "Form Quits & Reloads"?

I only see the WorkingArea change when the application itself quits &
reexecute it, that is when I am only changing the size of the TaskBar.

Or put another way: The WorkingArea is only updated for the DisplayChanged
event & app start. I would expect the WorkingArea to change if the size of
the TaskBar changes. Also I'm getting in consist changes on
DisplayChanged. ..

I'm not seeing anything in the KB about this, if you clarify what you are
seeing I will report it to MS.

Hope this helps
Jay

"Arcer P" <[e-mail]> wrote in message
news:OG******** ********@TK2MSF TNGP12.phx.gbl. ..

Situation 1 (erroneous):
TaskBar changes
Screen.PrimaryS creen.WorkingAr ea still returns the old rectangle

Situation 2 (OK)
TaskBar changes
Form Quits and Reloads
Screen.PrimaryS creen.WorkingAr ea returns the new rectangle

How to correct the 1st situation?

[Gary Milton]

Hi Arcer

It seems that you are right and it appears that the .NET Framework is caching the working screen size at application startup so if you change the working area after your application has been loaded (i.e. by increasing the size of the taskbar or adding the office shortcut bar etc.), Screen.PrimaryS creen.WorkingAr ea still returns the original cached size. I would suggest that this behaviour is probably a bug in the framework

A workaround would be to p/invoke the 'SystemParamete rsInfo' Win32 API which will get you the working area in realtime..

\
Private Const SPI_GETWORKAREA As Integer = 4

Private Structure REC
Public Left As Intege
Public Top As Intege
Public Right As Intege
Public Bottom As Intege
End Structur

Private Declare Function SystemParameter sInfo Lib "user32" Alias "SystemParamete rsInfoA"
(ByVal uAction As Integer, ByVal uParam As Integer, ByRef lpvParam As RECT, ByVal fuWinIni As Integer) As Intege
//

\
Dim rectDesktop As REC

If (SystemParamete rsInfo(SPI_GETW ORKAREA, 0, rectDesktop, 0) <> 0) The
Console.WriteLi ne("Desktop Working Width = " & CType(rectDeskt op.Right - rectDesktop.Lef t, String)
Console.WriteLi ne("Desktop Working Height = " & CType(rectDeskt op.Bottom - rectDesktop.Top , String)
End I
//

HTH
Gary

[Arcer P]

Jay B. Harlow [MVP - Outlook] wrote:

Arcer,
What do you mean by "Form Quits & Reloads"?

Step by step

1. Create a new solution with a single form

2. Write the Click event as follows:

Private Sub Form1_Click(ByV al sender As Object, ByVal e As
System.EventArg s) Handles MyBase.Click

Me.Text = Screen.PrimaryS creen.WorkingAr ea.ToString

End Sub
3. On the menu Debug click Start

4. Click the form that shows in the screen
and write down the form text (formely named caption)

5. Change the size and/or position of the task bar

6. Click the form again
notice that the form text did not change

7. Close the program

8. Start the program again

9. Click the form again
notice that the caption reflects the new screen working area


Is it clear now?

[Gary Milton]

Actually, don't use the p/invoke method. I just discovered that 'System.Windows .Forms.SystemIn formation.Worki ngArea' works dynamically in the same way as the p/invoke method so use this instead

Gar

[Arcer P]

Thank you very much for your sample code :)
I was not expecting to give so much trouble
Gary Milton wrote:

Hi Arcer,

It seems that you are right and it appears that the .NET Framework is caching the working screen size at application startup so if you change the working area after your application has been loaded (i.e. by increasing the size of the taskbar or adding the office shortcut bar etc.), Screen.PrimaryS creen.WorkingAr ea still returns the original cached size. I would suggest that this behaviour is probably a bug in the framework.

A workaround would be to p/invoke the 'SystemParamete rsInfo' Win32 API which will get you the working area in realtime...

\\
Private Const SPI_GETWORKAREA As Integer = 48

Private Structure RECT
Public Left As Integer
Public Top As Integer
Public Right As Integer
Public Bottom As Integer
End Structure

Private Declare Function SystemParameter sInfo Lib "user32" Alias "SystemParamete rsInfoA" _
(ByVal uAction As Integer, ByVal uParam As Integer, ByRef lpvParam As RECT, ByVal fuWinIni As Integer) As Integer
///
\\
Dim rectDesktop As RECT

If (SystemParamete rsInfo(SPI_GETW ORKAREA, 0, rectDesktop, 0) <> 0) Then
Console.WriteLi ne("Desktop Working Width = " & CType(rectDeskt op.Right - rectDesktop.Lef t, String))
Console.WriteLi ne("Desktop Working Height = " & CType(rectDeskt op.Bottom - rectDesktop.Top , String))
End If
///

HTH,
Gary

[Jay B. Harlow [MVP - Outlook]]

Gary,
Thanks for the work around!

I'm curious how well it works in a multi-monitor environment, as the
System.Windows. Forms.Screen object represents each monitor attached to your
computer.

Either way I will report something to MS as
System.Windows. Forms.Screen.Pr imaryScreen.Wor kingArea is not working
correctly.

Thanks
Jay

"Gary Milton" <an*******@disc ussions.microso ft.com> wrote in message
news:3E******** *************** ***********@mic rosoft.com...

Actually, don't use the p/invoke method. I just discovered that 'System.Windows .Forms.SystemIn formation.Worki ngArea' works dynamically in
the same way as the p/invoke method so use this instead.
Gary

[Arcer P]

Thanks again
I was about writting the same as you did
It seems to be a very strange behaviour

Do you know if VC++ has this behaviour too?
Gary Milton wrote:

Actually, don't use the p/invoke method. I just discovered that 'System.Windows .Forms.SystemIn formation.Worki ngArea' works dynamically in the same way as the p/invoke method so use this instead.

Gary

[Jay B. Harlow [MVP - Outlook]]

Arcer,

7. Close the program
8. Start the program again Thanks that is the part I needed, Gary gave a good work around.

I will report something to Microsoft.

Hope this helps
Jay

"Arcer P" <[e-mail]> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. .. Jay B. Harlow [MVP - Outlook] wrote:

Arcer,
What do you mean by "Form Quits & Reloads"?

Step by step

1. Create a new solution with a single form

2. Write the Click event as follows:

Private Sub Form1_Click(ByV al sender As Object, ByVal e As
System.EventArg s) Handles MyBase.Click

Me.Text = Screen.PrimaryS creen.WorkingAr ea.ToString

End Sub
3. On the menu Debug click Start

4. Click the form that shows in the screen
and write down the form text (formely named caption)

5. Change the size and/or position of the task bar

6. Click the form again
notice that the form text did not change

7. Close the program

8. Start the program again

9. Click the form again
notice that the caption reflects the new screen working area


Is it clear now?

[Arcer P]

Thanks
I was in a hurry and made an erroneous test
It works fine as well as your new approach
You are really kind

Gary Milton wrote:

Actually, don't use the p/invoke method. I just discovered that 'System.Windows .Forms.SystemIn formation.Worki ngArea' works dynamically in the same way as the p/invoke method so use this instead.

Gary