Prevent a window from moving when taskbar gets autohide disabled.

I have a windows form that shifts position when the taskbar autohide property
is disabled. The windows does not move back to the original position when
the autohide property is turned back on.

I have not been able to catch the position changing anywhere in my code and
so I am thinking that it is taking place inside the Form class. I have tried
the Locked property for my form but it doesn't make a difference.

Any suggestions?

Thanks,
Ken

Stoitcho
Tue Apr 24 09:53:59 CDT 2007

Hi,

I created a winform application that has simply an empty form. I can't
reproduce your problem. My windows doesn't move and stays pinned to its
location. That makes me thing that either your code does something or I
don't understand your problem correctly. Can you post some compilable sample
code that demostrates the problem?


--
Stoitcho Goutsev (100)

"KenDev" <KenDev@discussions.microsoft.com> wrote in message
news:D6796E0E-9F96-47AF-913F-38B848E8C11C@microsoft.com...
>I have a windows form that shifts position when the taskbar autohide
>property
> is disabled. The windows does not move back to the original position when
> the autohide property is turned back on.
>
> I have not been able to catch the position changing anywhere in my code
> and
> so I am thinking that it is taking place inside the Form class. I have
> tried
> the Locked property for my form but it doesn't make a difference.
>
> Any suggestions?
>
> Thanks,
> Ken

KenDev
Tue Apr 24 11:02:05 CDT 2007

Hello,

I have come to the same conclusion that somehow our code overrides what
seems to be the default behavior (my test app/form reacted the same as
yours). I have tried to find in our code where the location is changed, but
to no avail. I thought maybe the Locking property would override what was
happening, but that didn't work either.

We have a suite of applications that use another application to switch
between them (using the entire desktop). The app forms are four levels deep
in inheritance too. It would be hard to create a compilable sample to
demonstrate the problem.

The problem did not show up in previous versions of our software because the
apps prevented the taskbar from showing.

Thanks,

Ken

"Stoitcho Goutsev (100)" wrote:

> Hi,
>
> I created a winform application that has simply an empty form. I can't
> reproduce your problem. My windows doesn't move and stays pinned to its
> location. That makes me thing that either your code does something or I
> don't understand your problem correctly. Can you post some compilable sample
> code that demostrates the problem?
>
>
> --
> Stoitcho Goutsev (100)
>

Stoitcho
Tue Apr 24 13:13:57 CDT 2007

Ken,

What is this Locking property you mention in both of your posts?


--
Stoitcho Goutsev (100)

"KenDev" <KenDev@discussions.microsoft.com> wrote in message
news:5A96944F-D157-49DA-99DC-7181397AAA66@microsoft.com...
> Hello,
>
> I have come to the same conclusion that somehow our code overrides what
> seems to be the default behavior (my test app/form reacted the same as
> yours). I have tried to find in our code where the location is changed,
> but
> to no avail. I thought maybe the Locking property would override what was
> happening, but that didn't work either.
>
> We have a suite of applications that use another application to switch
> between them (using the entire desktop). The app forms are four levels
> deep
> in inheritance too. It would be hard to create a compilable sample to
> demonstrate the problem.
>
> The problem did not show up in previous versions of our software because
> the
> apps prevented the taskbar from showing.
>
> Thanks,
>
> Ken
>
> "Stoitcho Goutsev (100)" wrote:
>
>> Hi,
>>
>> I created a winform application that has simply an empty form. I can't
>> reproduce your problem. My windows doesn't move and stays pinned to its
>> location. That makes me thing that either your code does something or I
>> don't understand your problem correctly. Can you post some compilable
>> sample
>> code that demostrates the problem?
>>
>>
>> --
>> Stoitcho Goutsev (100)
>>
>

KenDev
Tue Apr 24 14:52:02 CDT 2007

Forgive me. I meant the "Locked" property. It shows in the properties box
when you have a System.Windows.Forms.Form derived object selected in the
Designer window. The help text at the bottom of the properties box states
"The Locked property determines if we can move or resize the control."

(However, I cannot find the Locked property in the documentation for Form or
any of its base classes.)

/ken

"Stoitcho Goutsev (100)" wrote:

> Ken,
>
> What is this Locking property you mention in both of your posts?
>
>
> --
> Stoitcho Goutsev (100)
>
> "KenDev" <KenDev@discussions.microsoft.com> wrote in message
> news:5A96944F-D157-49DA-99DC-7181397AAA66@microsoft.com...
> > Hello,
> >
> > I have come to the same conclusion that somehow our code overrides what
> > seems to be the default behavior (my test app/form reacted the same as
> > yours). I have tried to find in our code where the location is changed,
> > but
> > to no avail. I thought maybe the Locking property would override what was
> > happening, but that didn't work either.
> >
> > We have a suite of applications that use another application to switch
> > between them (using the entire desktop). The app forms are four levels
> > deep
> > in inheritance too. It would be hard to create a compilable sample to
> > demonstrate the problem.
> >
> > The problem did not show up in previous versions of our software because
> > the
> > apps prevented the taskbar from showing.
> >
> > Thanks,
> >
> > Ken
> >
> > "Stoitcho Goutsev (100)" wrote:
> >
> >> Hi,
> >>
> >> I created a winform application that has simply an empty form. I can't
> >> reproduce your problem. My windows doesn't move and stays pinned to its
> >> location. That makes me thing that either your code does something or I
> >> don't understand your problem correctly. Can you post some compilable
> >> sample
> >> code that demostrates the problem?
> >>
> >>
> >> --
> >> Stoitcho Goutsev (100)
> >>
> >
>
>
>

Stoitcho
Wed Apr 25 08:12:03 CDT 2007

Ken,

