Fixing a form on the screen

  • Thread starter Thread starter > Adrian
  • Start date Start date
A

> Adrian

How do I fix a form on the screen
using VS C# 2005. By "fixing" I mean that
the user cannot move the form about
on the display.

Thanks,
Adrian.
 
> Adrian said:
How do I fix a form on the screen
using VS C# 2005. By "fixing" I mean that
the user cannot move the form about
on the display.
Click to expand...

Not sure, but in native Win32 you'd do something like intercepting the
WM_MOVE messages and either ignoring them altogether, or resetting the
values before passing them to the default window proc. Probably there's
something similar you can do in .NET.

That said, use such a technique with great caution. It's pretty rude from a
user-interface perspective to put restraints on the user's ability to
configure their UI. If you are doing this, you should make sure it's for a
VERY VERY good reason.

Pete
 
Hi,

Thank you for your response. I tried something similar (below)
I put the code below the last line in xyz.designer.cs in VS C#.
That returns an error "Message could notbe found"
(are you missing a directive ... etc". Is there an answer to
this? This solution used to work well in VS 2003 by the way.

Adrian.

using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;

namespace TeleM
{
public class FixOnScreen: System.Windows.Forms.Form
{
public FixOnScreen()
{
base.WndProc (ref m);
}
private Message m;
private int WM_NCHITTEST = 0x0084;
private int HTCAPTION = 2;
private int HTNOWHERE = 0;
private int WM_SYSCOMMAND = 0x0112;
private System.Windows.Forms.Label label1;
private int SC_MOVE = 0xF010;

protected override void WndProc(ref Message m)
{
if(m.Msg == WM_NCHITTEST)
{
base.WndProc(ref m);
if((int)m.Result == HTCAPTION) m.Result = (IntPtr)HTNOWHERE;
return;
}
else if(m.Msg == WM_SYSCOMMAND && (m.WParam.ToInt32() & 0xFFF0) ==
SC_MOVE)
{
//Swallow the move request from the system menu
m.Result = IntPtr.Zero;
return;
}
}
}
}
 
Peter Duniho said:
"> Adrian <" <[email protected]> wrote in message
Click to expand...
That said, use such a technique with great caution. It's pretty rude from a
user-interface perspective to put restraints on the user's ability to
configure their UI. If you are doing this, you should make sure it's for a
VERY VERY good reason.

Pete
Click to expand...

Well I remember an application by Nero (in the past)
for copying cd's where you could move parts of the form
about and that turned their application into a heck of a
mess. I think it is up to the developer to do whatever he
thinks is necessary to create as much quality as he can,
and not be trapped by conventions which in the case in
hand would be dysfunctional. (In a philosophical sense
this has to do with norms and values being relative.
" .. pretty rude from a
user-interface perspective to put restraints on the user's ability to
configure their UI... "
Click to expand...
This is much too apodictic in my perception.)

Adrian.
 
> Adrian said:
Well I remember an application by Nero (in the past)
for copying cd's where you could move parts of the form
about and that turned their application into a heck of a
mess.
Click to expand...

If the user wants to create a mess, who are you to say they shouldn't? I
can't speak for Nero, but most applications that allow for customization of
the UI also provide a means to reset the UI to the original default.

That said, we're talking about the position of the application's window on
the desktop. There's a big difference between the question of allowing
customization *within* the application, and disabling the standard behavior
under a GUI operating system. Your original post appeared to be talking
about the latter, and the latter is simply bad behavior most of the time.
Applications should not in general do it, and if they do, they should have a
VERY VERY good reason (as I said).
I think it is up to the developer to do whatever he
thinks is necessary to create as much quality as he can,
and not be trapped by conventions which in the case in
hand would be dysfunctional.
Click to expand...

There is NOTHING dysfunctional about letting the user drag the application
window to any location on the screen he wishes.
This is much too apodictic in my perception.)
Click to expand...

How can anything be *too* apodictic? And if you find my statement
apodictic, why are you defending the practice of restraining the user?

Pete
 
Hi Peter,

