Error message: Msvc32i MFC application has encountered a problem and needs to close MFC vc++ c++

Sometimes starting windows xp machine will get the following error message

msvc32i MFC Application has encountered a problem and needs to close.

This problem may occur if the ClientMan program is installed on your computer.

To resolve this issue, remove the ClientMan program from your computer by downloading and applying the removal tool. To do so, follow these steps:


1 Click Start, point to All Programs, and then click Internet Explorer.

2 Type the following Web address (URL) in the Internet Explorer Address bar:

3 In the File Download dialog box, click Save.

4 In the Save As dialog box, specify where you want to download the file, and then click Save.

5 Close all instances of Internet Explorer, and then close all Windows Explorer windows.

6 Double-click the downloaded Remcli.zip file.

7 In the WinZip dialog box, double-click the Remcli.exe file.
Restart your computer.

8 Locate the %SYSTEMROOT%\Program Files on your computer, and then delete the ClientMan folder from your computer.

Note %SYSTEMROOT% is a Windows environment variable that identifies the folder where Windows XP is installed (for example, C:\Windows). To view the value that is associated with %SYSTEMROOT% on your computer, and to view other environment variables on your computer, type set at a command prompt, and then press ENTER. Badge Printer Dubai, Cloud Based Card Printing

Error LNK2001: unresolved external symbol vc++ c++ error message

When compiling an MFC application using the single-threaded run-time library, you receive the following two unresolved external error messages:

nafxcwd.lib(thrdcore.obj) : error LNK2001:
unresolved external symbol "__beginthreadex"

nafxcwd.lib(thrdcore.obj) : error LNK2001:
unresolved external symbol "__endthreadex"

Starting with version 3.0, all MFC classes are "thread safe" and require the multi-threaded run-time libraries to link successfully. Many people try to use the single-threaded run-time libraries because they assume these libraries are needed to enable the application to run in Win32s. This is not the case. MFC versions 3.0 and later will use a single thread, so as long as you are not creating additional threads in the application, the application will run under Win32s.

To avoid these unresolved external errors, do not set the Project Settings to Single-Threaded for an MFC version 3.0 or later application. This setting can be changed by doing the following:

On Microsoft Visual C++ .NET 2003

1. Click the Project menu.
2. Click Properties.
3. Expand Configuration Properties, and then click C/C++.
4. Click Code Generation.
5. In the right pane, make a selection other than Single-threaded or Single-threaded Debug in the Runtime Library list.

On Microsoft Visual C ++ 2.x, 5.0, and 6.0

1. Select the Project menu.
2. Select the Settings... option.
3. Select the C/C++ tab.
4. Select Code Generation on the Category list box.
5. Finally, make a selection other than Single-Threaded on the Use Run Time Library list box.

On Microsoft Visual C++ 4.x

1. Select the Build menu.
2. Select the Settings... option.
3. Select the C/C++ tab.
4. Select Code Generation on the Category list box.
5. Finally, make a selection other than Single-Threaded on the Use Run Time Library list box.

Debug Assertion failed - Error message when upgrading Visual C++ to Visual C++ 4.2 or a later version mfc , vc++ , c++

When upgrading vc++ to Visual c++ 4.2 or later you may receive the following error message

Debug Assertion failed
Program: my.exe
File: dbgheap.c
Line: 1017
Expression:_BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

The reason for this error message is

The CWinApp destructor in MFC included with Visual C++ 4.2 and later now frees the data assigned to the member variables shown above by passing the pointer to the free() function. Doing this prevents memory leaks, which would occur if an MFC regular DLL were dynamically loaded and unloaded.

To solve this issue

If you assign a value to m_pszAppName, m_pszRegistryKey, m_pszExeName, m_pszHelpFilePath, or m_pszProfileName, the data must be dynamically allocated on the heap. You may want to use the _tcsdup() run-time library function to do this.

Also, free the memory associated with the current pointer before assigning a new value. Here is an example:

// First free the string that was allocated by MFC in the startup
// of CWinApp. The string is allocated before InitInstance is
// called.
free((void*)m_pszProfileName);

// Change the name of the .INI file--CWinApp destructor will free
// the memory.
m_pszProfileName=_tcsdup(_T("d:\\somedir\\myini.ini"));

VC package not available or not registered winform application c#.net vb.net

When you trying to create a winform application you may receive the following error message.

"VC Package not available or not registered"


The error is comming because the windows installer does not register TLBs and DLLs if the installer finds these items are already exists. In most cases, a previous version of Visual Studio .NET or Visual Studio 2005 causes this behavior, even if the previous installation was under a different operating system.


To solve this problem you have to repair visual studio .net because the repair process forces registration of items that are not re-registered during an install. To run repair follow the following steps.

1. Start -> Settings -> Control panel -> Add/Remove Programs.

2. Then the list of installed programs will poppulate.

3. Find and click on visual studio .net 2005 and click change.

