Pasar mensajes con punteros a otra aplicación

[[escafandra]]

Por lo que se, para que TApplication reciba un mensaje de usuario hay que definir el evento Application->OnMessage = AppMessage; y escribir AppMensage:

//---------------------------------------------------------------------------
void __fastcall TForm1::FormCreate(TObject *Sender)
{
  // Asignación del procesador de mensajes para la aplicación y sus ventanas
  Application->OnMessage  = AppMessage;
}
.
.
.
.
//---------------------------------------------------------------------------
void __fastcall TForm1::AppMessage(tagMSG &Msg, bool &Handled)
{
   // USERM_SETPARAM Mensaje de Usuario pasar parámetros
   if (Msg.message == USERM_SETPARAM){
     CmdLine = (char*)Msg.wParam;
     Handled = true;
   }
}

Para que esta forma de enviar mensajes funcione, deben enviarse con la funcion PostMessage. No admite SendMessage del API de Windows, según la propia ayuda de Builder y mi propia experiencia.

El problema está que la ayuda de Builder advierte que no se pasen punteros pues se perderán antes de recibir el mensaje.

He comprobado que si ese mensaje con punteros se envía desde la propia aplicación, el puntero no se pierde. Sin embargo, si es otra la aplicación que lo envía, se recibe el puntero, pero su contenido es NULL.

Se me ocurre sobrecargar la funcion TApplication:WndProc(Messages::TMessage &Message), pero me parece engorroso.

¿Alguien tiene una idea de un método más simple?

Saludos

[jachguate]

¿son ambas aplicaciones hechas en builder?

Si es así, revisa la idea de Al de los objetos SuperGlobales

Hasta luego.

[Mick]

El problema lo estas enfocando de una manera incorrecta, cada aplicacion tienen un espacio de direcciones distinto, y no se ven unas a otras, aunque pases el puntero de una aplicacion a otra (total solo es un numero una direccion de memoria) no podras hacer nada con eso para acceder a los datos de la otra aplicacion ya que te saldra un "access violation".

Tendras que usar ficheros mapeados en memoria o crear memoria compartida, para que las dos aplicaciones puedan acceder a la misma zona de memoria.


Ssludos

[[escafandra]]

jachquate, si, ambas aplicaciones están escritas en Builder.
Mick, No estoy muy seguro de que no pueda pasar punteros por los espacios de memoria diferentes. No obtengo errores "access violation", simplemente el valor se borra, como advierte la ayuda "Si se usa PostMessage".

Por otro lado el propio Windows tiene mensajes para pasar texto WM_GETTEXT y WM_SETTEXT. Y con esto yo si paso texto con las API.
Yo pretendo un mensaje de usuario para poder interceptarlo inequívocamente y de alguina manera emular lo que el propio windows hace...

Me miraré lo de los objetos superglobales....

Gracias

[[seoane]]

Si se pudieran compartir punteros a través de simples mensajes me pregunto para que creo microsoft el mensaje WM_COPYDATA.

En realidad es como te dice Mick, no se pueden compartir punteros entre aplicaciones. Sin embargo con ciertos mensajes puede dar esa impresión, pero es internamente windows el que se encarga de "copiar" los datos de un proceso a otro.

En resumen, yo utilizaría WM_COPYDATA que por algo lo creo microsoft

[[escafandra]]

Muchas gracias [seoane]. Voy a seguir tu consejo.

EDITO:
Parece ser que sólo se puede usar con SendMessage y no con PostMessage.
Para sobrecargar la recepción de un mensaje a una aplicación en Builder, e imagino que también en delphi, solo se puede usar PostMessage. Esto obliga a utilizar otro método de sobrecarga, quizas reescribir (como ya apunté al principio) TApplication:WndProc(Messages::TMessage &Message) o en su caso usar una clase derivada de TApplication.

Se me antoja que debería ser mas sencillo.

[Ñuño Martínez]

Una pregunta, ¿por qué no utilizar la comunicación por red, a través del loop-back (localhost ó 127.0.0.1)? Es el método que se suele utilizar en los sistemas POSIX (UNIX, Linux, Solaris, MacOS, ...), incluso para comunicar el programa con el gestor de ventanas, y en mi opinión es bastante mejor, más lento pero mucho más flexible y menos propenso a las corrupciones de memoria.

En fin, una simple opinión.