|
You should find out first why your release build is linked with the debug version of the MFC.
Is this still the same project where you already recognised this?
If yes, I guess that there is something wrong with your release project settings.
You might use the Dependency Walker (depends.exe) Home Page[^] to check which DLL's are required by your application.
Note also that there are two definitions which are set accordingly when selecting the project build option: NDEBUG and _DEBUG. You should not change these. If you need to do so, create a special build instead of modifying the standard release or debug settings.
|
|
|
|
|
I have an idea The .lib I pointing to ucrt has both debug and release libs
Libcrt and libcrtd
If I just point it to the one with libcrt
Then those functions which require the debug build (erroneously ) should be unresolved
|
|
|
|
|
Why have you specified the CRT library in the project settings?
It is automatically selected according to the /M build option (static/dynamic, release/debug).
You should still use the Dependency Walker to check if there are more debug DLLs referenced.
|
|
|
|
|
I have MFC as a static build
I have used dependency walker against a DLL to see what functions they expose
I guess it works also against a .exe to see what methods are called
Thanks
|
|
|
|
|
Okay I finally ran dependency walker was absolutely no help all it told me that my module was dependent on MFC140D.DLL but which api Pulled this in ?
Next I turned to DUMPBIN a little more usefull but not by much so I used the /IMPORT option to see what calls my .exe is referencing from the Microsoft DLL's
By the way as a side not I ensure that both my native CRT call and MFC were dynamic wanted to be consistent
well for the regular windows .DLL as USER and GDI it (DUMPBIN) told me the API my program was referencing
Getting to MFC or MFC140D.DLL is became more secretive just showing the ordinal
number
|
|
|
|
|
You missed a library somehow. Hmmm what I might try is temporarily rename MFC140D.DLL and try a rebuild and hopefully you get a linker error.
In vino veritas
|
|
|
|
|
I did that and I got a whole slew of errors all related to the MFC wrappers my question would be then is there any difference between MFC140D and MFC140
I mean just the api's it exposes I am getting a whole slew of errors asserts and I am trying to track down the problem by removing piece by piece of my code related to the CDilaog which seems to be the problem I don't think its the fact that I am running with MFC140D as opposed to MFC140
Thanks
|
|
|
|
|
MFC140D is the debug build and MFC140 is the release build - I think.
|
|
|
|
|
You obviously have a real mess with the solution files. I think at this point I would either copy the directory and delete all the solution files or simply make a new directory and just copy the source files into it. Then set the solution up from new with the new directory with no existing solution files. I think that has to be the fastest way to solve it because it really shouldn't be this hard, its a lot less effort than what you are going thru.
In vino veritas
|
|
|
|
|
Leon my thinking exactly
I'll start from scratch (except for the source code)
when I first created the solution project I knew very little about the components I do now have a better idea
there are basically 3 components
1) C run time library such as sprintf
2) Windows native code user32 gdi etc..
3) the mfc wrappers
I am basically going to shared or dynamic linking for all three as opposed to static
Thanks
|
|
|
|
|
Well
At Leon's suggestion I started from scratch with a solution copying my code in
Guess what I noticed I had SetThreadName still my code. Obviously with no debugger this would cause problems
I am not by trade a Windows programmer but I will say this there seems to be somewhat of a window for (errors going from debug to release)
as having MFC140D.DLL in my module list I put MFC140.LIB as input to my linker to get rid of that problems
Again thanks to all who have been helping me
|
|
|
|
|
Finally, I solved my previous problem Re: Sum Multiple Value At a Time - C / C++ / MFC Discussion Boards[^]
I have a question in declaration why we declare sum = 0; if we declare only sum; what happen, what is the meaning of 0 and please clarify the function sum = sum+workhours; I have to understand whole thing.
#include<iostream>
using namespace std;
int main ()
{
int sum = 0;
int workhours;
int numemployee;
int employeewage;
int wage = 0;
cout << "Enter Number of Employee:";
cin >> numemployee;
for(int i=0;i<numemployee;i++)
{
cout << "Enter Employee Works Hours " << (i+1) <<":";
cin >> workhours;
sum=sum+workhours;
cout << "Enter Work/hrs Wage " << (i+1) <<":";
cin >> employeewage;
wage=wage+employeewage;
}
cout << "Total Work Hours: " << sum <<endl;
cout << "Total Wage:" << wage <<endl;
return 0;
}
modified 12-Sep-17 8:50am.
|
|
|
|
|
Well two problems if we imagine it uninitialized that is it will have some random value. The start value could be any integer value.
1.) Your sum starts at some random value then you do this line
sum=sum+workhours;
So your answer is some random value + the work hours.
Why bother calculating anything the total is just some random number.
2.) You print the answer even if you had zero employees you would print some random value.
The compiler will actually throw a warning about this line using uninitialized value due to that
The take home message here is variables don't magically start at zero if you want them to start as zero you need to set it to zero.
There is one subtlety here that when you are in debug mode it will initialize all variables to zero. That doesn't happen in release mode.
So new users when debugging often get caught out because when they look in debug mode sum will start as zero.
So the key here is don't set it to zero, compile in release mode ignoring the warning and run your code and watch some random number display. You will have your answer.
In vino veritas
modified 31-Aug-17 14:46pm.
|
|
|
|
|
Hi,
I am a beginner in C++. Today my first program is summed two value.
Question: Write a program that inputs the number of hours that an employee works and the employee wage. Then display the employee gross pay(Be sure promote to input).
I have a question here I input two value and calculate their result and display, but I want to input more than two value. How to input more than two value and calculate them?
#include<iostream>
using namespace std;
int main()
{
int i, m, j, n, k, l;
cout <<"Enter Your Work Hour:.\n";
cin >>i >>m;
cout << "Enter Your Salary:.\n";
cin >> k >> n;
j = i+m;
l = k+n;
cout << "Your Total Work Hour is:" << j <<endl;
cout << "Your Total Salary is:" << l <<endl;
return 0;
}
|
|
|
|
|
By 'more than two' do you mean a variable number of inputs, or a fixed number?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
Variable number of input..
|
|
|
|
|
In keeping with Davids theme, you could specify an array that's larger than you would ever need, and have the user enter the number of entries first, then setup an input loop based on that. Or setup a loop that runs the same number of times as your array size and have the user enter a value (like -1) that denotes the end of the data at which point you would exit the loop, then process the the data entered prior to the -1 entry.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
|
|
|
|
|
You'd need to use an array and a loop. Something like:
int hours[5] = {0};
for (int x = 0; x < 5; x++)
{
cout << "Enter hours worked for day " << (x + 1) << ": ";
cin >> hours[x];
}
"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
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Hi David,
I got it thanks for your help.
|
|
|
|
|
How to Terminate a thread created from CWinThread, without checking flag in thread function or ::TerminateThread (WinAPI)?
Example:
CWinThread* Obj;
Obj = AfxBeginThread(ThreadProc, this);
UINT ThreadProc(LPVOID *pVoid)
{
while(1)
{
//do something
}
return 0;
}
Now I want to terminate the ThreadProc without using flag or TeminateThread?
Thanks in Adavance 
modified 30-Aug-17 5:18am.
|
|
|
|
|
Why not just use the features that are available?
|
|
|
|
|
Just exit the thread function using a return statement (which is missing but required in your example code).
After adding the missing return statement, you may then also break out of the endless while loop.
|
|
|
|
|
Thank you for your response
I want to terminate the ThreadProc from outside of the thread
|
|
|
|
|
That was not really clear.
Then you have to signal the thread that it should terminate. If you don't want to use a global flag, use some kind of event. To check for events use WaitForSingleObject or WaitForMultipleObject (when multiple events must be handled).
Examples can be found in any MFC thread tutorial.
An old but very good article is:
Using Worker Threads[^] (see the Thread Shutdown Without Polling section).
Also available at WorkerThreads[^].
|
|
|
|
|
Member 13147508 wrote: How to Terminate a thread created from CWinThread, without checking flag in thread function or ::TerminateThread (WinAPI)?
Example:
CWinThread* Obj;
Obj = AfxBeginThread(ThreadProc, this);
UINT ThreadProc(LPVOID *pVoid)
{
while(1)
{
//do something
}
return 0;
}
The cleanest way to exit the thread is to return from the thread procedure.
And it is exactlz what your ThreadProc does!
So, nothing more!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
