I absolutely love my iPad. It is almost always with me. It is so useful and productive for me. I am very rarely on my laptop anymore. I use it for web, of course. But also for reading docs/email from work, for writing music (many MIDI capable synths, drum machines, sequencers) and live performance, calendar, task lists, incredible photo editing abilities, write notes, design user interfaces and then mail out to my team, plan out my software meetings, play games. With SplashTop, I can walk the iPad over to someone's office and show them something new I've added to the product. I also created an Excel spreadsheet so my wife can keep track of our daughter and her gymnastics team scores during competitions (much easier than bringing a laptop). I recently went on a two week vacation and left my laptop at home. I used the iPad to download all of my photos. Basically everyone around me knows how ecstatic I am over it. It is so useful and productive and fun! I continue to find new uses for it. My wife also has an iPad and likes it as well, though she doesn't use it for nearly all the same things as I do.

Thanks again for the input. Took me nearly two weeks, but I finally figured out the problem. It turns out we had two classes derived from std::string. I did not realize we had classes derived from std::string. I had noticed in a smaller test case, adding a certain #include would show the problem. Removing the #include and things would compile/link just fine. Unfortunately, there is a HUGE trail of #include's in that one header. This led me to slowly move #include's out of headers into CPP files allowing me to narrow down which headers were causing a problem. Eventually I got things down to where I noticed one of the std::string-derived classes and I went, "Aha!". Changed it to a 'has a' and the problem went away.

Thanks everyone for the helpful input. It does seem like something strange with the project. I wrote a test console application and got no linker errors. And the same calls link in other projects within the Solution just fine. I compared projects and am unable to find a difference between a project that works and a project that does not work. I am now trying to clean up code. The pre-compiled headers have includes for a ton of STL includes. I removed the one for string and am converting the headers and CPP files appropriately to see what happens. Anyway, it does seem to be something odd with this project. Everything worked fine in VS 2005. We never upgraded to 2008 and now I'm converting to 2010. EDIT: As a result of this exercise, I did run across several headers which were also including string, so I was able to clean those up.

modified on Monday, June 7, 2010 4:42 PM

I ran into something I don't understand. The following line is producing another unresolved link error. 'buf' is a std::string.

std::getline(stream, buf,'\n');

We have the same line of code in other projects that compile just fine. Below is the link error. To resolve the problem, I changed buf to a char[1024] and am calling stream.getline(buf, sizeof(buf), '\n'). But why am I getting this link error in the first place? The projects which compile fine are REQUIRED projects for the project giving me this problem. I don't know if the chain of links has something to do with this, but I thought I'd at least mention it.

18>SimpleMCSFile.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > & __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::operator+=(char)" (__imp_??Y?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAEAAV01@D@Z) referenced in function "class std::basic_istream<char,struct std::char_traits<char> > & __cdecl std::getline<char,struct std::char_traits<char>,class std::allocator<char> >(class std::basic_istream<char,struct std::char_traits<char> > &&,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > &,char)" (??$getline@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@YAAAV?$basic_istream@DU?$char_traits@D@std@@@0@$$QAV10@AAV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@0@D@Z)

I am moving our project from VS 2005 to VS 2010 and am running up against some linker errors. std::string being multiply defined is one issue, but I will take some more time to look into that one. The one I am really confused about is the std::string constructor. We have been using

// aCharArray is a char[]
std::string abc(aCharArray, 20);
// aStdString is a std::string
std::string anotherExample(aStdString.c_str(), 20);

without any problems. Now VS 2010 is giving me an unresolved external during linking. It is thinking I want the constructor std::string(const char*, unsigned int) which IS what I want. It used to be defined, and it does still seem to be defined. For some reason, updating to VS 2010, it is no longer linking, though. Is the implementation for this constructor perhaps missing? Anyone run into this or can anyone confirm the same issue? Thanks. Resolving these is pretty easy, but I am left confused as to why it gets unresolved external.

Aha! Thanks. That was the problem. I turned off UAC and everything works just as I would expect (like on XP)! I always leave UAC turned on because it's great for finding issues our customers will run into. I didn't even think about turning it off this time around.

Something puzzling is happening and I don't understand why. I tested using both my C# and VB.NET test apps and both result in the same behavior. When I run the application I have the following line (C#):

