Thanks for the input, using some kind of incremental search could be an option. However, my query was for a custom control with similar functionality as a CComboBox, but where the list box (the dropdown part) is replaced with a tree control or a menu with submenus. There's several examples here at codeproject, but I don't find any of them really cut for the job. It seemed like a pretty common problem, so there should definitely be someone out there having solved it.

I have a pretty large and old application where the user can select the current customer from a combobox. However, the number of customers have grown (>100) to the point where the users think that selecting a customer from the list is awkward. Does anyone have a good suggestion for a replacement for a CComboBox? The droplist portion should be a multilevel menu or a tree or similar ... I have seen several attempts here and in other places, but they all seem pretty experimental (non-standard UI behaviour, hardcoded drawing functions not utlizing themes, and so on).

There's a bunch of commercially availble tools for the job, you could check out Deja Vu, SDL Passolo or Idiom. If you google around for Flexytrans, you may find that one (it should be for free if you manage to find it). The more elaborate tools have loads of functions for working in teams. For the simpler ones, use the Clipboard to export the strings to text files.

Hi all, I'm using multiple document types (e.g. *.txt, *.xml) in a SDI type application, with two CSingleDocTemplate objects that handles two different file formats. The view class is the same for both document templates. However, when opening a file of the type that isn't currently open, MFC creates a new top level frame instead of disposing of the old view. This happens in CSingleDocTemplate::OpenDocumentFile, but I'm not that happy about overriding stuff about the view/doc logic of MFC. What I want is to keep the same frame for both document types, but from what I can read in the MFC source, the framework isn't really designed for that behaviour. Anyone with some experience of this?

Internationalisation is a huge topic, but a few pointers: 1. separate all UI strings from your code (string tables are a must in Windows) 2. do localizing into 1 other language in parallel with development to catch problems early 3. use industry standard tools (SDL, memoQ, Idiom, LocStudio if you can find it) for localizing, avoid developing your own tools 4. use the operating systems services whenever possible (NLS functions in Windows) Good luck!

A great step forward was to call CoUnitialize for each thread. Tried both with and without a message pump (with MsgWaitForMultipleObjects), the message pump version produced less exceptions, but the actual result of the conversion is the same. I'm really close to giving up on this, the combination of a under-documented API and multi-threading is a bit much :-) Currently, I have a pool of 4 threads for different converters (not only the Office ones, but for HTML and various other formats who are unproblematic). In case of the Office DLL converters, each thread in the pool kicks off another separate thread doing the actual conversion (the only way I could figure out to put a message pump there, and this is how it's done in the MFC/ole/Wordpad sample of MSVC). Everything works fine (with no exceptions at all and correct conversion results) if I block reentry at the call to ForeignToRtf32 with a CRITICAL_SECTION mutex. So if the application should do something with let's say *.docx files only, the performance boost from multi-threading is ... exactly zero (!) Functional, but what a waste of effort... Thanks anyhow for the interesting reading of marshalling!

No, I wasn't hoping that calling LoadLibrary from within the thread (that later will call ForeignToRtf32) would in some magical way make the DLLs thread safe. Did put some more effort into this, but couldn't find any real pattern. Did get rid of one exception type by balancing the calls to OleInitialize and OleUninitialize more carefully for each thread. Still getting a lot of exceptions of types 0x800401FD CO_E_OBJNOTCONNECTED and 0x8001010E RPC_E_WRONG_THREAD (though I'm not using any COM interfaces explicitly in my application). So back to my original question: Does anyone know anything about the thread safety of these libraries? Thanks

Check TextNotFound

Have you considered using some kind of macro (using a #define) instead of a function call?

Avoid multitasking if you can!

Hi all, I've been experimenting with the converter DLLs of Microsoft Office (under HKLM\Software\Microsoft\Shared Tools\Text Converters\Import). In a single-threaded environment, everything runs ok. But I'm running into difficulties when calling the exported conversion functions like ForeignToRtf32 in the multi-threaded version of my program, even if the libraries are loaded within the context of the calling thread. Does anyone know about the thread safety of these converters?

It might be that MSIE doesn't respond to WM_RBUTTONDOWN the way you hope. For all we know, it could be hooking in to some interrupt table or using a proprietary driver or ... Chances are that the handling of WM_RBUTTONDOWN is guarded by if(GetFocus() != this->m_hWnd) ... or similar. [EDIT] I just assumed that you've already tried with complete arguments (WPARAM/LPARAM) to the message?

modified on Thursday, April 21, 2011 7:47 AM

I think you're absolutely right on that, the dialog eats your return key press in IsDialogMessage. If you're using a dialog template you could try modifing the style in the resource editor instead of in your code. /M

Haha! Solved it seconds after posting:

DockPane(&m_wndTop, AFX_IDW_DOCKBAR_RIGHT);
m_wndBottom.DockToWindow(&m_wndTop, CBRS_ALIGN_BOTTOM);

Might help someone else ... /M

Hi all, Does anyone know how to (programmatically) dock two CDockablePane (or possibly CControlbar) on top of each other at the right side of the client window? I've tried just about every combination of alignment and CRect in calls to CFrameWndEx::DockPane, but to no avail. This is what I get:

This is what I want:

I would be really thankful for any input on this. Thanks /M (And, yes, I've searched the forums here but didn't find anything, I'm aware of the website www.google.com, and, yes, I know the location of the documentation for MFC and the Feature Pack, and, yes, I've tried just about everything I could come up with.)

Right, "your" was referring to the OP, naturally. Could have been more clear on that :)

The strange thing is that your code actually worked in the 32 bit edition. Any call to RegQueryValueEx using your parameters would result in an attempt to write something at memory address 200. Not good.

(I assume that the buttons you are creating are subclassed CButton.) The white spaces is created by someone somewhere. Did you check your handling of WM_ERASEBKGND?

It crashes when doing the actual function call? Hmmm ... Can you call anything in the DLL? Try calling a function returning void with no arguments, to eliminate problems with calling conventions and stuff like that. Does DllMain get called properly? /M

Conceptual answer: Didn't the boss hire the worker in some way? The boss should ideally be the manager for all the employees, that is, the boss should keep track of which workers that are entitled to salaries ...