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
How to stop Dialog moving out of client area of a Window
- RAMESHBABU
- Posts: 591
- Joined: Fri Oct 21, 2005 5:54 am
- Location: Secunderabad (T.S), India
- RAMESHBABU
- Posts: 591
- Joined: Fri Oct 21, 2005 5:54 am
- Location: Secunderabad (T.S), India
- RAMESHBABU
- Posts: 591
- Joined: Fri Oct 21, 2005 5:54 am
- Location: Secunderabad (T.S), India
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
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
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Ramesh,
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
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.When the dialog is moved beyond the client area, the screen
underneath the dialog is getting erased and could not be restored.
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
- Posts: 591
- Joined: Fri Oct 21, 2005 5:54 am
- Location: Secunderabad (T.S), India
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
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
- Posts: 4654
- Joined: Fri Nov 18, 2005 4:52 pm
- Location: San Diego, California, USA
- Contact:
Sorry, my misunderstanding. I thought you wanted to do it because the background wasn't being repainted properly.It is not to cover up any problem as such.
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.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.
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?
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.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.
James