|
Nish [BusterBoy] wrote:
In my CDocument's OnNewDocument()
I must manually clean up all the CDocument member objects.
Is this the right way?
No,You have to it in
DeleteContents()<br /> . 
Mazy
"The path you tread is narrow and the drop is shear and very high,
The ravens all are watching from a vantage point near by,
Apprehension creeping like a choo-train uo your spine,
Will the tightrope reach the end;will the final cuplet rhyme?"Cymbaline-Pink Floyd
|
|
|
|
|
Mazdak wrote:
No,You have to it in DeleteContents()
Thanks Mazy. I just discovered that. But what puzzles me quite a bit is the fact that the destructor never gets called. Maybe since this is a heap object [the entire document object in an MFC doc/view app], and since the program is quitting anyway, the MFC guys thought they need not call the destructor.
Peculiar though.
Nish
If I am awake and my eyes are closed, it does not necessarily mean that I am thinking of naked women.
|
|
|
|
|
Thats inteesting,Nish.Does your program SDI,and when you click on "New" it doesn't call destructor,or you mean when you quit your program,it doesn't call destructor?
Mazy
"The path you tread is narrow and the drop is shear and very high,
The ravens all are watching from a vantage point near by,
Apprehension creeping like a choo-train uo your spine,
Will the tightrope reach the end;will the final cuplet rhyme?"Cymbaline-Pink Floyd
|
|
|
|
|
Mazdak wrote:
Thats inteesting,Nish.
Yes. Very interesting indeed!
Mazdak wrote:
Does your program SDI
Yep. It's an SDI application.
Mazdak wrote:
when you click on "New" it doesn't call destructor,or you mean when you quit your program,it doesn't call destructor?
Whether I click New, whether I open a file, whether I close the application - all no use. The CDocument destructor simply refuses to get called.
Nish
If I am awake and my eyes are closed, it does not necessarily mean that I am thinking of naked women.
|
|
|
|
|
If you're using an SDI app;
- the destructor gets called when the app closes
- the constructor gets called when the app opens
- OnNewDocuemnts gets called when a new document is created
MDI:
- destructor called when document closed
- constructor called when document created or opened
- OnNewDocument called when a new document is created.
That's the basic outline, hope it's helpful. Sorry if repost but couldn't be bothered to click Next on the msg board  .
--
Andrew.
|
|
|
|
|
Hey guys
Now things are getting weirder.
I put a message box in my CDocument's destructor and was extremely stunned to realize that the destructor never gets called.
It didnt get called when I New'd a document. It didnt even get called when I closed the program.
CFormDesignerDoc::~CFormDesignerDoc()
{
AfxMessageBox("hey1");
}
Nish
If I am awake and my eyes are closed, it does not necessarily mean that I am thinking of naked women.
|
|
|
|
|
void CFormDesignerDoc::DeleteContents()
{
AfxMessageBox("hmmm");
CDocument::DeleteContents();
}
This shocked me to say the least. The destructor never gets called but this curious function does get called. I guess I'll have to clean up my document here.
Though I am still puzzled as to why the destructor never got called.
Nish
If I am awake and my eyes are closed, it does not necessarily mean that I am thinking of naked women.
|
|
|
|
|
I'm a complete moron when it comes to programming MDI apps, but I do understand that the purpose of MDI is to allow multiple documents to co-exist within the same instance of an application. Creating a new instance should never destroy an old one if that model is to be valid. It makes sense to me (like litle else does in MFC) that to eliminate an unwanted object you should be forced to deliberately call the destructor.
I'm not familiar with CFormDesignerDoc, but my first guess would be that the call to this function erases your previous settings in the Designer to allow you to start fresh with a new Form template.
But then, I'm a total idiot when it comes to VC++, so my comments may well be of no value. Feel free to pass this one over, Nish, if it doesn't seem relevant... We've missed you the past few days - you must be very busy...
|
|
|
|
|
Hello Roger,
First my application is an SDI app and not an MDI app. But that doesn't alter anything. The whole point is that when you 'New' a document or when you 'Open' an existing document, you'd think that the CDocument object would get destroyed and then re-created. Or at least I thought so anyway.
Nish
If I am awake and my eyes are closed, it does not necessarily mean that I am thinking of naked women.
|
|
|
|
|
You're entirely right; in an SDI application any existing document should be destroyed by a 'New' command. I think that all of your selections in a FormDesigner should also be returned to their default values, as well. Alas, I am too ignorant of MFC to delve into the possible reasons for the IDE to skip the obvious steps in creating a new document. Is there a way you could overcome this by calling the destructor from the application framework?
Oops, I just re-read your post. In a MDI app, existing documents should not be destroyed when a new doc is created - that would ruin the whole concept of a MDI app! In a SDI app, invoking a new document should replace the current doc, and to be graceful about it, the app should offer the user the opportunity to save the current doc for future use.
I take it, then, that when you invoke a New document, the old destructor is not called? Perhaps you need to call that function directly from the menu option. It shouldn't be necessary, but it does happen...
|
|
|
|
|
OnNewDocument doesn't create a new instance of the CDocument derived class. The CDocument object is only created once, probably in the WinApp::InitInstance code. Each call to OnNewDocument uses the same object each time.
You can clear out any variables in the Document by overriding DeleteContents.
The destructor to the CDocument Class only gets called when the application exits.
Michael
|
|
|
|
|
Michael P Butler wrote:
You can clear out any variables in the Document by overriding DeleteContents
That's what I am doing now.
Michael P Butler wrote:
The destructor to the CDocument Class only gets called when the application exits.
Here is the puzzling bit. The destructor never gets called when the application exits. Extremely curious eh?
Nish
If I am awake and my eyes are closed, it does not necessarily mean that I am thinking of naked women.
|
|
|
|
|
Have you put a break point into it. I double checked this before I posted my answer and my SDI app calls the destructor.
I assume you have a standard class wizard generated app, so it should call the destructor.
The CDocument::OnCloseDocument() function in DOCCORE.CPP is what calls my destructor. The CDocument class has a m_bAutoDelete flag which needs to be TRUE to call the destructor. This is defaulted to TRUE when the class is created.
Michael
|
|
|
|
|
Michael P Butler wrote:
Have you put a break point into it. I double checked this before I posted my answer and my SDI app calls the destructor
Unbelievable. When I put a break point I found that it does indeed call the destructor on application exit. But the message box I had used never showed up.
CFormDesignerDoc::~CFormDesignerDoc()
{
MessageBox(0,"lll","lll",0);
}
I guess that the moment the message box is shown the main program exits and along with it, all it's threads.
Nish
If I am awake and my eyes are closed, it does not necessarily mean that I am thinking of naked women.
|
|
|
|
|
Nish [BusterBoy] wrote:
I guess that the moment the message box is shown the main program exits and along with it, all it's threads.
Yes,thats what I guess too.
Mazy
"The path you tread is narrow and the drop is shear and very high,
The ravens all are watching from a vantage point near by,
Apprehension creeping like a choo-train uo your spine,
Will the tightrope reach the end;will the final cuplet rhyme?"Cymbaline-Pink Floyd
|
|
|
|
|
Is there any way wherein I can list down the name of the class declared in a COM component. To extend this problem further I also want to list down the properties / methods declared in the class?
In other words I am trying to build my own object browser!
thanks and regards,
Mangesh Sardesai
|
|
|
|
|
I have embedded several dynamically created buttons into a CListCtrl subitem. I can make an event for when any of them are clicked by adding a ON_BN_CLICKED(BTN_ID, OnButtonClick) message handler to my list ctrl and creating all the buttons with the id BTN_ID... The problem is that I don't know which one was clicked with this method. I can't add multiple message handlers at design time because I don't know how many buttons will be added. Is there a way to have the message handler return the ID of which button was clicked to my function or something?
|
|
|
|
|
WM_COMMAND sends both the control's ID and window handle in its parameters.
--Mike--
"Jobs that don't allow you to visit the Lounge 25 times a day at the minimum are not worth having anyway."
-- Nish, 3/28/2002
My really out-of-date homepage
Sonork - 100.10414 AcidHelm
Big fan of Alyson Hannigan and Jamie Salé.
|
|
|
|
|
I have 2 bitmaps(a red and green stoplight) that I want to display only one at a time at the same screen position. I have a boolean condition for 'go' that is updated at random time intervals elsewhere. The problem is that the bitmaps do not change from whatever the 'go' condition initially sends it. How do I get it to refresh and display the right image when the condition is updated?
void CLightDlg::OnPaint()
{
CPaintDC dc( this );
CBitmap bmp, *poldbmp;
CDC memdc;
if( GO )
bmp.LoadBitmap( IDB_GREEN ); //Green light bitmap
else
bmp.LoadBitmap( IDB_RED ); //Red light bitmap
memdc.CreateCompatibleDC( &dc );
poldbmp = memdc.SelectObject( &bmp );
dc.BitBlt( 78, 20, 59, 61, &memdc, 0, 0, SRCCOPY );
memdc.SelectObject( poldbmp );
}
|
|
|
|
|
Call Invalidate(FALSE) when the condition changes.
That makes the window redraw itself, the FALSE stops an erase and will stop flicker.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
|
how do i get a single ASCII character from the user, useing a console window, without having to use the return key.
i want the user to use the arrow keys (and some others) to move pices of info around on the screen.
how would i go about doing this and what headers will i need.
|
|
|
|
|
To read one single ASCII character from the console stdin you can use
int getchar(void); 
-Dominik
|
|
|
|
|
Previous:
Ok, im going to explain this vary carfully... with all the details and every thing "just to make sure im in the right place." My recent thread discused about rather i should use WTL, DirectX, or MFC. I ended up with me using DirectX.
Now:
The thing that i am going to program "in do time, after allot of study hours and practice" is program a 2D RPG "Two Dimensional Role Playing Game" Engine "The thing that i use to make the game."
This Engine will be entirly in a windows format, every little thing. I am not programming the game, i am just programming the tool that will program the game. "Now that every one knows that..."
Which device am i better off in using? WTL, Wich makes it easier to do windows stuff without the bulky MFC format. MFC "Which gives me a lot of extra things i dont need to deal with." Or DirectX, which doest do windows, yet does games?
The game is going to be "As i have told you" A RPG that will be played entirely on the .net. Any info on which way i should go would be helpful, and any place to find the tutorials from beginning to end that would teach me what i need to do would also help.
Thanks every one!
~SilverShalkin
![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif) The gate is opening
And light as warmth
And full of knowledge
Inrichest me
|
|
|
|
|
SilverShalkin wrote:
Which device am i better off in using? WTL, Wich makes it easier to do windows stuff without the bulky MFC format. MFC "Which gives me a lot of extra things i dont need to deal with." Or DirectX, which doest do windows, yet does games?
Why do you persist in putting DirectX in the list of options when it is a completely different part of your game ?
1/ If you want fast 2D graphics and more than one sound at once, you WILL use Direct
X. Simple as that. If you want to do it in 3D ( not as bad an idea as it sounds, you can fix the camera in a 2D style, which would give you a 3D type view without the 3D headaches, give you lighting, etc. ), then OpenGL might be a better option if you find another way to handle sound.
2/ If you want the game to run in a window, then the answer is probably MFC. You are clearly far out of your depth at this point, so using something that offers no documentation is going to be your own private hell. If you want the game to run full screen, as most games do, then the game should probably be Win32. If you're doing an engine, that is, a system that is called by other code to create the game, then still Win32, unless the engine has a GUI, in which case it's more of a games creation system than an engine. An engine to me is an SDK - it's something that gives me the bottom level code so I can write higher level code to achieve my goal, just like GDI stops me from having to find out the details of my graphics card and write each pixel as a byte in memory.
3/ There are no end to end tutorials, but I would *again* recommend you read www.flipcode.com if you're serious. It's full of people who are writing engines, or thought they could write an engine and gave up after a few months. www.gamedev.net is another one, it also hosts nehe.gamedev.net, the best set of OpenGL tutorials out there.
Overall I suggest you go to some gaming sites, write some code in the different systems you're considering so you know what it is you're asking, and what each bit will do, and stop asking the same question over & over again.
Christian
The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
"I'm somewhat suspicious of STL though. My (test,experimental) program worked first time. Whats that all about??!?!
- Jon Hulatt, 22/3/2002
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
