I think there's no easier way, except maybe using CRichEditCtrl.

Generally, you do have to recompile if you want to be safe. However, unless you have changed the interfaces of those classes that used to be in the DLL before your modifications, you should run well without recompiling. Again, there are cases when this is not true. One example is if you access functions in that DLL by their ordinals - add or remove a function and you're probably in trouble. Bottom line - you can never be 100% sure (that's why COM is better than regular DLLs), but you definitely may try leaving those executables as they are. Test empirically. If it works for you, it'll work for your users also.

Call TextOut or DrawText twice, with a call to SetTextColor before painting each of the two words.

Error checking is skipped, but the code should be usable: CFile file; file.Open("file.txt",CFile::modeRead); int len = file.GetLength(); TCHAR pData = new TCHAR[len+1]; // +1 for terminating '\0' int read = file.Read(pData,(len+1)*sizeof(TCHAR)); file[read] = '\0'; // Could use CString in the following line, but what's the point? view_object.SetWindowText(pData); delete [] pData;

Use CWindowImpl::SubclassWindow. It is actually derived from CWindowImplBaseT.

It is because IE doesn't have a standard menu, but instead uses a Rebar band with menu in it. Sadly, there's hardly any way to retrieve IE's menu with GetMenu(). Instead, you may want to try using IE's automation interface. I haven't used it to get IE's menu, but it shouldn't be too difficult.

This should work: IPacificInterface* pPacific = NULL; pOceanInterface->QueryInterface(NULL, IID_IPacificInterface, &pPacific); If this fails, try all other possible derived interfaces until a call to QueryInterface succeeds. This is pretty much like using dynamic_cast to determine the type of object by pointer or reference to base.

You could have a class in a separate h+cpp pair, but only #include it in the dialog header. The only instance of this class would then be a member variable inside the dialog class. This would make sure no other code uses it. If you want to go further, the business logic class could have a private constructor, and the dialog class declared as friend - another step towards not letting any other code use the business logic class. If you're really fond of patterns, you could also make a class factory for the business logic class. See: http://en.wikipedia.org/wiki/Abstract\_factory\_pattern Hope this helps. Denis

You need atoi instead of itoa.

Dear colleagues, Does anyone know of a way to create a Netscape plugin (in C++) that would be always active for whatever MIME type is currently loaded? What I need is to slightly modify the contents of any and all pages opened. Please direct me to where to look for a solution. The Netscape Plugin SDK documentation gives no answer to this. Is it really impossible to "filter" page content? Thanks in advance!

Visual Studio 7.0 I presume? It's full of such bugs and once in a while I think of rolling back to my favorite 6.0. :((

Now that's really odd... :confused: Have you tried creating the thread with AfxBeginThread? I'm asking because Microsoft claims the other methods aren't MFC-safe.

_CrtISValidHeapPointer(pUserData) To find out what's wrong with this line, declare pUserData as constant pointer and see where you get compiler errors. ;)

Have you called DragAcceptFiles for the recipient window? :)

Sure thing it is good practice, how else would you make the system free the resources allocated for this timer? Chances are that when you replace the timer the whole thing deallocates correctly in the SetTimer API. Still better to be absolutely sure and kill the timer by hand. The name of the function (KillTimer) sounds terrifying, but it's safe to use unlike other functions with frightening names (e.g. TerminateThread). :)

Yes, it does matter for me. I'd create them immediately where they are used, but also exactly where "main" pointers to them are stored (i.e. those pointers you use to delete recordsets; it's important as this must be done only once and preferably in a function called from the destructor of your CDatabase or CFormView object). The worst thing to do IMHO is to split the code that works with these recordset objects into several parts based in different classes. Chances are all hell will break loose upon you when: a) execution flow comes to destruction and oops you overlook a leak or delete objects twice or whatever else... b) the program swells in size and soon you are no longer able to track down all activities associated with recordsets. Keep it simple. In the end it's much better to misplace pointers but code consistently keeping in mind this architecture than to make a correct design decision (if there is one) but implement it inconsistently or in a sophisticated manner.

This article is ok: http://www.coding-zone.co.uk/cpp/ARTICLES/090101accessodbc.shtml[^] However, to simplify things you may want to wrap all this ugly ODBC API into a class. This (like so many things around) has already been done. Search CodeProject, I believe there are several such articles.

It depends. IMHO, it would be much better to hold your CDatabase and CRecordset objects together in the CDocument-derived class of yours because they are essentially serving the same purpose - to link your views to data. However, if recordset objects are subject to heavy dynamic user-invoked changes, I'd normally prefer to associate them with views. That's what I think, although it's so much more a matter of preference than of being right or wrong...

Just found this link. The source code is Borland-specific, but you can figure from it what registry entries to modify. http://bdn.borland.com/article/0,1410,19646,00.html[^]

Look up words in a tiny dictionary of commonly used language-specific words. Examples for English would be: I, you, he, she, it, a, the, have, has, am, are, is.... (you won't need more than a dozen or so per language) Making a mistake is of course possible, but if you scan input thoroughly enough chances are you'll determine the language accurately. Of course, the issue must have been looked into by many philologists. Try searching the web. Technically, if you wish to avoid this method all you can do is try checking character codes unless you want to mess with checking the current keyboard layout. I've never tried the latter but it looks like headache and guarantees absolutely nothing...