http://www.xtremevbtalk.com/showthread.php?

t=130108
as you know, some messages to windows in another process work smoothly, like WM_GETTEXT and
WM_SETTEXT, even though they return/send data.

The mechanism that makes this work is often called "data marshalling".

Many of us know this and have used this feature, but I've often wondered, where is the definitive of list of
message codes that are known to the marshall?

Originally Posted by Steven Roman, "Win32 API Programming with VB" (O'Reilly, 2000), p 296
It is not clear exactly which messages are automatically marshalled by Windows, and which are not, so you
need to experiment.

http://blogs.msdn.com/

http://msdn.microsoft.com/en-us/library/aa365574(VS.85).aspx
Interprocess Communications
The Windows operating system provides mechanisms for facilitating communications and data sharing
between applications. Collectively, the activities enabled by these mechanisms are called interprocess
communications (IPC). Some forms of IPC facilitate the division of labor among several specialized
processes. Other forms of IPC facilitate the division of labor among computers on a network.

Typically, applications can use IPC categorized as clients or servers. A client is an application or a process
that requests a service from some other application or process. A server is an application or a process that
responds to a client request. Many applications act as both a client and a server, depending on the situation.
For example, a word processing application might act as a client in requesting a summary table of
manufacturing costs from a spreadsheet application acting as a server. The spreadsheet application, in turn,
might act as a client in requesting the latest inventory levels from an automated inventory control application.

After you decide that your application would benefit from IPC, you must decide which of the available IPC
methods to use. It is likely that an application will use several IPC mechanisms. The answers to these
questions determine whether an application can benefit by using one or more IPC mechanisms.

Should the application be able to communicate with other applications running on other computers on a
network, or is it sufficient for the application to communicate only with applications on the local computer?
Should the application be able to communicate with applications running on other computers that may be
running under different operating systems (such as 16-bit Windows or UNIX)?
Should the user of the application have to choose the other applications with which the application
communicates, or can the application implicitly find its cooperating partners?
Should the application communicate with many different applications in a general way, such as allowing cut-
and-paste operations with any other application, or should its communications requirements be limited to a
restricted set of interactions with specific other applications?
Is performance a critical aspect of the application? All IPC mechanisms include some amount of overhead.
Should the application be a GUI application or a console application? Some IPC mechanisms require a GUI
application.
The following IPC mechanisms are supported by Windows:

Clipboard
COM
Data Copy
DDE
File Mapping
Mailslots
Pipes
RPC
Windows Sockets

pplications that use OLE manage compound documents— that is, documents made up of data from a variety
of different applications. OLE provides services that make it easy for applications to call on other applications
for data editing. For example, a word processor that uses OLE could embed a graph from a spreadsheet. The
user could start the spreadsheet automatically from within the word processor by choosing the embedded
chart for editing. OLE takes care of starting the spreadsheet and presenting the graph for editing. When the
user quit the spreadsheet, the graph would be updated in the original word processor document. The
spreadsheet appears to be an extension of the word processor.

The foundation of OLE is the Component Object Model (COM). A software component that uses COM can
communicate with a wide variety of other components, even those that have not yet been written. The
components interact as objects and clients. Distributed COM extends the COM programming model so that it
works across a network.

Key Point: OLE supports compound documents and enables an application to include embedded or linked
data that, when chosen, automatically starts another application for data editing. This enables the application
to be extended by any other application that uses OLE. COM objects provide access to an object's data
through one or more sets of related functions, known as interfaces. For more information, see COM and
ActiveX Object Services.
Using Data Copy for IPC

Data copy enables an application to send information to another application using the WM_COPYDATA
message. This method requires cooperation between the sending application and the receiving application.
The receiving application must know the format of the information and be able to identify the sender. The
sending application cannot modify the memory referenced by any pointers.

Key Point: Data copy can be used to quickly send information to another application using Windows
messaging. For more information, see Data Copy.
Using DDE for IPC

DDE is a protocol that enables applications to exchange data in a variety of formats. Applications can use
DDE for one-time data exchanges or for ongoing exchanges in which the applications update one another as
new data becomes available.

The data formats used by DDE are the same as those used by the clipboard. DDE can be thought of as an
extension of the clipboard mechanism. The clipboard is almost always used for a one-time response to a user
command, such as choosing the Paste command from a menu. DDE is also usually initiated by a user
command, but it often continues to function without further user interaction. You can also define custom DDE
data formats for special-purpose IPC between applications with more tightly coupled communications
requirements.

DDE exchanges can occur between applications running on the same computer or on different computers on a
network.

Key Point: DDE is not as efficient as newer technologies. However, you can still use DDE if other IPC
mechanisms are not suitable or if you must interface with an existing application that only supports DDE. For
more information, see Dynamic Data Exchange and Dynamic Data Exchange Management Library.
Using a File Mapping for IPC

File mapping enables a process to treat the contents of a file as if they were a block of memory in the
process's address space. The process can use simple pointer operations to examine and modify the contents of
the file. When two or more processes access the same file mapping, each process receives a pointer to
memory in its own address space that it can use to read or modify the contents of the file. The processes must
use a synchronization object, such as a semaphore, to prevent data corruption in a multitasking environment.

You can use a special case of file mapping to provide named shared memory between processes. If you
specify the system swapping file when creating a file-mapping object, the file-mapping object is treated as a
shared memory block. Other processes can access the same block of memory by opening the same file-
mapping object.

File mapping is quite efficient and also provides operating-system–supported security attributes that can help
prevent unauthorized data corruption. File mapping can be used only between processes on a local computer;
it cannot be used over a network.

Key Point: File mapping is an efficient way for two or more processes on the same computer to share data,
but you must provide synchronization between the processes. For more information, see File Mapping and
Synchronization.
Using a Mailslot for IPC

Mailslots provide one-way communication. Any process that creates a mailslot is a mailslot server. Other
processes, called mailslot clients, send messages to the mailslot server by writing a message to its mailslot.
Incoming messages are always appended to the mailslot. The mailslot saves the messages until the mailslot
server has read them. A process can be both a mailslot server and a mailslot client, so two-way
communication is possible using multiple mailslots.

A mailslot client can send a message to a mailslot on its local computer, to a mailslot on another computer, or
to all mailslots with the same name on all computers in a specified network domain. Messages broadcast to all
mailslots on a domain can be no longer than 400 bytes, whereas messages sent to a single mailslot are limited
only by the maximum message size specified by the mailslot server when it created the mailslot.

Key Point: Mailslots offer an easy way for applications to send and receive short messages. They also
provide the ability to broadcast messages across all computers in a network domain. For more information,
see Mailslots.
Using Pipes for IPC

There are two types of pipes for two-way communication: anonymous pipes and named pipes. Anonymous
pipes enable related processes to transfer information to each other. Typically, an anonymous pipe is used for
redirecting the standard input or output of a child process so that it can exchange data with its parent process.
To exchange data in both directions (duplex operation), you must create two anonymous pipes. The parent
process writes data to one pipe using its write handle, while the child process reads the data from that pipe
using its read handle. Similarly, the child process writes data to the other pipe and the parent process reads
from it. Anonymous pipes cannot be used over a network, nor can they be used between unrelated processes.

Named pipes are used to transfer data between processes that are not related processes and between processes
on different computers. Typically, a named-pipe server process creates a named pipe with a well-known name
or a name that is to be communicated to its clients. A named-pipe client process that knows the name of the
pipe can open its other end, subject to access restrictions specified by named-pipe server process. After both
the server and client have connected to the pipe, they can exchange data by performing read and write
operations on the pipe.

Key Point: Anonymous pipes provide an efficient way to redirect standard input or output to child processes
on the same computer. Named pipes provide a simple programming interface for transferring data between
two processes, whether they reside on the same computer or over a network. For more information, see Pipes.
Using RPC for IPC

RPC enables applications to call functions remotely. Therefore, RPC makes IPC as easy as calling a function.
RPC operates between processes on a single computer or on different computers on a network.
The RPC provided by Windows is compliant with the Open Software Foundation (OSF) Distributed
Computing Environment (DCE). This means that applications that use RPC are able to communicate with
applications running with other operating systems that support DCE. RPC automatically supports data
conversion to account for different hardware architectures and for byte-ordering between dissimilar
environments.

RPC clients and servers are tightly coupled but still maintain high performance. The system makes extensive
use of RPC to facilitate a client/server relationship between different parts of the operating system.

Key Point: RPC is a function-level interface, with support for automatic data conversion and for
communications with other operating systems. Using RPC, you can create high-performance, tightly coupled
distributed applications. For more information, see Microsoft RPC Components.
Using Windows Sockets for IPC

Windows Sockets is an protocol-independent interface. It takes advantage of the communication capabilities

of the underlying protocols. In Windows Sockets 2, a socket handle can optionally be used as a file handle
with the standard file I/O functions.

Windows Sockets are based on the sockets first popularized by Berkeley Software Distribution (BSD). An
application that uses Windows Sockets can communicate with other socket implementation on other types of
systems. However, not all transport service providers support all available options.

Key Point: Windows Sockets is a protocol-independent interface capable of supporting current and emerging
networking capabilities. For more information, see Windows Sockets 2.
Send comments about this topic to Microsoft

Build date: 10/22/2009

http://msdn.microsoft.com/en-us/library/aa365780(VS.85).aspx
Pipes
A pipe is a section of shared memory that processes use for communication. The process that creates a pipe is
the pipe server. A process that connects to a pipe is a pipe client. One process writes information to the pipe,
then the other process reads the information from the pipe. This overview describes how to create, manage,
and use pipes.

http://msdn.microsoft.com/en-us/library/aa365799(VS.85).aspx

Multithreaded pipe server

Named pipe server using overlapped I/O
Named pipe server using completion routines
Named pipe client
Transactions on named pipes
Send comments about this topic to Microsoft

What is IPC?

IPC stands for Inter-Process Communication. This is a topic that applies to all multi-tasking Operating
Systems, and hopefully this and future tutorials will introduce readers to the general concepts, discuss the
Win32 features that support IPC, and provide specific examples for VB6 programmers.

For the purposes of this tutorial, a "process" is any instance of an executable program. "Application" will
generally refer to the program itself, i.e. it's design and construction. When you compile an application, you
get an executable file, e.g. "MyApp.exe". When you run it, you have created a process which is an instance of
that application. Run another copy and you have 2 instances, i.e. 2 processes running the same code.

IPC includes both the exchange of information between processes, and the synchronisation of processes.
Synchronisation refers to the requirement for tasks to be performed in sequence, or subject to special
conditions such as the availability of a resource, or the completion of task being performed by another
process.

Hopefully, maybe, eventually, we'll cover a good deal of the following possible topics, although not in strict
order (a section on Semaphores with a VB demo should be ready at the same time this is posted)

Hello

i am trying to send Variables FROM an ActiveX-Dll (wich i am running in an ASP script on a IIS webserver),

TO my VB app wich is running on the same server,

how would i send information to the vbApp?, but mostly
how would i get information FROM the vbApp, that i can send back thru
the ASP script (using oResponse.Write in the ActiveX-DLL)

NOte:for now i found no tutorials about this. I tried SendMessage to

write to a textbox in my VB app, however i couldn't figure out how to,
get information from the VB app..

any help would be verry appreciated,

cheers,

Anz

http://msdn.microsoft.com/library/en...unications.asp

http://www.xtremevbtalk.com/t125706.html
__________________
There are 10 types of people in this world, those that understand binary, and those that don't.

thanks alot

i'm glad the SendMessage and PostMessage are in the list,

i was afraid that it would be "unproffesional"

i also conscidered DDE, but i think it's pretty slow

another possibility is to use the GetWindowText API,

unfortunately i don't manage to get data from a textbox,
it only works for the caption of the app's form?
is there some other API that would allow me to read
the text of the textbox?

after looking into the MSDN-link u posted i seem to have found a

possibility with the WM_COPYDATA message ...gonna investigate

if I remember correctly, SendMessage with WM_GETTEXT should do it

__________________
There are 10 types of people in this world, those that understand binary, and those that don't.