ATL / WTL / STL

Garth J Lancaster wrote: c) In VS2008, open your project, Under 'Additional Include Directories', include ${COMMON_CODE} (I think you need a space between this and the other directories iirc) The include directories should be a semicolon-separated list. The directories themselves may (or may not) contain spaces. In the bigger picture, I endorse this way of specifying directories. If I understand the original problem properly, OP used a full filespec for an include directory. Visual Studio likes to keep track of file and directory locations relative to the location of the project file (or solution file, depending on things). If you get a solution/project working in one location (which points to an absolute file/folder location) and then copy the solution/project to another location, the 'relative' file/folder pointers will be wrong. Garth's solution should fix that part of the problem. -- Harvey

Only time I've had to do it was when I didn't have the source to a third-party dll. You should be able to have the rest of the application be debug and your third-party dlls be release mode with no issues (obviously you can't debug the inner working of those dlls but they're still loaded and working). With that said though... it's probably better practice to run the whole thing in debug or release (a lot can go wrong with the mixed assemblies).

In the above scenario u can use vector which would maintain the count of questions.Second thing if u want to provide some uniqueness to the question I think u should take a timestamp as variable in your question class which is updated when u create a question and will be overwritten if u modify that question. Thus ur count and uniqueness will remain intact.

hm this doesnt help me... can you please just answer the question if you know it thanks Frank

bkelly13 wrote: I realized the project was set to build the realease version. Yeah, we've all done that once or twice. The thing with the Release build is that variables can get optimized away that will always show up in the Debug build. BTW I don't think that rebooting would have made any difference to the situation.

khaliloenit wrote: there is no version 64 for driver for mdb files That is true, so I'm afraid you have to keep it as 32 bit.

I assume then that you are talking about the file with the same name as the solution. This is created and used by Visual Studio that contains information about the solution and it's references.

Having originally started with C, I too prefer returning an error code to be cleaner than catching exceptions, but I'm sure others see exceptions as the true C++ method for handling errors.

Review all the macros available to help with unicode/non-unicode compilations from MFC: What are TCHAR, WCHAR, LPSTR, LPWSTR, LPCTSTR (etc.)?[^] If you don't want to use MFC, you can always make your own macros to do the same thing... they're all relatively straight forward.

after a long time seeing you here <>:thumbsup: Jibesh V P

After writing the OP I outlined the process with all the steps then began to implement. I have started using a common directory for re-usable code. In order for the Manager to call a method in its creator it must know the name of the owner's class. To do that I added a forward declaration in the Manager. However, this means that when the class is re-used, and the owner has a different name, the Manager must be changed. There is another indicator this is a bad practice. After the forward declaration in the dot H file, the dot CPP file needs to reference the dot H file of the owner. The common code resides in another directory and it cannot find the central code of the main project unless it is specifically spelled out. Then, if the project is moved or re-name, the common code must change. There may be a way to do this automatically using directive and path names within Visual Studio. But I now think that even if that can be done it would be miss-guided. Conclusion: A utility class can call "down" the heiarchy to objects it creates, but should not call up to its owner. While the concept of it calling up may make the owner code neater, it represents an inversion of authority. (Regardless of how the methods are name, a call up in an inversion.) Problems remain: The main application uses pointers into the lower level objects to accomplish its tasks. How does it become aware that the lower level needs to exit, or maybe even has already exited. Controlled exits: When the TCP sending function detects that the client has closed the connection it does not exit right away. It waits until the upper level code calls the method to send the data. Then the lower level returns an error code stating that the data has not been sent and that the object is exiting. Uncontrolled exits: I generally do not like exceptions, but this appears to be a time when an exception is warranted. When the lower level must terminate unexpectedly, then an exception could work its way back to the upper level and the exception handler can NULL the pointer. Thanks for your time

This is just too funny. sigh, in a sad sort of funny.... So, I have managed to muddle along as there simply is no time to re-write this app. Yet. I can get it to run in the debugger under Windows 7, so that's what I've been doing. Fast forward three months. New laptop, new Windows 7 install (should be basically the same, but who really knows?), new VM, etc. Guess what's running now? :mad: Thumps along just fine. I know the bug is still there, I'm not that dellusional. Charlie Gilley You're going to tell me what I want to know, or I'm going to beat you to death in your own house. "Where liberty dwells, there is my country." B. Franklin, 1783 “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759

khaliloenit wrote: when i run my code the API above fails. Well, as I said, we cannot see your screen so we have no idea what may be happening. One of these days I'm going to think of a really clever signature.

You mentioned Inside COM by Dale Rogerson which remember using so I had a glance at my bookshelves. I know Inside COM taught me the underlying principles of interfaces and COM without resorting to ATL or MFC. Professional COM Applications with ATL (Wrox, 1999) was quite good on Active X, and does have a section 'Building an ActiveX Calendar Control' which explains a lot. However something like this, whilst being the same era as Inside COM, refers to VC6 and ATL3, not the most up to date now. I did also buy ActiveX Controls Inside Out (Microsoft Press, 1997) and see it on my shelf but this is un-thumbed so I obviously didn't use it a lot, but its more wider ranging than the ATL book mentioning MFC and Visual Basic controls (VBXs). I don't want to sell mine but hope this might help.

If you want to be able to count instance hits, have a look at the shared memory option here.[^] This article also shows some other techniques which I think fix some of the problems described in Joe Newcomer's article first referenced above. I have used the shared memory technique to inhibit multiple instances of a program as well as manage some common data in a program where I allow multiple instances. [I have a lot of respect for the technical output of both of these authors.] -- Harvey

Thank you! Pretty much all areas of programming can become tricky if you cross the line. :-) I've always considered myself a generalist programmer and I'm definitely not a network expert. I've just had the luck to work on some specialized networking apps.