4. Insert the product CD. If an installation wizard starts, cancel the wizard, and then proceed with the repair as outlined in the following step. If the product CD is not inserted before the next step, the CD may not be recognized.


5. Click Repair/Re-install, and then follow the onscreen instructions.

Cannot open precompiled header file: 'Debug/.pch': No such file or directory

I am working on a Managed C++ project and I get the following error:

TestThread.cpp(3) : error C2859: c:\projects\ProjectName\debug\vc70.pdb
is not the pdb file that was used when this precompiled header was
created, recreate the precompiled header.

Why would I get this error? How do I rebuild the precompiled header?
Clean Solution, Rebuild Solution, don't help.

If I manually delete the vc70.pdb, it doesn't seem to recompile. I've
also tried manually compiling stdafx.cpp. I get:

fatal error C1083: Cannot open precompiled header file:
'Debug/ProjectName.pch': No such file or directory

Any help is appreciated.

Managed C++ gets more and more frustrating every day.

This should not be caused, I think, by your use of MC++. Seems like your
project settings got hosed somehow. First, try if you like to disable
precompiled headers (it's in the compiler options in the project settings).
See if that helps at first. If it does, then try setting your settings for
stdafx.cpp to "Create precompiled Header" (/Yc) with stdafx.h, and then set
the rest of the files to "Use Precompiled Header" (/Yu) with stdafx.h. See
if that helps

C2447: missing function header (old-style formal list?) blog

The following error messages may appear if you try to use the function-try-block syntax.
error C2143: syntax error : missing ';' before 'try'
error C2143: syntax error : missing ';' before 'try'
error C2065: 'ii' : undeclared identifier
error C2143: syntax error : missing ';' before 'try'
error C2448: 'Unknown' : function-style initializer appears to be a function definition
error C2143: syntax error : missing ';' before 'catch'
error C2143: syntax error : missing ';' before '{'
error C2447: missing function header (old-style formal list?)

Back to the top
CAUSEThe compiler does not support the function-try-block syntax as specified in the...The compiler does not support the function-try-block syntax as specified in the C++ Standard (section 15) quoted below:

-3- A function-try-block associates a handler-seq with the ctor-initializer, if present, and the function-body. An exception thrown during the execution of the initializer expressions in the ctor-initializer or during the execution of the function-body transfers control to a handler in a function-try-block in the same way as an exception thrown during the execution of a try-block transfers control to other handler.
Back to the top
STATUSMicrosoft has confirmed that this is a bug in the Microsoft products that are li...Microsoft has confirmed that this is a bug in the Microsoft products that are listed at the beginning of this article.
Back to the top
MORE INFORMATIONSteps to Reproduce BehaviorThe following code example demonstrates the error: //...Steps to Reproduce Behavior
The following code example demonstrates the error:
//test.cpp
// compiler option needed: /GX
int f(int);
class C {
int i;
public:
C(int);
};

C::C(int ii)
try
: i(f(ii))
{
// constructor function body
}
catch (...)
{
// handles exceptions thrown from the ctor-initializer
// and from the constructor function body
} ID Card Printer in Africa

C2065: '' : undeclared identifier blog

Today, I'm going to talk about decltype, which allows perfect forwarding functions to have arbitrary return types. It's of interest to people who are writing highly generic code.





the return type problem



C++98/03 has an interesting blind spot - given an expression like x * y, where x and y have arbitrary types, there's no way to say "the type of x * y". If x is of type Watts and y is of type Seconds, then x * y might be of type Joules. Given print(const T& t), you can call print(x * y), and T will be deduced to be Joules, but this doesn't work in reverse: when writing multiply(const A& a, const B& b), you can't name its return type while preserving full generality. Even though when multiply() is instantiated, the compiler knows the type of x * y, that information is unavailable to you here. The C++0x keyword decltype removes this blind spot, allowing you to say "multiply() returns the type of x * y". (decltype is an abbreviation of "declared type"; I pronounce it as rhyming with "speckle type".)





decltype: the pattern



Here's how to write a completely generic functor that wraps operator+(). This Plus functor is not a template, but it has a templated function call operator that takes two arguments of arbitrary (and possibly different) types, adds them together, and returns the result, which can be of arbitrary (and possibly different from both of the arguments) type.



C:\Temp>type plus.cpp

#include

#include

#include

#include

#include

#include

#include

using namespace std;



struct Plus {

template

auto operator()(T&& t, U&& u) const

-> decltype(forward(t) + forward(u)) {

return forward(t) + forward(u);

}

};



int main() {

vector i;

i.push_back(1);

i.push_back(2);

i.push_back(3);



vector j;

j.push_back(40);

j.push_back(50);

j.push_back(60);



vector k;



vector s;

s.push_back("cut");

s.push_back("flu");

s.push_back("kit");



vector t;

t.push_back("e");

t.push_back("ffy");

t.push_back("tens");



vector u;



transform(i.begin(), i.end(), j.begin(), back_inserter(k), Plus());

transform(s.begin(), s.end(), t.begin(), back_inserter(u), Plus());



for_each(k.begin(), k.end(), [](int n) { cout << n << " "; });

cout << endl;



for_each(u.begin(), u.end(), [](const string& r) { cout << r << " "; });

cout << endl;

}



C:\Temp>cl /EHsc /nologo /W4 plus.cpp

plus.cpp



C:\Temp>plus

41 52 63

cute fluffy kittens



Compare this to C++98/03 's std::plus (which is unchanged in C++0x). Because it's a class template, you'd have to pass plus() and plus(), repeating the element types. Its non-templated function call operator has the form T operator()(const T& x, const T& y) const, making it unable to deal with 2 different types, much less 3 different types, without resorting to implicit conversions. (You can feed plus() a string and a const char *. That will construct a temporary string from the second argument, before concatenating the two strings. The performance of this is not especially desirable.) Finally, because it takes const T&, it can't take advantage of C++0x move semantics. Plus avoids all of this: Plus() doesn't repeat the element type, it deals with the "3 different types" case, and because it uses perfect forwarding, it respects move semantics.





trailing return types



Now, let's look at that templated function call operator again:



template

auto operator()(T&& t, U&& u) const

-> decltype(forward(t) + forward(u)) {

return forward(t) + forward(u);

}



Here, auto has a different meaning from for (auto i = v.begin(); i != v.end(); ++i), where it says "make the type of this thing the same as the type of whatever initializes it". When used as a return type, auto says "this function has a trailing-return-type; after I declare its parameters, I'll tell you what its return type is". (The C++0x Working Draft N2857 calls this a late-specified return type, but this is being renamed to trailing-return-type; see paper N2859.) If this seems suspiciously similar to how lambdas are given explicit return types, that's because it is. A lambda's return type has to go on the right in order for its lambda-introducer [] to appear first. Here, the decltype-powered return type has to go on the right in order for the function parameters t and u to be declared first. Where the auto appears on the left, the template parameters T and U are visible, but the function parameters t and u are not yet visible, and that's what decltype needs. (Technically, decltype(forward(*static_cast(0)) + forward(*static_cast(0))) could go on the left, but that's an abomination.)