m_COMApp = new SignalServer.Application();

No matter what I do, I always get a new instance of the COM server, even if the server is already up and running. This does not happen in XP and I don't recall it ever happening under Vista (I plan to re-test that this weekend as I have Vista at home). This only happens when I run the COM client directly from within Visual Studio. I even changed my reference to point to another version of the server, and it still wanted to load the server found in the original directory. I decided to run the application by double-clicking in Explorer and then I get the expected behavior. That is, if a server is already running, it will simply attach to the currently running server. Anyone know why I get the other behavior? Some thoughts are: 1) I am on Visual Studio 2005. Maybe this won't happen in 2010. 2) All the applications are 32-bit apps and the OS is 64-bit. Maybe because of the x86 directory names, things get a little messed up? Anyone else experience this? Thanks for any information.

You are probably correct. I have now spent more time with things and have things working pretty well. I think I have the solution I was looking for.

By losing the sort, I mean I can no longer sort when clicking on the column. This is just the nature of using a List or array as your datasource as they don't know how to sort per column. Also, when I say this is in-memory data, what I really mean is this is not connected to a database. I now have things working by deriving from IBindingList and implementing the sort routines as well as adding a Comparer, but it took me awhile. I tried How To Allow To Sort By Multiple Columns in Custom Data Binding which would not compile. It is based on an article from MSDN. So I fixed up the code to be like the MSDN article and, though it would compile, I still could not sort on my columns. I ended up having to use a sample in the MSDN Library for an IBindingList interface. But even THAT example does not show how to sort. So I took the necessary bits I needed from Implementing a strongly typed collection with sort/filter/GetChanges features and finally got things working.

I want to bind an in-memory data class to a DataGridView using the DataSource member. I have read several ways of doing this and have implemented and tried several but once I set the DataSource, I then lose the ability to sort. I want to display my data class inside of a grid. I can use a List (List < MyDataClass >, for example) which works but I lose sorting. I can get sorting back, but I have to create my row like this object[] row = {MyDataClass.FirstName, MyDataClass.LastName}; which then removes the binding to the actual objects. I've now been trying to use DataSets and DataTables, but I still lose my binding. And the columns are not automatically generated from the exposed properties, like when I use a List collection. My next step is to create a class implementing the IBindingList interface. Will this be what I want? Any help or advice is greatly appreciated. Thanks. Oh, another wrench in the idea is that I want to flatten out the object. So my object may contain other objects which I want to also display in the table as part of the same row. I was thinking there was a way to bind a specific grid column to an object's property, but I haven't been able to find that yet.

Yes. You can maintain your old MFC client application while calling into new managed DLLs. In fact, this is an article I've wanted to write for awhile. Any file which will be calling into a C# DLL will need to have the following options set in its Properties dialog: * C/C++/General - Compile with common language runtime (/clr) * C/C++/General - Debug Information Format - Program Database (/Zi) * C/C++/Code Generation - Basic Runtime Checks - Default (others may work too) * C/C++/Code Generation - Enable Minimal Rebuild - No * C/C++/Code Generation - Enable C++ Exceptions - Yes With SEH Exceptions (/EHa) * C/C++/Precompiled Headers - Create/Use Precompiled Header - Not Using Precompiled Headers Add the following near the top of your file (after #include's) * #pragma managed * using namespace System::Windows::Forms; * using namespace MyManagedDLL; ...and any other namespaces you may want to add. This just makes coding easier so you won't always need to prepend your classes with the fully qualified name. Right click on your project and select References. Add the following references. * mscorlib * System * System.Windows.Forms * Your special C# DLL Depending on your code, you may need to add more References. You will receive compilation errors if anything is missing. The above will allow you to call a managed DLL from your client MFC application. There might be one thing I left off. I've had others do this same thing and I recall one time someone mentioning they had to add another reference I missed. Going from managed to non-managed is a different story. One option is to use P/Invoke, but that is really best used for calling 'c' functions, not for C++. There is quite a lot written in regards to P/Invoke on this site. http://www.codeproject.com/KB/miscctrl/HostMFC.aspx[^] I haven't yet used it, but plan to look more into this for work when I have more time. This is a project explaining how to host your MFC application from within a .NET App Framework. It looks very interesting. I have not really had any pitfalls, but there are some things to be aware of. You will need to write code to convert between your C++ data types/classes and the managed data class. You will need to write this code in C++ using CLI.

