How to stop Dialog moving out of client area of a Window

[RAMESHBABU]

Hi all

1) Is there any way to disable the "Move" from the System Menu of a
Dialog box ?

2) Can we ristrict a dialog movement beyond the Client area of a Window.

I tried in this way:

oDlg:bMoved := {|| oDlg:Move(72,4), SysRefresh() }

The Dialog box became movable beyond the client area, even though
the "DEFINE DIALOG oDlg OF oMainWindow:oClient" clause is used.

When the dialog is moved beyond the client area, the screen
underneath the dialog is getting erased and could not be restored.

Can anybody guide me to solve the above problem(s).

- Ramesh Babu P

[RAMESHBABU]

Hi all

Forget about my 2nd point in the posting. I resolved it.

Still for my academic interest, I keep my first point alive to be advised.

Thanks

- Ramesh Babu P

[RAMESHBABU]

Hi friends

In response to the 1st point of my own question, I came out with a solution as under.

The following function is very useful when you want to Disable the 'X'
button or 'Move' from system menu of a Dialog or a Window.

A small compilation of FWH functions together for a most needed purpose.

Regards,

- Ramesh Babu P


FUNCTION Diable_X_Move(oWinDlg, lDisableX, lDisable_Move)

LOCAL nCount := 0
LOCAL hMenu := 0
LOCAL cClass := oWinDlg:ClassName()

hMenu := GetSystemMenu(oWinDlg:hWnd, .F.)
nCount := GetMItemCount(hMenu)

IF lDisableX
// To Diable `X' Button of a Window or a Dialog
RemoveMenu( hMenu, nCount-1, nOR( MF_BYPOSITION) )
ENDIF

IF lDisable_Move
IF cClass != "TDIALOG"
// To Disable `Move' Menu Item in Dialog
RemoveMenu( hMenu, 1, nOR( MF_BYPOSITION) )
ELSE
// To Disable `Move' Menu Item in a Window
RemoveMenu( hMenu, nCount-2, nOR( MF_BYPOSITION) )
ENDIF
ENDIF

DrawMenuBar( oWinDlg:hWnd )

RETURN nil

[James Bott]

Ramesh,

When the dialog is moved beyond the client area, the screen
underneath the dialog is getting erased and could not be restored.

It sounds like you are diabling the move capability to cover up a programming problem rather to enhance the user's experience. This doesn't seem like a good solution.

I have never experienced a redraw problem when moving a dialog. This is usually handled automatically by Windows. Are you doing something unsual with the background that isn't redrawn?

James

[RAMESHBABU]

Mr.James

Thank you for your analysis. I have resolved the problem of client area,
undereneath the dialog, getting erased, when the dialog is moved.

>It sounds like you are diabling the move capability to cover up a
>programming problem rather to enhance the user's experience. This
>doesn't seem like a good solution.

Sorry!. It is not to cover up any problem as such. My application is
designed purely in SDI environment. And there is no need to move any
dialog(s) from their orginal places painted on the Client area of Main
Window. By disabling the Move, I am preventing my users to play with
the mouse to move the dialogs here and there. By doing so I don't think
that I am effecting the user's experience in windows.

Though it is not the Standard way of Windows, some times I feel it is not
wrong to such things like the way we always can't stick to ORMALISATION
rules while designing databses keeping the speed of the application in
mind.

Regards,

- Ramesh Babu P

[James Bott]

It is not to cover up any problem as such.

Sorry, my misunderstanding. I thought you wanted to do it because the background wasn't being repainted properly.

And there is no need to move any dialog(s) from their orginal places painted on the Client area of Main Window. By disabling the Move, I am preventing my users to play with the mouse to move the dialogs here and there. By doing so I don't think that I am effecting the user's experience in windows.

Well, personally, as a user, I would not like that one bit. I do like to move the dialogs even on SDI apps. Sometimes you need to move a dialog so you can see another app you are working with at the same time.

In my apps I even set them up to remember where the user last moved the dialog and it opens it in the same place the next time. My users like this.

Have you asked your users what they think about not being able to move the dialogs?

Though it is not the Standard way of Windows, some times I feel it is not wrong to such things like the way we always can't stick to ORMALISATION rules while designing databses keeping the speed of the application in mind.

While I don't disagree that sometimes one should violate the Windows standards, I think you should only do it if you have a really good reason.

James