WORKAROUND: Screen.PrimaryScreen.WorkingArea

[Arcer P]

Situation 1 (erroneous):
TaskBar changes
Screen.PrimaryScreen.WorkingArea still returns the old rectangle

Situation 2 (OK)
TaskBar changes
Form Quits and Reloads
Screen.PrimaryScreen.WorkingArea 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****************@TK2MSFTNGP12.phx.gbl...

Situation 1 (erroneous):
TaskBar changes
Screen.PrimaryScreen.WorkingArea still returns the old rectangle

Situation 2 (OK)
TaskBar changes
Form Quits and Reloads
Screen.PrimaryScreen.WorkingArea 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.PrimaryScreen.WorkingArea 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 'SystemParametersInfo' 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 SystemParametersInfo Lib "user32" Alias "SystemParametersInfoA"
(ByVal uAction As Integer, ByVal uParam As Integer, ByRef lpvParam As RECT, ByVal fuWinIni As Integer) As Intege
//

\
Dim rectDesktop As REC

If (SystemParametersInfo(SPI_GETWORKAREA, 0, rectDesktop, 0) <> 0) The
Console.WriteLine("Desktop Working Width = " & CType(rectDesktop.Right - rectDesktop.Left, String)
Console.WriteLine("Desktop Working Height = " & CType(rectDesktop.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(ByVal sender As Object, ByVal e As
System.EventArgs) Handles MyBase.Click

Me.Text = Screen.PrimaryScreen.WorkingArea.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.SystemInformation.WorkingAre a' 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.PrimaryScreen.WorkingArea 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 'SystemParametersInfo' 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 SystemParametersInfo Lib "user32" Alias "SystemParametersInfoA" _
(ByVal uAction As Integer, ByVal uParam As Integer, ByRef lpvParam As RECT, ByVal fuWinIni As Integer) As Integer
///
\\
Dim rectDesktop As RECT

If (SystemParametersInfo(SPI_GETWORKAREA, 0, rectDesktop, 0) <> 0) Then
Console.WriteLine("Desktop Working Width = " & CType(rectDesktop.Right - rectDesktop.Left, String))
Console.WriteLine("Desktop Working Height = " & CType(rectDesktop.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.PrimaryScreen.WorkingA rea is not working
correctly.

Thanks
Jay

"Gary Milton" <an*******@discussions.microsoft.com> wrote in message
news:3E**********************************@microsof t.com...

Actually, don't use the p/invoke method. I just discovered that 'System.Windows.Forms.SystemInformation.WorkingAre a' 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.SystemInformation.WorkingAre a' 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****************@TK2MSFTNGP11.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(ByVal sender As Object, ByVal e As
System.EventArgs) Handles MyBase.Click

Me.Text = Screen.PrimaryScreen.WorkingArea.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.SystemInformation.WorkingAre a' works dynamically in the same way as the p/invoke method so use this instead.

Gary

[Arcer P]

How do you report to MicroSoft?
Jay B. Harlow [MVP - Outlook] wrote:

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****************@TK2MSFTNGP11.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(ByVal sender As Object, ByVal e As
System.EventArgs) Handles MyBase.Click

Me.Text = Screen.PrimaryScreen.WorkingArea.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?

[Jay B. Harlow [MVP - Outlook]]

Arcer,
MVPs, such as myself, have a channel available to us to report bugs.

For details on being or becoming an MVP see:
http://mvp.support.microsoft.com/

Hope this helps
Jay

"Arcer P" <[e-mail]> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...

How do you report to MicroSoft?
Jay B. Harlow [MVP - Outlook] wrote:

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****************@TK2MSFTNGP11.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(ByVal sender As Object, ByVal e As
System.EventArgs) Handles MyBase.Click

Me.Text = Screen.PrimaryScreen.WorkingArea.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?