Joseph M. Newcomer wrote:
See below...
On Thu, 24 Sep 2009 01:28:36 +0330, MicroEbi <MicroEbi@NoMail.com> wrote:
AliR wrote:
void CChildFrame::ReallyClose()
{
CMDIChildWnd::OnClose();
}
AliR.
Hello,
Thanks, I think the problem is when I try to hide the frame, for some
unknown reason it destroys it.
I have this function in my CChildFrame class
void CChildFrame::ToggleVisibility()
{
if(IsWindowVisible())
ShowWindow(SW_HIDE);
else
ShowWindow(SW_SHOW);
}
****
I tend to get nervous when I see things that "toggle" such state. You should know if you
plan to show it or hide it and call the correct method explicitly.
Note that this handles only the case of showing and hiding, and does not implement the
earlier suggestion of overriding the OnClose and explicitly hiding it.
****
when I try to hide it either by clicking close or using this function.
It removes he frame but when I try to show it again it does not appear.
****
Forget the notion of toggling. If you want to show it again, you will EXPLICITLY call a
show mechanism. If you want to hide it, you will EXPLICITLY call a hide mechanism.
Toggling is inapprpropriate.
****
I have put some break points and I'm sure when I ToggleVisibility()
ShowWindow(SW_SHOW) executes but it does not return my window. has it
been destroyed?
****
You cannot claim to ask a question if you don't ask a question. You have failed to say
what you did, only that in some unknown and undescribed context, ShowWindow(SW_SHOW)
doesn't show anything. You have not said how you call this, or what the call stack is.
Using toggling is almost always suspect unless the user has a "toggle state" option;
instead, you apparently have provided the user with explicit "hide" (the close box) and
"show" (some undefined mechanism). So you need to have interfaces that implement these,
as explicit "hide" and "show" methods.
Also, you have some interesting problems. For example, if you don't save the state, how
does the user know that there is unsaved state if there are no windows visible because
they happen to be hidden at the moment. So how does the user know to explicitly close the
windows? Note also that a user might expect that a close by clicking the close box works
EXACTLY like a close in any other app, and you are doing something different. So what you
need to do to make this work right is to, for example, on a "close", write the document
contents to the file, so the "open" looks AS IF it is reading the file, but merely
"refreshes" from the "internal cache" (and this also requires that on such activation you
check the consistency of the data by looking at the file timestamp of the file that
generated the document and the current file). This also leads to the question of whether
or not you should prompt instead of automatically saving; that is, you give the *illusion*
that you have saved the file and closed the document and view, while actually retaining it
in memory for performance reasons. The key issue in using such cache techniques is that
the cache consistency must be maintained. Of course, if these objects are merely
transient and have no file representation, and nothing needs to be saved as persistent
state, your job is vastly simpler, since the consistency issue disappears.
You need to show us
1. Your child frame OnClose handler
2. Your mechanism for making the window reappear
****
As I said my project is with feature pack and I use visual studio style
and MDI tabbed document bar.
****
Note that MDI as clasically implemented should work correctly with the earlier suggestion,
but I have not used the MDI tabbed document bar and do not know if it Plays Well with the
idea of making a window invisible. It might well be that this mechanism is unsupported,
or will require that you carefully read the code of the Feature Pack to see how to do it.
I ran into a similar problem with the CTabView from codeproject, which didn't handle
hiding tabs. In my case, I was able to modify the source code, and it took a fair amount
of effort to handle all the state changes to hide a tab if it wasn't needed.
joe
****
thanks
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
The problem persists. I decided to use your suggestion in the other
I think quality of feature pack code is lower than rest of MFC.