Thanks for the answers. That is what I figured, but wanted real data to support it.

I am just curious as to the best practice for suspending a thread. We have a thread that every once in awhile is required to do something. I am currently using SuspendThread on the CWinThread object. When the thread needs to do work, I Resume the thread. That seems to work well and does not eat up any CPU. But I am just wondering if a better way is to WaitForSingleObject and use an Event to resume the thread. Using SuspendThread works and is certainly easy to implement, but am just curious which way may provide a better design. Thanks for the insight. Note: We were originally ending the thread when it was done with its job, but ran into some other problems. This thread calls into something else which uses OpenMP for multi-threading. When our C++ client thread ended, the OMP threads did not seem to get removed so we kept accumulating OMP threads until we eventually get an error saying too many OMP threads.

Here! Here! This site is always the first place I look and has been an unbelievable amount of help. I have told many others about this site.

This is exactly what I have been doing for the last 4.5 months. I was hired on to port an application from Borland to VS 2005 with some C# sprinkled in there. To be more specific, I am porting from Borland OWL. Are you using OWL? Sorry, I am not familiar with Borland C++ Builder or the Borland tools. I'm just porting code and we use a makefile to compile the Borland code. I can give you some pointers if you are using OWL. A lot of the classes and methods transfer quite easily to MFC. Things like TDC is a CDC, TPen is a CPen. There are other portions of Borland which are nice and make you wish MFC had the same thing. For example, Borland has an actual color class (TColor). There is no equivalent in MFC so I had to use a COLORREF and the RGB macros in place of TColor. There are other helpful Borland classes which you just need to figure out how to do the equivalent in MFC. Since you will be working with MDI, you should be aware of Borland's window structure. Do you have a background in MFC and how the window classes relate? In MFC, a window contains a MainFrame which itself controls the MDIClient window. These are one-in-the-same when it comes to MFC classes. In Borland, you actually have two separate classes. A TMDIClient class and TMDIFrame/TDecoratedMDIFrame. You will need to convert the two classes into the one CMDIFrameWnd. Does the project use STL? The STL is different between the two and requires some minor name changes. A compile error will point this out and you can usually figure out the equivalent just looking it up on MSDN. Unfortunately, there is really no information on-line for Borland information. I use their OWL help documentation if I ever get stuck. This should at least give you a heads up. Let me know if you have any more questions or concerns. We can take this to e-mail if necessary.

Thanks for the feedback. I spent all day at work trying to figure this out and found it last night while continuing my search at home. As a sidenote, Borland OWL separates the MDIFrame from the MDIClient with distinct classes. MFC does not have this distinction, so I am having to combine the two Borland classes we have into a single CMDIFrameWnd derived class.

I think I may have found what I need. I don't believe what I'm asking is possible. I finally found a thread over on MSDN[^] with someone asking a very similar question. I am now going to take the approach of using a CDialogBar[^]. Still open to suggestions, though.

Splitters seem like a popular topic. I have found several examples here, elsewhere, and in the forums. But I can't seem to find any which answer my question. I am converting a Borland C++ application to MFC. The application has a split window with a Tree on the left side, and multiple windows on the other. Basically, the right side is similar to MDI allowing for multiple windows to display at one time. From all my research today, it seems like splitters allow for only a single window at a time and the window will fill/maximize the entire split window. Is there some way to get multiple windows within a split window? I may start looking at Borland's internal code to find out how they do it. Or my boss may end up deciding to scrap the multiple window idea. I suspect it is not really a major feature as most people probably maximize the window anyway. Thanks in advance for help or pointers.

Hmmm, strange. Apparently I did not erase it. It seems the forum is completely deleting my code. I just typed it again in my previous message and it does not show up in the post. Somehow it worked when you typed it in your post. I wonder why.

Ooops. I copied the code from one of my own projects and had to rename things from my class name to CMainFrame. I accidentally erased . Very sorry about that. Glad you still figured it out. I ran into my own pet peeve of someone giving a code example which doesn't work.