1

Topic: How to read out messages from a window of other process

Hello. There is a pair of applications (they are mine), one, roughly speaking, a jacket, another - a kernel. The jacket creates the window (in the process) then generates application - a kernel which should "cling" to the window created by a jacket to create on it a context of a drawing and to receive messages.  between processes it is impossible, only through  the code. And  simply it is possible to hang up on messages? Like in MSDN would write that function - the receiver too should be in DLL or something such, but it is impossible to understand somehow. It is possible to direct, of course, messages from  to a kernel hands, through a file any, for example, but it is somehow too difficult...

2

Re: How to read out messages from a window of other process

Hello, Went, you wrote: Describe, please, a problem explicitly Actually, what it would be desirable to receive, and why the kernel itself cannot lift a window for an output? Redefinition of flows of input-output arises, recently did such (with technical curiosity), launching from pluses (jacket) the console application (kernel) on . Java threw in the console (System.out.print/println) the quitting data, pluses them received and displayed in the window. Approaches for any console kernel.

3

Re: How to read out messages from a window of other process

W> Sabklassit between processes is impossible, only through  the code. And  simply it is possible to hang up on messages? Like in MSDN would write that function - the receiver too should be in DLL or something such, but it is impossible to understand somehow. Win32-huk it also is one of methods inject': the code will be executed in a context of that process, which  a window. In my opinion better  a call between processes (as one of variants - through standard flows of input-output as it was offered above - How to read out the message with a window of other process). If it would be desirable ready, that is, for example, RPC.

4

Re: How to read out messages from a window of other process

W> Hello. There is a pair of applications (they are mine), one, roughly speaking, a jacket, another - a kernel. W> the jacket creates the window (in the process) then generates application - a kernel which should "cling" to the window created by a jacket to create on it a context of a drawing and to receive messages. W> Sabklassit between processes is impossible, only through  the code. And  simply it is possible to hang up on messages? Like in MSDN would write that function - the receiver too should be in DLL or something such, but it is impossible to understand somehow. W> It is possible to direct, of course, messages from  to a kernel hands, through a file any, for example, but it is somehow too difficult... The Kernel make COM out of proc server'. Calls from the program in a kernel and through rpc will reversely walk without additional . Well and to a kernel it is not necessary to be engaged in drawing explicitly, the data  for display still a variant, but drawing  it is not necessary is better. For this purpose it will be better to make a separate component which in the program by data of a kernel to draw. If the big speed/interactivity that with rpc is required it is necessary to be very accurate,  a lot of time is spent for switching of contexts.

5

Re: How to read out messages from a window of other process

Hello, Went, you wrote: W> It is possible to direct, of course, messages from  to a kernel hands, through a file any, for example, but it is somehow too difficult... I here would look: http://www.boost.org/doc/libs/1_35_0/do … sage_queue If hands. , the most simple variant.

6

Re: How to read out messages from a window of other process

Hello, CEMb, you wrote: CEM> Describe, please, a problem explicitly CEM> Actually, what it would be desirable to receive, and why the kernel itself cannot lift a window for an output? The jacket is a program-editor, and the kernel is an application-oriented application. The kernel can be launched independently, creating the window and working in a normal mode, and can - from the editor, in this case the editor creates a window (it  MDI applications), creates process of application-oriented application, informing through command line  on a window, which application should . In this mode the debag/analysis/editing of application-oriented application is produced. It is necessary that the window of application-oriented application did not argue for a place on the screen with the program-editor, and took a place of the normal document within client area. Pushed ctrl+tab - switched from application-oriented application to any document, edited, switched reversely and you look result. Or laid out a tile nearby, and you look at all in real time. CEM> redefinition of flows of input-output Arises, recently did such (with technical curiosity), launching from pluses (jacket) the console application (kernel) on . Java threw in the console (System.out.print/println) the quitting data, pluses them received and displayed in the window. Approaches for any console kernel. Yes, I something such also think. The master windows (jacket) will read out messages, to pack them in a file, and application-kernel will take away them from a file and ostensibly to "process".

7

Re: How to read out messages from a window of other process

Hello, plastictown, you wrote: P> I here would look: P> http://www.boost.org/doc/libs/1_35_0/do … sage_queue P> If hands. , the most simple variant. Yes, similar I also plan to implement something, only on the bicycle.

8

Re: How to read out messages from a window of other process

9

Re: How to read out messages from a window of other process

Hello, CEMb, you wrote: CEM> it is possible, I do not see all pattern, but I would make this moment so: CEM> 1. The kernel creates the window - apprx. CEM> 2. The jacket launches a kernel, the kernel creates the window (item 1), the jacket receives from it , tears off to it a head, puts on the MDI-window as the child and  events of type WM_SIZE to correct the sizes of a window of a kernel. Yes, the idea sounds sensibly, thanks. Only here we receive a reverse problem - now the editor cannot trace event of a window of a kernel (that will be necessary for editing). It is possible to arrive more artfully - to suppose a window on a window, it, probably, the best compromise variant