|
One solution is EnableMenuItem().
GetSystemMenu(FALSE)->EnableMenuItem(SC_CLOSE, MF_DISABLED);
Kuphryn
|
|
|
|
|
The problem I have with this approach is that as a child window, there is no system menu for it, and I get an unhandled exception. This is when I put these statements in the OnCreate handler of the child window.
When I put this in for the main frame, then indeed it does disable the close, but for the main window, not for the child.
Thanks,
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
That should work anyways. See the doc for CWnd::GetSystemMenu.
CWnd::GetSystemMenu
CMenu* GetSystemMenu( BOOL bRevert ) const;
Return Value
Identifies a copy of the Control menu if bRevert is FALSE. If bRevert is TRUE, the return value is undefined.
The returned pointer may be temporary and should not be stored for later use.
Parameters
bRevert
Specifies the action to be taken. If bRevert is FALSE, GetSystemMenu returns a handle to a copy of the Control menu currently in use. This copy is initially identical to the Control menu but can be modified. If bRevert is TRUE, GetSystemMenu resets the Control menu back to the default state. The previous, possibly modified, Control menu, if any, is destroyed. The return value is undefined in this case.
Remarks
Allows the application to access the Control menu for copying and modification.
Any window that does not use GetSystemMenu to make its own copy of the Control menu receives the standard Control menu.
The pointer returned by the GetSystemMenu member function can be used with the CMenu::AppendMenu, CMenu::InsertMenu, or CMenu::ModifyMenu functions to change the Control menu.
The Control menu initially contains items identified with various ID values such as SC_CLOSE, SC_MOVE, and SC_SIZE. Items on the Control menu generate WM_SYSCOMMAND messages. All predefined Control-menu items have ID numbers greater than 0xF000. If an application adds items to the Control menu, it should use ID numbers less than F000.
Windows may automatically dim items on the standard Control menu. CWnd can carry out its own checking or dimming by responding to the WM_INITMENU messages, which are sent before any menu is displayed.
John
|
|
|
|
|
You should be able to create a system menu. In the PreCreate() function add the style for the system menu, then disable the clost button which was explained by the other users.
hope this helps (I'm not sure it will though  )
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
take a look at my homepage under:
http://www.code-diary.com/HTML/Diary/0001.htm
greets,
Jason
|
|
|
|
|
Hi
I have a little, but pain-in-the-ass type of problem.
I virtually override the OnCancel() function:
'virtual void OnCancel()'
Then at the implementation
void CMyStupidDialogName::OnCancel()
{
::AfxMessageBox("ONCANCEL");
}
I've added the (X) button on the dialog. I press that standard (X) button in the right corner of the dialog and my code isn't executed (oncancel).
Isn't pressing that button equal to canceling?
|
|
|
|
|
Anonymous wrote:
Isn't pressing that button equal to canceling?
No. It returns the IDCANCEL value from DoModal(), but OnCancel() is not called.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
It's isn't called the 'close' button for nothing 
maybe you should override the OnClose() function...
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
ah damned
your right (like always )
uhm .. it's getting time for weekend i would say 
Thanks for the help 
|
|
|
|
|
well i will have to disappoint you all guys
i've overwriten the onclose() one like this:
void CMyStupidDialogName::OnClose()
{
app->bClosed = true;
CDialog::OnClose();
}
i debug (run to cursor) and you were right the onclose part is executed but the form is still not closed.
|
|
|
|
|
So you added a close button ON the dialog in addition to the standard close button?
If I'm correct, try the following:
the declaration in CMyStupidDialogName
afx_msg void OnYourButtonPressed();
the implementation
void CMyStupidDialogName::OnYourButtonPressed()
{
PostQuitMessage(-1);
}
map that function to the button this way:
DECLARE_MESSAGE_MAP(CMyStupidDialogName, CDialog)
ON_BN_CLICKED(YOUR_BUTTON_ID, CMyStupidDialogName::OnYourButtonPressed)
END_MESSAGE_MAP()
this should work if it doesn't, slap me
A student knows little about a lot.
A professor knows a lot about little.
I know everything about nothing.
|
|
|
|
|
Hello
Your problem is that you forgot to call the default handler for OnCancel().
void CMyStupidDialogName::OnCancel()<br />
{<br />
::AfxMessageBox("ONCANCEL");<br />
CDialog::OnCancel();<br />
}
Isaac Inyang
Ansyl Technologies
|
|
|
|
|
Can someone explain what the vc++ compiler does in these two
particular instances:
Scenario #1:
I have an inline function, let's call it InlineFunction(). It will
return type int and accesses a private member variable of a particular
class. It is a public member function of the same class, MyClass...
Now consider the following lines of code:
void main()
{
MyClass ThisClass;
cout << ThisClass.InlineFunction() << endl;
return 0;
}
Scenario #2
Same as above, only we assign the value of
InlineFunction to a variable:
void main()
{
MyClass ThisClass;
int temp;
temp = ThisClass.InlineFunction();
cout << temp << endl;
return 0;
}
Can anyone tell me how the compiler handles the inline function
in the two different scenarios? I realize that it expands the function
in the code, buy how is scenario #2 different from #1 in terms of how the
compiler handles the situation??
|
|
|
|
|
John Theal wrote:
how is scenario #2 different from #1 in terms of how the
compiler handles the situation??
No difference at all. The compiler simply replaces a function call with the actual code for the function. Where the function appears is irrelevant, unless it is a recursive call to an inline function.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
i dont think so that there is any change i mean in the 1st case the return value by the function is directly place from where it is called. i mean the cout<< "here is the returned value"
while that in the 2nd senario the retuen value is being assiged to the var and that particular var is used to display the value with the cout object.
i dont think so there is much difference in the 2 senrio.
if any one can tell more its good isnt it..
Thanx
TAKE CARE
|
|
|
|
|
Have you looked at the assembly output of the two? That'll tell you what the compiler is doing to each.
|
|
|
|
|
In scenario #1, the compiler will insert the code for the function inline with the expression evaluation for the << operator arguments. It will place the return value of <nobr>InlineFunction() on the stack, passing it to the << operator.
In scenario #2, it's handled inline, except as an argument for the int assignment operator for the variable temp. It then picks up the variable out of temp and places it on the stack, passing it to the << operator.
Scenario #1 is a trifle faster, in that the compiler is free to evaluate the inline function and place it's result directly on the stack. Scenario #2 requires that the function be evaluated and the result placed in a temporary variable.
In either case, the compiler inserts the code for the inline function into the expression evaluation for the argument to the appropriate function. In scenario #1, it's the << operator. In scenario #2, it's the assignment operator.
Software Zen: delete this;
|
|
|
|
|
|
Can anyone give me some advice on coping a whole dialog with all its resources (like the menu bar, ClassView, and ClassWizard info) from one project into another?
It must be something that people do all the time, yet I couldn't find anything usefull by googling it.
Paul
|
|
|
|
|
You'll either need to copy the entire .RC file, or copy/paste the relevant pieces from one .RC file to the other.
|
|
|
|
|
there's an article here on CP that talks about that, but I don't know what to search for.
one way (I think) could be to copy-n-paste the dialog between 2 instances of VC and copy-n-paste the dialog files and insert them into you new project.
but you have to be carefull of the resource ID numbers.
Maximilien Lincourt
"Never underestimate the bandwidth of a station wagon filled with backup tapes." ("Computer Networks" by Andrew S Tannenbaum )
|
|
|
|
|
If you are really lazy like me  - create intermediate empty solution and add old project and new project to it. In resource view just drug the resource from one project to another, holding Ctrl key.
|
|
|
|
|
The most reliable way I've found of doing this is by hand, using the text editor.
Copy/paste the resources out of the .RC file and into the destination. Don't forget to copy/paste the DESIGNINFO section if there is one. You mentioned menus; you'll have to copy the menu as well.
Copy the resource ID's from the original resource.h into the destination. You may need to renumber the resource ID's so that they don't conflict.
The IDE (VC6, VS.NET 2002, and VS.NET 2003) will let you cut/paste controls, but it's not terribly smart about whole dialogs.
Software Zen: delete this;
|
|
|
|
|
Hi all,
I posted yesterday morning to try and get my menu item to be checked and unchecked as one of my dialogs is displayed via the menu item. I kinda need this to be accomplished soon, so i figured i could post it again because the original post is 5 or 6 pages into the message board.
Beer26 was kind enough to help me with this solution.
in the new dialog class add this function. Now the new dialogs will control that menu item in it's parent.
void MyClass::checkmymenuitem(int checked)
{
CMenu* pMainMenu = GetParent()->GetMenu();
CMenu *submenu = pMainMenu->GetSubMenu(1); // replace 1 by the horizontal menu position
UINT g = submenu->GetMenuItemID(3); // replace 3 by the actual vertical item position
CString mnustr;
submenu->GetMenuString(3, mnustr, MF_BYPOSITION); // replace 3 by the actual vertical item position
// you can optionally change mnustr to a text here
if (checked) submenu->ModifyMenu(3, MF_BYPOSITION | MF_STRING | MF_CHECKED, g, mnustr);
else submenu->ModifyMenu(3, MF_BYPOSITION | MF_STRING | MF_UNCHECKED, g, mnustr);
}
in initdialog
checkmymenuitem(true);
then in onclose
checkmymenuitem(false);
It works fine the first time the app is started(menu item unchecked), when the menu item is selected the first time (checked), and when the dialog is closed the first time(unchecked). BUT it doesn't update the menu at all after the first time it is selected and the dialog is closed.
Can anyone help me figure this out PLEASE. I was originally trying to use a pointer to the dialog being displayed, but that led to the same result.
|
|
|
|
|
(haven't looked at the original question)
can't you simply add a ON_UPDATE_COMMAND_UI command handler for the menu item ?
and use :
void MyClass::OnUpdateYourMenuItem( CCmdUI* pCmdUI )
{
pCmdUI ->SetCheck( IsYourDialogVisible() );
}
Maximilien Lincourt
"Never underestimate the bandwidth of a station wagon filled with backup tapes." ("Computer Networks" by Andrew S Tannenbaum )
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