Locked property is design time property and doesn't exist in runtime (it is
not part of the class). It works only on the design surface in order to
prevent controls from unintentional moving or resizing.


--
Stoitcho Goutsev (100)

"KenDev" <KenDev@discussions.microsoft.com> wrote in message
news:AF4BD0FF-80C2-4CF2-A88E-FD889C72C160@microsoft.com...
> Forgive me. I meant the "Locked" property. It shows in the properties
> box
> when you have a System.Windows.Forms.Form derived object selected in the
> Designer window. The help text at the bottom of the properties box states
> "The Locked property determines if we can move or resize the control."
>
> (However, I cannot find the Locked property in the documentation for Form
> or
> any of its base classes.)
>
> /ken
>
> "Stoitcho Goutsev (100)" wrote:
>
>> Ken,
>>
>> What is this Locking property you mention in both of your posts?
>>
>>
>> --
>> Stoitcho Goutsev (100)
>>
>> "KenDev" <KenDev@discussions.microsoft.com> wrote in message
>> news:5A96944F-D157-49DA-99DC-7181397AAA66@microsoft.com...
>> > Hello,
>> >
>> > I have come to the same conclusion that somehow our code overrides what
>> > seems to be the default behavior (my test app/form reacted the same as
>> > yours). I have tried to find in our code where the location is
>> > changed,
>> > but
>> > to no avail. I thought maybe the Locking property would override what
>> > was
>> > happening, but that didn't work either.
>> >
>> > We have a suite of applications that use another application to switch
>> > between them (using the entire desktop). The app forms are four levels
>> > deep
>> > in inheritance too. It would be hard to create a compilable sample to
>> > demonstrate the problem.
>> >
>> > The problem did not show up in previous versions of our software
>> > because
>> > the
>> > apps prevented the taskbar from showing.
>> >
>> > Thanks,
>> >
>> > Ken
>> >
>> > "Stoitcho Goutsev (100)" wrote:
>> >
>> >> Hi,
>> >>
>> >> I created a winform application that has simply an empty form. I can't
>> >> reproduce your problem. My windows doesn't move and stays pinned to
>> >> its
>> >> location. That makes me thing that either your code does something or
>> >> I
>> >> don't understand your problem correctly. Can you post some compilable
>> >> sample
>> >> code that demostrates the problem?
>> >>
>> >>
>> >> --
>> >> Stoitcho Goutsev (100)
>> >>
>> >
>>
>>
>>

KenDev
Wed May 23 11:04:06 CDT 2007

I can repeat the problem by creating a windows application. I move the
application so that it extends into the area where the taskbar will display
(it is in autohide). I change the taskbar properties to disable autohide,
and voila, the application moves so that it is not covered at all by the
taskbar.

If the window is maximized to consume the entire screen, it does not move
(though it resizes to account for the taskbar height). If I size the window
to screen resolution, it does not move or resize (but if I maximize it, it
does resize).

My application does not take the whole screen, so the taskbar moves it.
Previously, the taskbar did not even show (still looking at that one). I
can override the OnMove and OnResize, to keep the window at the same
location, but there is some flashing of the window in the moved location.

Ken

"Stoitcho Goutsev (100)" wrote:

> Ken,
>
> Locked property is design time property and doesn't exist in runtime (it is
> not part of the class). It works only on the design surface in order to
> prevent controls from unintentional moving or resizing.
>
>
> --
> Stoitcho Goutsev (100)
>
> "KenDev" <KenDev@discussions.microsoft.com> wrote in message
> news:AF4BD0FF-80C2-4CF2-A88E-FD889C72C160@microsoft.com...
> > Forgive me. I meant the "Locked" property. It shows in the properties
> > box
> > when you have a System.Windows.Forms.Form derived object selected in the
> > Designer window. The help text at the bottom of the properties box states
> > "The Locked property determines if we can move or resize the control."
> >
> > (However, I cannot find the Locked property in the documentation for Form
> > or
> > any of its base classes.)
> >
> > /ken
> >
> > "Stoitcho Goutsev (100)" wrote:
> >
> >> Ken,
> >>
> >> What is this Locking property you mention in both of your posts?
> >>
> >>
> >> --
> >> Stoitcho Goutsev (100)
> >>
> >> "KenDev" <KenDev@discussions.microsoft.com> wrote in message
> >> news:5A96944F-D157-49DA-99DC-7181397AAA66@microsoft.com...
> >> > Hello,
> >> >
> >> > I have come to the same conclusion that somehow our code overrides what
> >> > seems to be the default behavior (my test app/form reacted the same as
> >> > yours). I have tried to find in our code where the location is
> >> > changed,
> >> > but
> >> > to no avail. I thought maybe the Locking property would override what
> >> > was
> >> > happening, but that didn't work either.
> >> >
> >> > We have a suite of applications that use another application to switch
> >> > between them (using the entire desktop). The app forms are four levels
> >> > deep
> >> > in inheritance too. It would be hard to create a compilable sample to
> >> > demonstrate the problem.
> >> >
> >> > The problem did not show up in previous versions of our software
> >> > because
> >> > the
> >> > apps prevented the taskbar from showing.
> >> >
> >> > Thanks,
> >> >
> >> > Ken
> >> >
> >> > "Stoitcho Goutsev (100)" wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I created a winform application that has simply an empty form. I can't
> >> >> reproduce your problem. My windows doesn't move and stays pinned to
> >> >> its
> >> >> location. That makes me thing that either your code does something or
> >> >> I
> >> >> don't understand your problem correctly. Can you post some compilable
> >> >> sample
> >> >> code that demostrates the problem?
> >> >>
> >> >>
> >> >> --
> >> >> Stoitcho Goutsev (100)
> >> >>
> >> >
> >>
> >>
> >>
>
>
>