|
hi
am trying to take a screen shot of a context menu
tried the alt-print screen combination, but of course the menu closes when i hit the alt key
does anyone have any suggestions?
regards
bryce
|
|
|
|
|
well bugger me, alt-pritnscreen does the top most window and printscreen copies the whole screen
(usign windows 2000)
you learn summat new every day
bryce
|
|
|
|
|
It's worked that way since Win 95 
and maybe before that, but I only started using Win with 95.
--Mike--
Just released - RightClick-Encrypt v1.4 - Adds fast & easy file encryption to Explorer
My really out-of-date homepage
Sonork-100.19012 Acid_Helm
|
|
|
|
|
Michael Dunn wrote:
and maybe before that, but I only started using Win with 95.
Yup, worked that way in 3.1 also. I had so much fun, taking a screenshot of the desktop w/ Progman running & making the wallpaper so it looked like Progman was still running even when it was minimized though of course you could see the icon for Progman then so it wasn't all that good of a joke...
... and then i'd reboot into OS/2 & do useful stuff ... 
---
Shog9
Actually I use to find learning in bars when drinking really useful.
It sort of makes a language liquid. - Colin Davies, Thinking in English?
|
|
|
|
|
Use print screen alone, and then paintbrush for example. Alt will hide menu.
|
|
|
|
|
hi, i'm new in game dev. i cant make the connection between:
(1) 3D modeling in 3D Studio Max
and
(2) DirectX 3D
any pointer? i can model a spaceship using 3D Studio MAX. But how can i load it into my application...?
thanx!
norm
|
|
|
|
|
The DirectX SDK used to come with a tool called conv3ds.exe that converts .3ds files into .x files for loading in Direct3d. It doesn't seem to exist in the DX8.1SDK, but you can find it on google
--
Help me! I'm turning into a grapefruit!
|
|
|
|
|
The DirectX SDK comes with a plugin for Max which will output meshes (including animated meshes) to a .X file. You can then load this file using the DirextX utility library.
If you're new to game development I suggest you learn OpenGL at first because it's much easier to use at the beginner to intermidiate levels yet is just as powerful as DirectX. When you're comfortable with OpenGL switch over to DirectX this way the transition is much easier.
I recommend you start using Opengl[^] and Glut which will help you understand 3D concepts rather then get bogged down in the device and window handling routines. nehe.gamedev.net[^] has a whole bunch of tuturials related to game dev.
HTH
Brian Azzopardi
bibamus, edamus, cras moriemur [eat, drink, for tomorrow we die]
|
|
|
|
|
thanx guys. i'm new in directx and game dev. but i do have experience writing COM client and have lots of experience with CAD and 3D modeling. so, should i just go straight to directx then?
norm
|
|
|
|
|
norm wrote:
lots of experience with CAD and 3D modeling
Programming CAD and 3D modeling or just creating the models? If you're a newbie to 3D coding (gameing or otherwise) it's important to understand the fundamentals: matrix operations, frames of reference (local-space, world-space), the graphics pipeline (what's the difference between a fragment and a texel and what ops can be performed on one but not the other). Knowing how to model and elephant in Max does not even begin to prepare you for the complexities of 3D programming.
I still recommend you start with Opengl and glut until you're comfortable withe the concepts enough to know your euler angles from your quaternions and how to get polies as fast as pos onto the screen. Once you can do this switch over to DirectX if you want. Carmack used OpenGL for Doom3 so if it's good enough for him i reckon it's good enough for me 
Brian Azzopardi
bibamus, edamus, cras moriemur [eat, drink, for tomorrow we die]
|
|
|
|
|
thanks for the feedback first of all, but what's the name of the 3D Matrix plugin that allows u to convert 3DMax files into x-files?
norm
|
|
|
|
|
i've got it: conv3ds.exe... sorry =)
norm
|
|
|
|
|
When I compile my application using VC++ 6.0, my app requres MFC42.DLL while if compiled with VC++.net, is requires MFC70.DLL
Is there a way to compile using .net AND forcing it to link to MFC42.DLL and not MFC70.DLL ???
PLEASE help.
Rick Eastes.
------------
|
|
|
|
|
|
Obviously.
However, the .net framework (20MB) is certainly not small. I don't want to distribute this dll when mfc42.dll would be fine.
Rick Eastes.
------------
|
|
|
|
|
You should just be able to distribute the MFC7 dlls. The .NET framework is only required for managed applications.
Michael 
Time flies like an arrow. Fruit flies like a banana
|
|
|
|
|
From VS.Net redist.txt file :
The following merge modules have been provided for use when
redistributing the Visual C++ runtime files. Redistributing
the merge modules is the recommended method for the
redistribution of these files.
VC_atl70.msm
atl70.dll (UNICODE)
atl70.dll (ANSI)
VC_CRT.msm
msvcr70.dll
VC_CRT_IO.msm
msvci70.dll
VC_MFC.msm
mfc70.dll
mfc70u.dll
GDIPlus.msm
gdiplus.dll
MFC_Loc_E.msm
mfc70deu.dll
mfc70esp.dll
mfc70fra.dll
mfc70ita.dll
MFC_Loc_FE.msm
mfc70chs.dll
mfc70cht.dll
mfc70jpn.dll
mfc70kor.dll
VC_STL.msm
mscvp70.dll
What they are saying is that redistribuing DLLs is wrong and obstrusive to the new XP install procedure.
You must distribute what they call Merge modules (.msm files).
Btw, .mcm is a subformat of the general Windows Installer SDK (.msi database).
Otherwise it won't install on XP, depending on the profile.
Have fun.
And if you still want to distribute sharewares on a low deployment basis (for 9x for instance), just distribute these :
mfc70.dll
msvcr70.dll
msvcp70.dll (stl)
msvci70.dll
I recommend to put these files in the app directory, not on system32.
And I swallow a small raisin.
|
|
|
|
|
StephaneRodriguez wrote:
I recommend to put these files in the app directory, not on system32.
If you do this, it's better statically linking to MFC. This way, the installer size will be smaller, since only the needed code will go to the final .EXE
Concussus surgo.
When struck I rise.
|
|
|
|
|
Well Daniel I believe you're right, at least in theory,
But in practice I have had so many problems with statically linked MFCs, especially when I tried to run my .exe on someone else machine with sometimes another OS, that I have decided that static linking of the MFCs was not for me. The problem was most of the time a crude GPF! (memory access violation).
In fact, the only *good reason* not to put the MFCs in your app directory is that the MFCs are not only DLLs, they are COM components, and self-register themselves each time they are loaded, hence overwriting the registry, which may lead to unpredictable consequences on the stability of other installed MFC apps, especially after uninstall.
And I swallow a small raisin.
|
|
|
|
|
StephaneRodriguez wrote:
But in practice I have had so many problems with statically linked MFCs, especially when I tried to run my .exe on someone else machine with sometimes another OS, that I have decided that static linking of the MFCs was not for me. The problem was most of the time a crude GPF! (memory access violation).
I've never had a problem with statically linking. Perhaps you wrote some bad code?
StephaneRodriguez wrote:
In fact, the only *good reason* not to put the MFCs in your app directory is that the MFCs are not only DLLs, they are COM components, and self-register themselves each time they are loaded, hence overwriting the registry, which may lead to unpredictable consequences on the stability of other installed MFC apps, especially after uninstall.
Yikes! I still suspect that isn't true, but I greped the mfc dlls and mfc42.dll has DllRegisterServer in it. Thankfully none of the MFC70.dll's have that in there so maybe they've changed things.
Joel Lucsy (jjlucsy@ameritech.net)
|
|
|
|
|
StephaneRodriguez wrote:
In fact, the only *good reason* not to put the MFCs in your app directory is that the MFCs are not only DLLs, they are COM components, and self-register themselves each time they are loaded, hence overwriting the registry, which may lead to unpredictable consequences on the stability of other installed MFC apps, especially after uninstall.
This isn't true:
1. MFC dlls are not COM components. You can't regsvr32 mfc70.dll. (But you can create COM components with MFC).
2. COM components doesn't register themselves each time they are loaded.
3. With a COM DLL, it doesn't help installing the DLL on your app directory, because, when registered, it will be the only one DLL to be instantiated.
Concussus surgo.
When struck I rise.
|
|
|
|
|
Daniel Turini wrote:
MFC dlls are not COM components
Fair enough for mfc7, I admit I didn't chcked the exports functions before posting an answer,
And I swallow a small raisin.
|
|
|
|
|
My MFC application compiles successfully in both VC++7.0 and VC++6.0 but I feel I have wasted my time and money buying VC++7.0
WHY? I need to have a small distributable.
Here are two senarios:
1. Compile with .NET
Need MFC70.dll which most computers don't have.
2. Compile with VC6
Runs on ALL computers without ANY additional dll's
 Surely there is a way using .NET to make the exe link to old dll's like MFC42.DLL and not new ones like MFC70.DLL
Rick Eastes.
------------
http://www.eastes.net
|
|
|
|
|
Yes, somewhat waste of money especially if you don't have C# in the package you bought.
What's more is that MFC70 has STL embedded everywhere, much harder to debug a callstack than the previous release IMHO.
For some programmers however, MFC70 is a new step to achieve robustness and so on,
And I swallow a small raisin.
|
|
|
|
|
RickEastes wrote:
Surely there is a way using .NET to make the exe link to old dll's like MFC42.DLL and not new ones like MFC70.DLL
Have you tried changing the LIB and INCLUDE search paths ?
This probably would help...
Concussus surgo.
When struck I rise.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
