|
I'll just also mention that if you also meant how could it be closing without your wishes, the most common way is you hit return in a dialog based app. Other than that, if that's what you meant, you'll have to be more specific.
Christian
After all, there's nothing wrong with an elite as long as I'm allowed to be part of it!! - Mike Burston Oct 23, 2001
|
|
|
|
|
When you run (in VC++6.0) in Debug mode and the app closes (by the user), appear on 'Docking view'window' - tab 'Debug', the messages:
The thread 0x3A4 has exited with code 32053 (0x7D35).
The thread 0x1B8 has exited with code 32053 (0x7D35).
The thread 0x498 has exited with code 32053 (0x7D35).
The program 'D:\MyProgram\Debug\MyProgram.exe' has exited with code 32053 (0x7D35).
I would like to know any shape to get some information like this about the program exit.
[]'s Cris
|
|
|
|
|
I have a problem with animating my OpenGL code in an MFC window. When I move the window the background leaks onto the screen. I was wondering if anyone knows what to do. I think you have to use the WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE messages, but I am not sure. Also I was wondering if anyone knows if you can animate OpenGL in a dialog box?
Matt
|
|
|
|
|
First of all I'd recommend not using MFC. nehe.gamedev.org ( from memory, to be honest all I am sure of is nehe ) has a ton of GL tutorials that do not use MFC and will help you learn pretty much all you'd want to know. As for your sizing, I'd have thought you'd handle WM_SIZE to keep track of the changing size of your GL window, but if you're drawing onto the DC of the window, I don't see how you'd be drawing outside it.
There's no reason you couldn't animate GL in a dialog box.
Christian
After all, there's nothing wrong with an elite as long as I'm allowed to be part of it!! - Mike Burston Oct 23, 2001
|
|
|
|
|
> First of all I'd recommend not using MFC.
Why not Christian?
To hell with those thin-skinned pillow-biters. - Me, 10/03/2001
|
|
|
|
|
Doesn't MFC make OpenGL calls unnecessarily slow? MFC isn't the best thing to go with 3D Graphics.
|
|
|
|
|
Doesn't MFC make OpenGL calls unnecessarily slow?
How exactly it slows OpenGL calls?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Relying on MFC code is like taking a chance, and I would not depend on it for game rendering.
MFC classes such as CArray, CMap, and CList that perform inefficient data copies. Also there are many redundant calls that MFC applications make.
|
|
|
|
|
Well, it's pretty obvious at this point that you don't have much (if any) experience writing OpenGL apps using MFC.
To hell with those thin-skinned pillow-biters. - Me, 10/03/2001
|
|
|
|
|
OpenGL is not only for game rendering. If you need to create a complicated 3D modeler with rich UI, MFC (or WTL) surely helps.
MFC classes such as CArray, CMap, and CList that perform inefficient data copies
I find this statement mysterious. Please elaborate.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Well, since MFC doesn't wrap any of the OpenGL API, I fail to see that this would be an issue.
To hell with those thin-skinned pillow-biters. - Me, 10/03/2001
|
|
|
|
|
For OpenGL applications it is highly reccomended to register the windows class with style set to CS_OWNDC, which is (as far as I know) not something MFC will do for you. Of course, you can always do it yourself, but I've never noticed this in any of the CodeProject articles on OpenGL. 
I vote pro drink ![Beer | [beer]](https://codeproject.freetls.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
From what I can see, you can still use MFC in an OpenGL app.
To hell with those thin-skinned pillow-biters. - Me, 10/03/2001
|
|
|
|
|
Of course you can. My first MFC project was a CAD application with a heavy use of OpenGL.
I vote pro drink
|
|
|
|
|
Because if you're doing an OpenGL app, it's likely you don't *need* MFC for anything, and not using MFC gets you closer to the main message loop for rendering etc, plus while I think the effect MFC has on speed is overrated, I still think it's probably there and to be avoided when you're not going to do any real GUI anyhow.
Also, for me personally GL was a good excuse to learn Win32, which I always recommend.
Christian
After all, there's nothing wrong with an elite as long as I'm allowed to be part of it!! - Mike Burston Oct 23, 2001
|
|
|
|
|
I should probably reiterate the main reason for me. While there is no doubt you most certainly *can* do OpenGL in an MFC app, I recall that doing a Direct Draw game using MFC became a major pain when I started trying to get it to render in idle time, although as I recall that was actually because I started with a dialog based app and it was through this project I learned about WM_KICKIDLE.
Nevertheless, the main reason for me is the nehe tutorials, because they are an excellent source of info, and they do not use MFC, nor do any of the major OpenGL books. Therefore it's simply a case of conforming to the way information is being presented.
I guess also my bias is starting to lean towards only using MFC when I need it, based on the amount of time I'm spending without it. But I did not mean to imply you COULDN'T do it with MFC, only that there are reasons I personally wouldn't.
Christian
After all, there's nothing wrong with an elite as long as I'm allowed to be part of it!! - Mike Burston Oct 23, 2001
|
|
|
|
|
I would rather not use MFC but my project requires that I do. Anyway I am not sure if the OnSize will work, but I'll try. Also I am not drawing outside the box, it is that the picture leaks outside the box.
|
|
|
|
|
I would rather not use MFC but my project requires that I do. Anyway I am not sure if the OnSize will work, but I'll try. Also I am not drawing outside the box, it is that the picture leaks outside the box.
|
|
|
|
|
1. Make sure your window is created with CS_OWNDC
2. Make sure you've select a double buffered rendering mode
3. You can optionally stop rendering while the user drags the window. This is usually desirable anyways. If you want to drag with the image then consider buffering the image yourself with glcopypixels or something similar. Then do a blit while you drag instead of a render. That works well for CAD style apps where rendering may not be real-time.
I've seen the rendering bleed outside the window. I forget the specifics as to why it happends but it doesn't always happen with all video cards.
Todd Smith
|
|
|
|
|
Todd what do you mean by your number 3.
3. You can optionally stop rendering while the user drags the window. This is usually desirable anyways. If you want to drag with the image then consider buffering the image yourself with glcopypixels or something similar. Then do a blit while you drag instead of a render. That works well for CAD style apps where rendering may not be real-time.
I am not understanding it.
|
|
|
|
|
Hi,
I am writing an MFC application which has a menu called IDR_MAINFRAME. Now in the menu I have a menu item File>Listen (ID_FILE_LISTEN).
I want the message handler for this menu item in the view class of my application (CUDPView). So I used the Class Wizard to add the message handler, and it created the following function in the CUDPView.cpp file:
void CUDPView::OnFileListen()
{
// TODO: Add your command handler code here
AfxMessageBox("Ok Code Reachable"); // added by me
}
I added the AfxMessageBox line in the code to see if this function was indeed called when I clicked File>Listen, but it was not called!
Tell me please, what's wrong?
Mike 
|
|
|
|
|
|
No I dont have any message hanlders anywhere else. Is that necessary? If yes then tell me what I should do?
|
|
|
|
|
No, it's not necessary, but other handlers may be invoked first.
Did you override OnCmdMsg in any class?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Nope! I did on override OnCmdMsg anywhere....I haven't over ridden any functions!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
