Честно говоря, не доконца понял в чем ваш вопрос, но возможно следующая цитата из Рихтера про ваш случай.

NOTE
--------------------------------------------------------------------------------
You can send window messages across process boundaries to interact with built-in controls (such as button, edit, static, combo box, list box, and so on), but you can't do so with the new common controls. For example, you can send a list box control created by a thread in another process an LB_GETTEXT message where the LPARAM parameter points to a string buffer in the sending process. This works because Microsoft checks specifically to see whether an LB_GETTEXT message is being sent, and if so, the operating system internally creates memory-mapped files and copies the string data across process boundaries.

Why did Microsoft decide to do this for the built-in controls and not for the new common controls? The answer is portability. In 16-bit Windows, in which all applications run in a single address space, one application could send an LB_GETTEXT message to a window created by another application. To port these 16-bit applications to Win32 easily, Microsoft went to the extra effort of making sure that this still works. However, the new common controls do not exist in 16-bit Windows and therefore there was no porting issue involved, so Microsoft chose not to do the additional work for the common controls.

=================================================================================
В кратце смысл в том, что старые элементы управления работали через границы процессов благодаря поддержке в системе. Для новых такая поддержка отсутствует.