Well, we have to choose win32 application to write opengl in vc6Chowever in glut,we actually new a console applcation at the startB
Is this because the window and message handling routines are programmed manually within the GLUT console app?
Originally posted by peter.vullings:
See the NeHe tutorials for information on how to do this: http://nehe.gamedev.net/
I don’t get it.where is mentioned in NEHE that we can start with console application to write OPENL in vc6.
And for your second reply post? can you
elaborate a little more ? i can not yet understand how to manually set the OPENGL initialization.
It’s not clear what you are asking.
Whether a console is launched for any application depends on the entry point used by the developer, this is basically main vs WinMain on Windows, but it’s not clear that’s what you’re asking because you talk about writing OpenGL in a console using an IDE.
You can always open your own console and go to the directory of the IDE generated executable and run it from the command line.
Originally posted by dorbie:
[b]It’s not clear what you are asking.
Whether a console is launched for any application depends on the entry point used by the developer, this is basically main vs WinMain on Windows, but it’s not clear that’s what you’re asking because you talk about writing OpenGL in a console using an IDE.
You can always open your own console and go to the directory of the IDE generated executable and run it from the command line.[/b]
In VC6, when you start a project. You have to choose a win32 application or win32 console application.
I am just curious , For Writing the same opengl. the GLUT start with console application while the nehe program tend to start with the win32 application ,use winmain as entry point .
can i ,like glut, write the console program using win32 api directly ?? In addition, i like to output the debug info directly to the console .
For win32 apps, you can manually open the console with AllocConsole()and close it with FreeConsole(). Check them out in the sdk docs - there are a bunch of functions that allow manipulation of the console and provide i/o.
If I’m understanding your question correctly…
Yes you can. All you really need to have to create a window is an hInstance. A “Windows application” (with WinMain) gives you this directly. A “console application” (with main) does not… but you can obtain one easily enough with ‘GetModuleHandle(NULL)’.
Once you have an hInstance in your console application you can register your class and create windows like you would any other Windows application while viewing debugging printfs in the console.
- sec
Originally posted by secnuop:
[b]If I’m understanding your question correctly…
Yes you can. All you really need to have to create a window is an hInstance. A “Windows application” (with WinMain) gives you this directly. A “console application” (with main) does not… but you can obtain one easily enough with ‘GetModuleHandle(NULL)’.
Once you have an hInstance in your console application you can register your class and create windows like you would any other Windows application while viewing debugging printfs in the console.
- sec[/b]
Thankx secnuop very much for the enlightment,
I look through the MSDN and GLUT source code .GetModuleHandle are just there,except in MSDN i don’t understand the way they explain about the GetModuleHandle function when you pass NULL to it. (Quote from MSDN: If this parameter is NULL, GetModuleHandle returns a handle to the file used to create the calling process. ) .the “file” word absolutely confuse me
Then i read about the
source code in msdn about GetModuleHandle() ,if what i understand is true, the console app are child process hiddened generated from the winmain --the main process.(you don’t know this when you start with a console application). Then GetModuleHandle(NULL) just returns the handle of parent process or calling process.
Anyways Thanx ConFusion too .
BTW the name secnuop does not make any sense to me . what does it mean ?
Cheers