Gracias por sus sugerencias. Richard & overslacked, el enlace que proporcionó en los comentarios fue muy útil. Además, no tuve que permitir que el servicio interactuara con el escritorio para iniciar manualmente una bomba de mensajes con Application.Run. Aparentemente, solo necesita permitir que el servicio interactúe con el escritorio si desea que Windows inicie automáticamente un mensaje para usted.
para la edificación de todos, esto es lo que terminé haciendo iniciar manualmente una bomba mensaje para esta API tercera parte:
internal class MessageHandler : NativeWindow
{
public event EventHandler<MessageData> MessageReceived;
public MessageHandler()
{
CreateHandle(new CreateParams());
}
protected override void WndProc(ref Message msg)
{
// filter messages here for your purposes
EventHandler<MessageData> handler = MessageReceived;
if (handler != null) handler(ref msg);
base.WndProc(ref msg);
}
}
public class MessagePumpManager
{
private readonly Thread messagePump;
private AutoResetEvent messagePumpRunning = new AutoResetEvent(false);
public StartMessagePump()
{
// start message pump in its own thread
messagePump = new Thread(RunMessagePump) {Name = "ManualMessagePump"};
messagePump.Start();
messagePumpRunning.WaitOne();
}
// Message Pump Thread
private void RunMessagePump()
{
// Create control to handle windows messages
MessageHandler messageHandler = new MessageHandler();
// Initialize 3rd party dll
DLL.Init(messageHandler.Handle);
Console.WriteLine("Message Pump Thread Started");
messagePumpRunning.Set();
Application.Run();
}
}
que tuve que superar algunos obstáculos para conseguir que esto funcione. Una es que debe asegurarse de crear el Formulario en el mismo hilo que ejecuta Application.Run. También solo puede acceder a la propiedad Handle desde ese mismo hilo, así que me resultó más fácil simplemente inicializar el DLL en ese hilo también. Por lo que sé, está esperando ser inicializado desde un hilo GUI de todos modos.
Además, en mi implementación, la clase MessagePumpManager es una instancia de Singleton, de modo que solo se ejecuta una bomba de mensajes para todas las instancias de la clase de mi dispositivo. Asegúrate de inicializar realmente tu instancia singleton si comienzas el hilo en tu constructor. Si inicia el hilo desde un contexto estático (como la instancia de MessagePumpManager estática privada = new MessagePumpManager();) el tiempo de ejecución nunca cambiará de contexto al hilo recién creado, y se bloqueará mientras espera que se inicie el bombeo de mensajes.
Revise este hilo, puede ser útil: http://connect.microsoft.com/VisualStudio/feedback/details/241133/detecting-a-wm-timechange-event-in-a-net-windows-service – overslacked
@overslacked, de hecho lo hace. Dice exactamente cómo hacerlo. –
@overslacked Sé que esta es una pregunta antigua, por lo que no sorprende que el enlace de MS Connect ya no funcione. Pero como el contenido de ese enlace parece ser crucial para la discusión aquí, me preguntaba si hay un nuevo enlace disponible. Perdón por estar causando problemas! – Sabuncu