|
Image file I suppose.
I am interested in knowing as well.
|
|
|
|
|
I think you might be able to do it using OpenGL programming.
|
|
|
|
|
the different between the framework of dll and application
in the VC++ 6.0??
a good man in china
|
|
|
|
|
YEAH,WIN32 DLL AND WIN32 APPLICATION
a good man in china
|
|
|
|
|
A dll is a dynamic link library of functions and variables that are loaded dynamically by an application or service into its address space at run time.
John
|
|
|
|
|
LOL 
[It is possible to represent everything in this universe by using 0 and 1]
I was born intelligent
Education ruined me!.
An idea is useless until it has been implemented.
|
|
|
|
|
I've got a component which uses a library which MUST be properly closed when you exit from using it. It takes a couple of seconds.
Is it ok to create a Thread to do all this work (as long as I don't modify or read memory inside the component from within the thread) in the Destructor of the component? And exit the component immediately?
|
|
|
|
|
Paul Farry wrote:
Is it ok to create a Thread to do all this work (as long as I don't modify or read memory inside the component from within the thread) in the Destructor of the component?
Yes, it's fine. As you mentioned, watch out for accessing memory that has been deleted.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Hi,
I was wondering if anyone else has seen this problem:
When I right click and open up a context menu in a CWnd sub-classed dialog, then go into a submenu my mouse cursor goes from the arrow to the hourglass and never reverts back to the arrow cursor until after I close the dialog box.
It doesn't seem to matter which way I create the menu (either through resources or purely by code) and I have tried overwritting the OnSetCursor function which always sets the mouse to the arrow.
I know that OnSetCursor is being called because outside of a menu the cursor is not an arrow.
Here is the sample of my code:
for cursor override:
BOOL CCMFrame::OnSetCursor(CWnd* pWnd, UINT nHitTest, UINT message)
{
if (message == 0)
{
HCURSOR hCursor = LoadCursor(NULL, IDC_ARROW);
SetCursor(hCursor);
return TRUE;
}
return CWnd::OnSetCursor(pWnd, nHitTest, message);
}
for menu creation:
CMenu mnuTop;
mnuTop.LoadMenu(IDR_POPUP_MENU);
CMenu* pPopup = mnuTop.GetSubMenu(0);
ASSERT_VALID(pPopup);
pPopup->TrackPopupMenu(TPM_RIGHTBUTTON |
TPM_LEFTALIGN, Point.x, Point.y, this, NULL);
Thank you for any insight into what could be causing this!!
Crystal
|
|
|
|
|
dWorkVan wrote:
When I right click and open up a context menu in a CWnd sub-classed dialog, then go into a submenu my mouse cursor goes from the arrow to the hourglass and never reverts back to the arrow cursor until after I close the dialog box.
Seems to mimic how Windows 2000 Explorer.exe and its Property dialog behaves - seems you are in good (or bad, depending on how you look at it) company.
Have you registered a cursor for your dialog? Do you handle all the WM_* messages as you should?
To give you a hint: The problem isn't with the manu code (no matter what it does) - the problem is with setting the right cursor when the focus returns to the dialog. If the hCursor is NULL, guess what it *can* set it (or *not* set it) to.
|
|
|
|
|
Thanks for the insight.
To answer your questions:
The cursor is registered for the dialog and its owner and I am almost positive that all the WM_* messages for both are handled correctly. Actually, the dialog the menu appears on isn't the owner of the menu, but both the owner of the menu and the dialog handle the WM_SETCURSOR messages which *should* cover the case when focus returns to the dialog.
So I am still at a loss of how to fix / overcome this problem.
|
|
|
|
|
How do I correct this error in VC++6.0?
"utils.c(125) : fatal error C1010: unexpected end of file while looking for precompiled header directive"
along with all other imported c files
I created a win32 console app "hello world" and inserted C files from
ftp://ftp.cs.brown.edu/pub/nlparser/nlparser.tar.gz
Thanks
Later,
JoeSox
www.humanaiproject.org
"Dream as if you'll live forever; live as if you'll die tomorrow."
- James Dean(ISTP)
|
|
|
|
|
You probably have either /Yu or /YX set. In Project Settings in VC 6.0, go to the C++ tab and select Precompiled Headers from the Category drop-down. Select the 'Not using precompiled headers' radio button and choose OK. It's best to do this for all project types - choose All Configurations in the Settings For drop-down before making the setting.
Precompiled headers are a way to collect common headers for your project in a single file that the compiler generates once; it can then reload a pre-compiled version of the common headers and speed up compiling each source file, because it only has to read and process the headers that source file includes that aren't in the PCH, and compile the code in the source file. You typically see that 'stdafx.cpp' takes ages to compile, then everything else takes fractions of a second on a fast machine.
The AppWizard assumes you want to do this and configures your project for /YX (automatic use of PCH) if it's an empty project, or with /Yc"stdafx.h" (create PCH through stdafx.h) for stdafx.cpp and /Yu"stdafx.h" (use PCH through stdafx.h) for all other source files.
When any of the /Y{cuX} options are specified, the compiler looks for #include "headername", where headername is the header specified as the argument. If no argument is specified, the default name is based on the source file name (/Yc) or is MSVC.PCH (/YX). The compiler also looks for #pragma hdrstop directives. If it doesn't find either in the source file, it generates a C1010 error.
/YX creates the precompiled header only if it doesn't already exist; in practice, this means that the first source file compiled is the one which will cause the PCH to be generated. It's usually better to specify /Yc on a file which only generates the PCH, and /Yu on everything else.
--
Mike Dimmick
|
|
|
|
|
thanks that worked. but now I have 345 errors to debug
am I not supposed to compile C files in MSC++6.0 
I guess the files were not meant to be converted to C++, darn I need Part of Speech tagger in C++. It will probably take me a while to figure out the errors. Thanks!![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Later,
JoeSox
www.humanaiproject.org
"Dream as if you'll live forever; live as if you'll die tomorrow."
- James Dean(ISTP)
|
|
|
|
|
If the file extension is .c, and the /Tp or /TP switch is not specified, the code should be compiled as C.
In the header files, ensure there's an extern "C" block around all the function declarations, so that the compiler doesn't decorate the names, or, rather, uses the C rules for name decoration. If this happens, the linker will complain that it can't find a funny name like ?a@@YAHD@Z, which is the decorated name for int __cdecl a(char).
This should allow your code to be written in C++, with the libraries you're using in C.
I've done this when porting a DOS application to Pocket PC, which has no console library, therefore I had to emulate a console myself. The emulation layer was written in C++, while the original application was written in, and was compiled as, C.
--
Mike Dimmick
|
|
|
|
|
|
thanks, I forgot about that page
Later,
JoeSox
www.humanaiproject.org
"Dream as if you'll live forever; live as if you'll die tomorrow."
- James Dean(ISTP)
|
|
|
|
|
1) Goto project->settings.
2) Under Settings For: Select the file or files that generate the error.
3) Select the C++ tab.
4) Select Catagory: Precompiled headers.
5) Check "Not using precompiled headers".
INTP
|
|
|
|
|
thanks, that worked
John R. Shaw wrote:
INTP
Later,
JoeSox
www.humanaiproject.org
"Dream as if you'll live forever; live as if you'll die tomorrow."
- James Dean(ISTP)
|
|
|
|
|
I'm relatively new to Visual C++, C++ altogether even. I know enough and have been going through some tutorials on code project. At the minute I'm working through an introduction to using dialogs and forms. Followed the instructions and made a pretty simple app, but every time I try to run it I get and error:
The ordinal 5076 could not be located in the dynamic link library MFC42D.DLL
I'm using the MFCAppWizard in Visual C++ 6.No matter what kind of program I try to run that uses a form or dialog, I keep getting an ordinal error. CAn anyone tell me what this is. I'm running VC++ on XP Pro.
The more we think we know, the less we understand
|
|
|
|
|
I just looked at ordinal 5076 and in MFC42.DLL it refers at CView::OnUpdate, while in MFC42D.DLL it refers at CWnd::WindowProc (ordinals in these two files are not supposed to match anyways). I really don't know why this is happening but what happens if you try to build and run the release version? I couldn't find CWnd::WindowProc in MFC42.DLL that's why I am asking.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
It's there, it's just at ordinal 6374 in the release build (look at MFC42.DEF in C:\Program Files\Microsoft Visual Studio\VC98\MFC\SRC\Intel [typically]).
Since the linking is done by ordinal, if you somehow had the wrong version under the wrong name, you'd get erroneous behaviour by the app, not an error like this.
MFC42.DLL is supposed to be compatible from version 4.2 of MFC right up to version 6.0 (i.e. new functions were added at the end, semantics are meant to be identical, and structure and class sizes remain the same).
I think you may have a corrupted copy of MFC42D.DLL, or possibly one from an older version of MFC (although the ordinal numbers should be the same). Try reinstalling it from the Visual Studio CDs, or reinstalling the service pack - you did apply Service Pack 5[^], didn't you?
My version of MFC42D.DLL (from SP5) is version 6.00.8665.0, dated 2000-07-15, size 929,844 bytes.
Sidenote: MFC uses ordinals rather than names because nearly 7000 decorated names, averaging about 40 characters long, would take up 280Kb (guesstimated) in the final DLL. Quite a hit for a DLL that's already nearly 1Mb in size. It would take the loader a bit longer to fix up the import table, too.
--
Mike Dimmick
|
|
|
|
|
Mike Dimmick wrote:
It's there, it's just at ordinal 6374 in the release build
You are right. I don't know why my search didn't return 6374.
Your reply makes perfect sense though.
// Afterall, I realized that even my comment lines have bugs
When one cannot invent, one must at least improve (in bed).-My latest fortune cookie
|
|
|
|
|
Thanx Mike, found the problem. Didn't have Service Pack 5 lol. Everything's working fine now, plain sailing.
Later
The more knowledge we gain, the less we understand
|
|
|
|
|
It sounds like your app is not using the DLL you link with. What the version of the MFC42D.DLL your app is using?
We do not inherit the Earth from our ancestors, we borrow it from our children - Antoine de Saint-Exupéry (1900-1944)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