As for the expression given to decltype, giving it the same expression as the return statement ensures correctness in all cases. (Pop quiz: why would decltype(t + u) be wrong?) The repetition here is unavoidable but centralized - it appears exactly once, on adjacent lines, so it is not dangerous.





another example



For completeness, here's that "3 different types" example:



C:\Temp>type mult.cpp

#include

#include

#include

#include

#include

#include

using namespace std;



struct Multiplies {

template

auto operator()(T&& t, U&& u) const

-> decltype(forward(t) * forward(u)) {

return forward(t) * forward(u);

}

};



class Watts {

public:

explicit Watts(const int n) : m_n(n) { }

int get() const { return m_n; }

private:

int m_n;

};



class Seconds {

public:

explicit Seconds(const int n) : m_n(n) { }

int get() const { return m_n; }

private:

int m_n;

};



class Joules {

public:

explicit Joules(const int n) : m_n(n) { }

int get() const { return m_n; }

private:

int m_n;

};



Joules operator*(const Watts& w, const Seconds& s) {

return Joules(w.get() * s.get());

}



int main() {

vector w;

w.push_back(Watts(2));

w.push_back(Watts(3));

w.push_back(Watts(4));



vector s;

s.push_back(Seconds(5));

s.push_back(Seconds(6));

s.push_back(Seconds(7));



vector j;



transform(w.begin(), w.end(), s.begin(), back_inserter(j), Multiplies());



for_each(j.begin(), j.end(), [](const Joules& r) { cout << r.get() << endl; });

}



C:\Temp>cl /EHsc /nologo /W4 mult.cpp

mult.cpp



C:\Temp>mult

10

18

28



You might ask, "is all of this generality really necessary?" The answer is yes, yes it is. I've already mentioned how perfect forwarding and decltype make arithmetic operation functors easier to use (by removing the need to repeat element types), more flexible (by dealing with mixed argument and return types), and more efficient (by respecting move semantics). Essentially, perfect forwarding and decltype allow you to write more "transparent" code. Inflexible code and inefficient code are not transparent - their presence can't be ignored.





advanced rules



decltype is powered by several rules. However, if you stick to the pattern above, they don't matter and it just works. I rarely get to say that about C++, but it's true in this case.



Although the vast majority of decltype uses will follow the pattern above, decltype can be used in other contexts. In that case, you've activated expert mode, and you should read the rules in their entirety. In the C++0x Working Draft N2857, they're given by 7.1.6.2 [dcl.type.simple]/4.





but wait, there's more



decltype is the fifth and final C++0x Core Language feature being added to VC10. While it wasn't in the VC10 CTP, it's in VC10 Beta 1. Also in VC10 Beta 1 are many C++0x Standard Library features, which I'll be blogging about soon!