|
Because an MFC project will automatically include any dependent MFC libraries.
|
|
|
|
|
Ok, thanks that explains that. So is this linked version closer to the MFC-Static mode or shared DLL mode?
|
|
|
|
|
I think the majority of the standard libraries are DLL's as they are installed by default on all Windows systems.
|
|
|
|
|
Thanks for all your help. I think I understand now. I would assume an MFC application compiled with Standard Windows Libraries would still be dependent upon various MFC dlls such that the end users machines might still need the VC redistributable package installed, where as the Static MFC linking gets by that requirement. In other words, going with Standard Windows Libraries buys me nothing unless I am genuinely MFC free.
|
|
|
|
|
Yes, I think that's about it.
|
|
|
|
|
I'm trying to debug a single threaded C++ application. When the program reaches to a breakpoint, the thread state pass to "1". Then, when I press F10 (step-over), the program just continue and it doesn't go to the next statement.
|
|
|
|
|
This is often an indication that the debug database is out of step with the source; try a full rebuild and see if that improves things.
|
|
|
|
|
Either what Richard said, or you're trying to debug multi-threaded code as if it were single-threaded. You will need to freeze and thaw threads appropriately (one of the many things) if it were multi-threaded.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
hello guys... There is this folder which I really don't like to be displayed in my project/solution. When it is opened, I have to scroll all the way down to look for my desired files. Now I know how it can be disabled ( Tools -> Options -> Text Editor-> C/C++ -> Advanced ). But I want to know that how will it affect my projects in future. Although I read this article but still I could not get the idea. Any input is welcome. Thanks.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
If you don't want to see a "folder" in your solution, just remove it from said solution? or "unload" it from the solution ?
Or am I missing something else ?
Watched code never compiles.
|
|
|
|
|
Maximilien wrote: If you don't want to see a "folder" in your solution, just remove it from said
solution? or "unload" it from the solution ?
When I right click on this folder, niether I see Remove option nor the Unload option.
Maximilien wrote: Or am I missing something else ?
Well all I can tell is that this folder is created automatically. To better understand the problem, did you visit the link given in OP? May be you should read Disable External Dependencies in the first section named as Browsing/Navigation.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Overloaded_Name wrote: When it is opened, I have to scroll all the way down to look for my desired files.
Don't open it. This folder is required by the Intellisense system and gets rebuilt from time to time. If you never open it it really won't cause you any problems.
|
|
|
|
|
Well the problem is; it automatically gets open. I would never want to open it. Well nothing is wrong with this folder but it is really annoying that I have to scroll alot, to get to the bottom of the Solution Explorer.
Richard MacCutchan wrote: This folder is required by the Intellisense system and gets rebuilt from time to
time
This suggests that you are inclinded to NOT TO DISABLE IT.
This world is going to explode due to international politics, SOON.
|
|
|
|
|
Overloaded_Name wrote: it automatically gets open.
I use VS2010 Express Edition and it is always closed. Maybe you have some option set that opens it.
|
|
|
|
|
At the top of the "Solution Pane" there is a icon button "Show All Files" that toggles between two modes, one of them only shows relevant files in the pane. Maybe that can solve your problem.
|
|
|
|
|
Hi, I have a problem, i got a huge project which works nice in release build, but in debug version I get thousands of debug assertion failures, which i realy dont want to care about.
It is this kind of thing what is failing (in afxwin2.inl): (m_hWnd is NULL)
_AFXWIN_INLINE void CWnd::ShowScrollBar(UINT nBar, BOOL bShow)
{ ASSERT(::IsWindow(m_hWnd)); ::ShowScrollBar(m_hWnd, nBar, bShow); }
With these debug assertions it is not possible for me to Debug the project.
I just want to change a little part of the project, but without debugmode (i need traces and so on) this will become very hard, so it is in any way possible to switch them off ?
And yes, i know assertions are my best friend, because they tell me something is wrong, but in this case I do not want to care about what is wrong, I only want to get my work done quickly without reprogramming the application.
Thank you
|
|
|
|
|
You could try redefining the ASSERT macro into something that doesn't do anything.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
You sir, are a dangerous idiot.
Seriously, no one listen to this, it is dangerous stupid advise.
==============================
Nothing to say.
|
|
|
|
|
Erudite_Eric wrote: it is dangerous stupid advise.
You sir, are an illiterate idiot.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Well, its a nod to the colonials!
==============================
Nothing to say.
|
|
|
|
|
That would only work if you rebuilt the entire Windows debug library.
|
|
|
|
|
|
mackel90 wrote: i got a huge project which works nice in release build
You realize that the assertion is telling you that you are issuing Scroll Bar Functions to an object that is not realized as a window. That is, the fact that m_HWND is NULL means that you are trying to scroll a window that doesn't exist. I'm not sure of your definition of "working fine" but this ain't my definiton. You should fix these.
|
|
|
|
|
You should never, never ignore such assertions. If such assertions fail, it mean that your code is wrong and shouild be fixed.
By the way, if you somehow disable assertion there, then what would happen with assertion in your own code. Assertion is a tool to help make good and correct code. Learn to use them correctly.
Philippe Mori
|
|
|
|
|
This post shouldnt be voted down because it is important that beginner programmers understand why DEBUG ASSERTS must be resolved.
mackel90, you really need to learn to program properly. And so do your colleagues who put this project together. Read the other good comments here, and think very very carefully about what is being said.
YOU MUST RESOLVE THESES DEBUG ASSERTS BEFORE YOU BUILD A RELEASE VERSION.
It is also good practice to back up a DEBUG ASSERT with a line of code that checks the same thing and exits the func so in release mode you have the same level of protection.
==============================
Nothing to say.
|
|
|
|