|
Basically, the value could be retreived earlier however, there was a problem retreiving it on a more recent attempt.
See here[^]
|
|
|
|
|
Here is a stupid question...this means at some point the pointer went from a good pointer to a bad one. Is the stale value the address of the original memory location where the data was or a completely new location? This is meant to be a general question about what the stale value actually is....I think I understand that it was once valid.
|
|
|
|
|
Hi Experts,
I have 2 files ( .h and .c) I added in MFC dialog based application but I am getting linker error.
Is there any special thing to add .c file.
|
|
|
|
|
john5632 wrote: but I am getting linker error.
Are you certain the file is compiled as C++ ?
What link errors ?
Are you referencing an external library ?
Watched code never compiles.
|
|
|
|
|
yes, I am getting linker error 2019, 2001.
error LNK2019: unresolved external symbol "void __cdecl Unload(void)" (?Unload@@YAXXZ) referenced in function "public: void __thiscall CTestDlg::OnBnClickedButton2(void)" (?OnBnClickedButton2@CTestprotDlg@@QAEXXZ) TestprotDlg.obj
|
|
|
|
|
So, in function CTestDlg::OnBnClickedButton2() you have a call to function Unload(), but the linker cannot find it. Where is function Unload() declared?
[edit]I suspect that your source file should have the exctension .cpp rather than .c if this is an MFC project.[/edit]
|
|
|
|
|
Where is the "Unload" function? Is it in the file you added ? are you certain the file is compiled ?
Watched code never compiles.
|
|
|
|
|
I'm assuming certain things since you're haven't shared any code with us.
I assume that the Unload function is written in the .c file and its declaration is available in the corresponding .h file.
Now I believe that you're calling the Unload function from a routine in a .cpp file.
Since C++ compilers do name mangling, the Unload function name will be internally changed.
To prevent this from happening you must include the header file within an extern "C" block.
extern "C"
{
#include "my_c_header.h"
}
|
|
|
|
|
john5632 wrote: ...but I am getting linker error.
Care to share?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Post the code.
John Nawrocki
Chief Technical Advisor
Custom Molded Products
|
|
|
|
|
NB: As indicated in a reply the issue has been solved. The DirectX module was changing the floating point precision.
A colleague is calling the constructor of a class which takes two doubles as arguments. Each argument he passes is the sum of two doubles:
CGridPoint( a + b, c + d)
The class object stores the two values internally. When he views the result he sees that the values have been rounded to 1 decimal place.
The values are not so large that this would be expected. Here are example:
a = 44.445472717
b = 724631.800000000
a + b = 724676.250000000
In other words he passes in 44.445472717 + 724631.800000000 as the first argument to the constructor and the result is stored internally and is seen to be 724676.250000000.
Does anyone know the cause of this rounding?
BTW he uses VS2008. This works in VS2010.
|
|
|
|
|
What is the code he is using to store the values and also to display them?
|
|
|
|
|
He is examing the property of the CGridPoint class using the debugger. He also confirms that the results look wrong when used. He displays a 2D representation of a Geophysical survey vessel and streamers on his screen, and position error ellipses are wrong, which is how he found this issue.
The code is C++ of course. He has rewritten like this:
CGridPoint gpt2 = gpt[i].Rotate(m_gptEllipseAngle);
gpt2.m_fEasting += gptLocation.m_fEasting;
gpt2.m_fNorthing += gptLocation.m_fNorthing;
pts[i] = ViewPoint(gpt2);
And it still fails. The original would have been something like:
CGridPoint gpt2 = gpt[i].Rotate(m_gptEllipseAngle);
pts[i] = ViewPoint(CGridPoint(gpt2.fEasting + gptLocation.m_fEasting, gpt2.fNorthing + gptLocation.m_fNorthing ));
The above might have a typo or two, not sure, I rewrote it here without compiling it.
|
|
|
|
|
I can't see the CGridPoint class in ATL or MFC; is this a Microsoft or home produced class?
|
|
|
|
|
He has found the cause. A call to DirectX was changing the floating point (double) precision ..
|
|
|
|
|
I think we need to see CGridPoint. I suspect that it is explicitly rounding things to 2dp (or could even be quarter-points from the particular example you gave).
|
|
|
|
|
A quick look at the rounded result (7xxx.25) shows it to have about the precision we'd expect from float. I'd wager that there's an explicit or implicit conversion to float and back again hidden in there somewhere. Looks like you'll have to pick through it line by line.
Peter
Software rusts. Simon Stephenson, ca 1994.
|
|
|
|
|
Implementing a Custom Download Manager?
Asynchronous pluggable protocols enable developers to create pluggable protocol handlers, MIME filters, and namespace handlers?
|
|
|
|
|
A easy method is using UrlDownloadToFile()
|
|
|
|
|
How to add Common Controls 6.0 to DLL / ATL ?
I don't have the source code of the EXE, I'm writing only the DLL linked to it.
If I put this line in the stdafx.h of the DLL it doesn't work:
#pragma comment(linker,"/manifestdependency:\"type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='x86' publicKeyToken='6595b64144ccf1df' language='*'\"")
InitCommonControls(); / InitCommonControlsEx();
is not working neither,
I need Common Controls 6.0 to show my tooltips controls and they work only with the manifestdependency line at the exe file / or manifest file to exe
Thanks for anyone who can help,
Mithrill
|
|
|
|
|
If you are allowed, then try modifying the manifest inside the executable, -as far as i know- it is stored as resource inside the executable and you can modify resources in the binary. Try using UpdateResource[^] or google for applications that can do this.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
Maybe there is a way to do that with
LoadLibrary(comctl32.dll)
GetProcAddress ???
In some kind of dynamic way ?
There must be a way
|
|
|
|
|
I wonder, does the exe load comctl32.dll but calls InitCommonControls[^] and not InitCommonControlsEx[^] and would it help if it were to call the Ex version? You could try hooking the InitCommonControls API method and call the Ex version instead, i wonder if that would work.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> If it doesn't matter, it's antimatter.<
|
|
|
|
|
I've found it easier to create a .manifest or .xml file in the res folder, and then add the apropriate entry to the .rc file.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
You cannot do this in a DLL, only in the original executable. The #pragma is meaningless in a DLL because it only gets loaded on demand and is not allowed to conflict with the settings of the main executable. You will either need to get hold of the source or object code of your executable and rebuild it or live with the problem.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