In certain situations where a form is constructed
from constituent part-forms, I don't want the
part-forms to be moved about on the display.
Hence I block the ability of the user of my
application to move part-forms on the screen.

I think it is legitimate to modify the behavior
of a standard user interface, as long as the
effects are temporary, are limited to the
domain of the application proper, and do
not infringe upon any contractual obligation
that I have agreed to, explicitly or implied.

Adrian.
 
Hi Stoitcho,

Thank you for your response.
We are using the same code to fix a form on the screen.
I made a mistake in applying the code and got an error.
In the mean time I have rectified the cause of that error
and the app. is working fine now.

Many thanks,
Adrian.
 
> Adrian said:
[...]
I think it is legitimate to modify the behavior
of a standard user interface, as long as the
effects are temporary, are limited to the
domain of the application proper, and do
not infringe upon any contractual obligation
that I have agreed to, explicitly or implied.
Click to expand...

I agree with all of the above (especially the last clause...IMHO, probably
the most important), and it does sound as though you have a good reason to
fix the forms in their location (assuming the user has a way to move them
all as an aggregate).

It just was the case that none of that was clear in the original post, and
whether or not *you* have a good reason, other people may come across this
thread and think that generally it's okay to do what you ask, as opposed to
using it only in very specific, user-friendly situations. Even if it
doesn't apply in your case, I'm still glad I took the opportunity to point
out what I did. :)

Pete
 
(snipped)
other people may come across this
thread and think that generally it's okay to do what you ask, as opposed to
using it only in very specific, user-friendly situations.
(snipped)
Click to expand...

Actually I don't think this is the core issue at all. If someone writes
poor software, it won't sell, that will be his or her punishment.

The issue here is a legal one. Using an analogy: "Do I want
Another developer to write software that, when installed, will
muck about with my software that has also been installed?" My
answer would be "no", because legally that software is still
mine, the user having obtained user-rights only. In court I
might have a case against Another. In my perception
this is the only relevant issue, not whether the software
is user-friendly or not, for, as I said, the developer will
be punished in his purse for doing that.

Adrian.
 
> Adrian said:
[...]
The issue here is a legal one. Using an analogy: "Do I want
Another developer to write software that, when installed, will
muck about with my software that has also been installed?"
Click to expand...

I disagree. Neither of us were talking about writing software that affects
some other software. We're talking about the implementation of one's own
software. The issue you raise is valid, but not relevant to this thread.

And yes, you're right that really bad software simply won't succeed in the
marketplace. But there is software out there that is user-unfriendly and
yet succeeds in spite of its user interface. A bad UI is no guarantee of
market failure, and thus should be argued against at any opportunity.

Pete
 
Peter Duniho said:
> Adrian said:
[...]
The issue here is a legal one. Using an analogy: "Do I want
Another developer to write software that, when installed, will
muck about with my software that has also been installed?"
Click to expand...

I disagree. Neither of us were talking about writing software that affects
some other software. We're talking about the implementation of one's own
software. The issue you raise is valid, but not relevant to this thread.

And yes, you're right that really bad software simply won't succeed in the
marketplace. But there is software out there that is user-unfriendly and
yet succeeds in spite of its user interface. A bad UI is no guarantee of
market failure, and thus should be argued against at any opportunity.

Pete
Click to expand...
Peter,

You are quite wrong, fixing a form interferes
with Windows, belonging to Microsoft. So
theoretically Microsoft has a case.
Theoretically that is, because I don't expect
they would give two hoots.

There are no heavenly rules against writing
bad software, only economical ones: it
won't sell. The rest is lollipop.

Adrian.
 
> Adrian said:
You are quite wrong, fixing a form interferes
with Windows, belonging to Microsoft.
Click to expand...

What an odd reach of logic. Suffice to say, I disagree with your
perspective.
[...]
There are no heavenly rules against writing
bad software, only economical ones: it
won't sell. The rest is lollipop.
Click to expand...

I suppose that's true for someone with no sense of art in programming. Good
luck with that.

Pete
 
Back
Top