|
Thank you so much for your answers.
You idea is very good, Could you tell me where I can find some articls about
this, so I can get more detailed reference to save time in this samall but tough thing.
Ray
|
|
|
|
|
I may have missed your point, but why not create a method that you would call when you have that "something special"?
|
|
|
|
|
Okay, I know I have seen this before. But now, when I need it, I can't seem to find it. Any help will be most appreciated.
I have and MDI app with 2 child windows, one of which I would like the users not to be able to close, at least not easily. I would like to disable the [X] button so it won't accidently be hit, but I can't locate an easy way to do it.
I did Google and found a couple of question/answer pages, but the solutions didn't work. They dealt with changing the system menu. Isn't there a style element or something easy?
As I said, any help will be most appreciated.
Thanks,
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
do it by Calling SetWindowLong(GWL_STYLE)
Thanx
TAKE CARE
|
|
|
|
|
SetWindowLong? Thanks. What value should I use to disable the close button then?
Dave
"You can say that again." -- Dept. of Redundancy Dept.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
