Microsoft way, waaay too helpful

[Rick]

Gentlepeople:

With regard to the following code:

private void frmSendOrder_Load(object sender, EventArgs e)
{
if (!acceptWindowManagerPosition) {
this.Left = this.initialRight - this.Width;
this.Top = this.initialTop;
Rectangle r = Screen.FromControl(this).WorkingArea;
if (this.Left < r.Left) {
this.Left = r.Left;
}
if (this.Top < r.Top) {
this.Top = r.Top; // Point 1.
}
}
Point pt = PointToScreen(new Point(Left,Top) );
Console.WriteLine("%s", pt.ToString() );
}

At Point 1, if the dialog in question is partly off the screen to the
top, not only is Top changed, but Left is also changed. Apparently,
if I put the dialog right on the edge of the screen, Microsoft decides
to help me out and move out to where Microsoft thinks it should go.
Is this behavior documented somewhere?

Regards,

Rick

 

[Roger]

Hi,
Did you try setting the Form.StartPosition property
to an appropriate value?
Roger

 

[Peter Duniho]

[...] Apparently,
if I put the dialog right on the edge of the screen, Microsoft decides
to help me out and move out to where Microsoft thinks it should go.
Is this behavior documented somewhere?

If you've read the relevant documentation and you haven't seen it
mentioned, then the answer is probably "no".

But then, we don't really know what "behavior" it is you're specifically
talking about, because you haven't posted a concise-but-complete code
example that reliably demonstrates the problem. Certainly, I don't
think it's unreasonable for .NET to make an attempt to ensure that Forms
are always visible on-screen, but whether that's actually what's going
on here is not clear at all, nor do I recall whether that's part of the
behavior of a Form.

It's entirely possible that there's just a misinterpretation of
coordinates you're looking at.

For a better answer, or at least more-informed opinions, you should post
a concise-but-complete code example that clearly and reliably shows
exactly what it is you're asking about. What does the code do, what did
you expect it to do that's different, and why did you expect the
different behavior?

Pete

 

[Bert Hyman]

In Peter Duniho

[...] Apparently,
if I put the dialog right on the edge of the screen, Microsoft
decides to help me out and move out to where Microsoft thinks it
should go. Is this behavior documented somewhere?

If you've read the relevant documentation and you haven't seen it
mentioned, then the answer is probably "no".

Of course, determining a priori what documentation is "relevant" in any
given circumstance is practically impossible.

 

[Peter Duniho]

Of course, determining a priori what documentation is "relevant" in any
given circumstance is practically impossible.

That's odd. I use the MSDN documentation at least dozens of times a
day, and I almost never have any trouble at all figuring out, for a
given circumstance, what part of the documentation I need to read.

 

[Göran Andersson]

That's odd. I use the MSDN documentation at least dozens of times a
day, and I almost never have any trouble at all figuring out, for a
given circumstance, what part of the documentation I need to read.

Well, sometimes it's not that easy to find all the information needed.
Even if the documentation is complete, it's not overly repetetive, so
everything about a member is not collected in the documentation about
that member. You might have to look at the overview of the class or the
documentation for some other members to get all the information. If you
are not used to how the information is spread out, there are a lot of
wrong places to look...

 

[Rick]

I guess I haven't been clear enough as to what's happening. I have
annotated the code below, to show the values. The values are not
exact; they are from memory. But they will show you the idea.

I have a two-display arrangement. The right display is the "dominant"
display. It has the menu, and icons of running programs.

I placed the window of my application near the upper left corner of my
*left* display, in such a way that there was no room for the new form
to appear to the left of the top of the existing window, and stay on
the screen. When I adjusted my original window so that it was off the
screen to the top, I got the undesired behavior.

Here's the code I used to put up the 2nd window. Note that the
desired position for the new window is loaded into the object before
the window is created.

private void btnGenerateBuyOrder_Click(object sender,
EventArgs e)
{
DataGridView dg = dgIOIBuys;

if (dg.SelectedCells.Count != 0)
{
if (frmSendOrder == null)
frmSendOrder = new frmSendOrder();

frmSendOrder.initialRight = this.Left - 10;
frmSendOrder.initialTop = this.Top + 8;
frmSendOrder.acceptWindowManagerPosition = false;
frmSendOrder.ShowDialog(this);
}
}

And here's the method that is executed on the "load" event in the 2nd
window. I have marked what the values were, on the right of the
source code line.

private void frmSendOrder_Load(object sender, EventArgs e)
{
if (!acceptWindowManagerPosition) {
this.Left = this.initialRight - this.Width; -1400 =
-1200 - 200
this.Top = this.initialTop; -20 = -20
Rectangle r = Screen.FromControl(this).WorkingArea;
r = (Left=-1210, Top = 0, ...)
if (this.Left < r.Left) { -1400 < -1210
this.Left = r.Left; -1200 = 1200
}
if (this.Top < r.Top) { -20 < 0
this.Top = r.Top; // Point 1. 0 = 0
} When we investigated the value of this.Left at
this point using a tracepoint, it was about -900.
}
}

When I tried to assign the Top of the dialog box to be 0, Microsoft
apparently decided my positinoing needed to be adjusted. It moved the
dialog down about 300 pixels, and right about 200. Is this behavior
documented somewhere?


Regards,

Rick

 

[Tim Roberts]

And here's the method that is executed on the "load" event in the 2nd
window. I have marked what the values were, on the right of the
source code line.

private void frmSendOrder_Load(object sender, EventArgs e)
{
if (!acceptWindowManagerPosition) {
this.Left = this.initialRight - this.Width; -1400 =
-1200 - 200
this.Top = this.initialTop; -20 = -20
Rectangle r = Screen.FromControl(this).WorkingArea;
r = (Left=-1210, Top = 0, ...)
if (this.Left < r.Left) { -1400 < -1210
this.Left = r.Left; -1200 = 1200
}
if (this.Top < r.Top) { -20 < 0
this.Top = r.Top; // Point 1. 0 = 0
} When we investigated the value of this.Left at
this point using a tracepoint, it was about -900.

As soon as you assign "this.Left = r.Left;", the Move event will fire. Do
you happen to have a Move event handler that is fixing up the positioning?