Mixing Strings and CStrings

I am mixing and matching various pieces of code I have found on the internet and or or purchased.

One of these pieces is a socket server written as a console app (off of codeproject).   This code uses "string" almost exclusively.

I am incorporating into this code another set of classes which came out of a dialog based application and uses "CString" extensively.

When I attempt to compile the resulting code, I get the following compiler error:

"error C2061:syntax error : identifier 'CString'.

Clearly the compiler does not recognise CString.

Do I need a 'using' statement?  Or how do I fix this?

Code example please.


Who is Participating?
DanRollinsConnect With a Mentor Commented:
Most ActiveX controls expect to run in a window.  If you start this as a Dialog-based app, then it is very easy to add the control to the dialog.  Just right-click in the dialog editor, select "Add ActiveX Control" and select it.  You can probably modify its properties right there in the dialog editor.  Then in the ClassWizard, under the Member Variables tab, add a control-type variable for that item.  The ClassWizard will then create a "wrapper" class that will provide access to the member functions and data.  To figure out how to use the control, you can look at its documentation (if available) and/or examine the .H and .CPP files generated by the ClassWizard.

-- Dan
NickGeorghiouConnect With a Mentor Commented:
Hi BeerFizz,

Is the project an MFC project? If not an MFC project then CString will not be recognised...

However I am not sure this is your problem. I would have expected an error more like undeclared identifier.


BeerFizzAuthor Commented:

In the property pages for the app it says under General:

Use of MFC:  Use Standard Windows Libraries
Use of ATL: No

Does that help?
Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

BeerFizzAuthor Commented:

looking at the code I noticed there was no inclusion of stdafx.h, so I inserted the following line at the top of the file containing the CString definitions
#include "stdafx.h"

this produced a different error message:

fatal error C!!89: #error : WINDOWS.H already included.  MFC apps must not #include <windows.h>

this error referenced the following lines in afxv_w32.h

#ifdef _WINDOWS_
      #error WINDOWS.H already included.  MFC apps must not #include <windows.h>

I commented the '#include "stdafx.h"' out and read up on CString.  I foudn that it needed the following headers, which I put in:

#include <cstringt.h>
#include <atlstr.h>
#include <afxcoll.h>

This produced the same error message as the previous include:

fatal error C!!89: #error : WINDOWS.H already included.  MFC apps must not #include <windows.h>

Any Ideas????   What other information can I provide to help solve this?

DanRollinsConnect With a Mentor Commented:
The simplest option would be to make a new project and this time, select ...
   Win32 Console Application
in the first step and select
   "An application that supports MFC"
in the second step.   Then start adding-in the source code again.

There are several issues regarding headers and libraries that the App Wizard handles cleanly to prevent the types of errors you are seeing.  It is probably quite possible to patch up your existing project to make it compile and run, but won't you feel better knowing that it is correct from the start?

-- Dan
BeerFizzAuthor Commented:

Dan, thanks for the response.  Yes I would feel better knowing it is correct from the start.

The code I originally pulled off of code project came with a .sln and .vcproj and that is what I started with; first doing the mods I needed before adding in the additional code (the stuff with the cstrings).

Actually, I guess what I really want to do is convert it to a dialog based app, however, it does a lot of console writes, which I guess I could convert to addstrings to a list box.   But my real concern with this approach would be some problem with the console code which would be the converse of the cstring problem.  Typically, can you easily convert a console app to a dialog app, assuming you handle all io to the console?
DanRollinsConnect With a Mentor Commented:
Yes.  I've found it generally quite easy to convert Console-style apps to Dialog-based apps.   Most Console apps don't need to do tricky U/I input and output -- they just dump a few lines of text to the screen.  The rest of the code is "generic logic" that ports easily into separate modules or same-named functions in the main module.

Also, console apps generally do all of their output in one or two specific areas of the code.  It's pretty easy to change every call to, say printf(...) to a call to some internal function, called, for instance, TextBoxOutput(...).

BTW -- in this case, I'd recommend using the AppWizard to "start fresh" with dialog-based app.
AndyAinscowConnect With a Mentor Freelance programmer / ConsultantCommented:
Also consider if your app would be requiring a menu and/or toolbar.  If yes then I would recommend an SDI based app with a CFormView based view rather than dialog based.  (You would get the code for the menu/toolbar implemented 'for free', a diaog base app and you would have to add some code to support those).
BeerFizzAuthor Commented:

I took the initial approach of creating a console app from scratch with support for MFC, it seemed the simplest approach and I could later convert it to a dialog app.  

After creating the MFC console app, I brought over the socket server code and incorporated it.  Unfortunately there were a host of additional compilation problems.  It appears this code was written pretty tightly for win32.

So, I have another potential approach I might try which is:   The set of classes I am trying to incorporate into this console app comes as source and also as an OCX.

Question, can I incorporate the OCX into this win32 console app?  If so, please be specific.

BeerFizzAuthor Commented:

If I go into

tools/add remove toolbox items... and then to the comm components tab I can scroll down to my OCX.  I can check the box and then say add.  But what next?

My level of knowledge here is that the next step would be to drag the ocx icon off of the toolbox and onto a dialog.   Then I would be able to include the .h and use the functions.

In a win32 console app, what do I do?

BeerFizzAuthor Commented:

This has been tough, but I think I'm down to the last couple of compilation errors.  The following is the code:

   private :

      static void *operator new(size_t objSize, size_t bufferSize);
      static void operator delete(void *pObj, size_t bufferSize);

void *CIOBuffer::operator new(size_t objectSize, size_t bufferSize)
   void *pMem = new char[objectSize + bufferSize];

   return pMem;

void CIOBuffer::operator delete(void *pObject, size_t /* bufferSize*/)
   delete [] pObject;

error C2059: syntax error: 'string'
error C2091: function returns function
error C2802: static member 'operator new' has no formal parameters

Any idea on how to fix this?

PS. I should have made this 5000 point :)
BeerFizzAuthor Commented:

I give up on using this code i pulled from codeproject.  Don't know what I'm doing wrong and at this point I don't care.

Please could you recommend to me a base set of code which I can use as a socket server.

This code from codeproject was almost ideal as it created a 'socket thread pool' and a 'business thread pool'.   This is a link to it:

I have a web site with some php which I have successfully talking to this server.  I am able to throttle the business pool side down to one and it will take multiple requests from the web and queue them up feeding them serially to the business logic side.  This is a requirement as my business logic can only handle one user at a time.

Are you aware of any similar code i can use?
Thanks for the points.  
I did check out that codeguru page and it looked like the author had written a nice piece of code.  As he said, it was designed to be a separate logic-only blackbox with the expectation that any desired kind of U/I code could be grafted onto it.  When you decided to give up on it, well, so did I :-)  Good luck in finishing your task.
BeerFizzAuthor Commented:

After getting over my frustration, I had another go at it.  (My 19th attempt I think)

This time I put all the MFC code in a DLL.   This separated the two conflicting systems.

So, that part of the code is working very nicly...  

Onto my next set of problems :)

Thanks Dan,
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.