Carbonio ReceiveNextEvent e fili secondari

Question

Immaginate una libreria multi-piattaforma che deve creare le proprie finestre senza fare affidamento su WinForms / GTK # / WPF / MonoMac / etc (questo è OpenTK nel caso in cui qualcuno è interessato).

Qui è l'affare: il supporto di Windows e X11-grado Unix (o può funzionare con) cicli multipli di eventi, uno su ciascun thread. Questo significa (a) è possibile creare una finestra per ogni filo e farli lavorare in modo indipendente e (b) è possibile eseguire un WinForms (GTK #, WPF, ... o) finestra su un thread e aprire una finestra OpenTK su un diverso, senza interferenze.

Ora, al meglio della mia - certamente limitato - la conoscenza, Carbon non supporta questa. gli eventi del sistema operativo vengono consegnati solo al ciclo di eventi "principale" e tutte le discussioni secondari eseguiti su fumi (che è, ReceiveNextEvent restituisce sempre eventLoopTimedOutErr e non trova alcun evento). OpenTK si può lavorare con questa limitazione, nessun problema, ma questo pone un problema interessante per applicazioni che tentano di miscelare OpenTK un toolkit diverso (ad es MonoMac) per presentare una finestra di configurazione.

Opzioni Due:

• abbandonare l'idea folle e impedire che la miscelazione OpenTK con diversi toolkit (cattivo).
• scegliere un ascia e incidere carbonio alla sottomissione (buono).

Ecco stavi entrare: si può pensare a un modo per fare questo lavoro? Immaginate il seguente scenario:

1. Thread # 1 (principale) viene eseguito un codice di inizializzazione di nostra scelta e depone le uova un secondo thread (siamo in grado di modificare questo liberamente).
2. Thread # 1 (principale) si apre una finestra nativa e gestisce un ciclo RAEL (RunApplicationEventLoop). Si va fuori dal nostro diretto controllo, anche se possiamo ancora installare timer per eseguire il nostro codice, se necessario.
3. Thread # 2 (secondario) si apre una finestra OpenTK che prontamente si blocca (gli eventi vengono consegnati solo per infilare # 1 e ReceiveNextEvent ottiene nulla).

E 'possibile filtrare gli eventi da filo # 1 e consegnare loro di infilare 2 #, se necessario? Potrebbe CF in qualche modo aiutare qui? Guru di Mac OS X, si prega di aiuto!

(Programmazione lingua non importa, l'uso tutto quello che hanno familiarità con. Preferirei una soluzione a base di carbonio, ma di cacao avrebbe funzionato bene.)

Answer 1

Passando gli eventi da un thread ad un altro dovrebbe funzionare per quanto semplicemente ricevendo gli eventi consegnati. La parte adesiva è che un sacco di API UI-correlate non sono thread-safe, anche se il nucleo movimentazione Carbon Event è. Tutto ciò che comporta controlli aggiornamento e disegno dovrebbe probabilmente essere maneggiato di nuovo sul thread principale. Ciò richiederebbe un sacco di avanti e indietro, e non può valere la pena di provare a farlo funzionare.

Answer 2

Date un'occhiata al Application.AddMessageFilter e IMessageFilter interfaccia. potrebbe essere in grado di intercettare e inoltrare messaggi utilizzando logica personalizzata. Ho usato questa tecnica in passato (passato molto lontano), ma è stato tanto tempo fa che non mi ricordo tutti i caveat che vanno con esso. Non sono nemmeno certo che il filtro dei messaggi riceverà tutti i messaggi. .NET potrebbe non essere li filtrando fuori dietro le quinte prima di inviarli al IMessageFilter, ma vale la pena un colpo.