[.NET] WndProc messageloop in console app?

[MrBucket]

Als je een windows forms applicatie maakt, heb je altijd (impliciet) de beschikking over een windows message loop. Maar ik wil graag een messageloop hebben voor mijn console-applicatie. Heeft iemand hier enige ervaring mee, toevallig?

Voor zover ik kan bepalen lijkt de message loop aangemaakt te worden door Application.Run(). Maar Run verwacht ofwel een Form, ofwel een ApplicationContext met daarin een Form. En aangezien het een console-application betreft heb ik geen Form tot mijn beschikking (en ik wil er liefst ook geen aanmaken, alleen om een messageloop te krijgen).

De derde Application.Run() heeft helemaal geen argumenten; deze is helemaal apart, want waar stuurt hij de binnenkomende messages dan heen? Is er een manier om deze uit te lezen?

--
Toelichting op mijn misschien wat aparte vraag: Ik ben bezig met een commandline tooltje wat nogal veel met sockets doet. Om thread- en concurrency-problemen zoveel mogelijk te voorkomen wil ik dat alles in dezelfde thread loopt d.m.v. een message loop. Ik wil dan alle operaties asynchroon uitvoeren, en voor elke statusverandering (data ontvangen, verbinding verbroken, etc.) een message definieren, die ik in mijn message loop kan afhandelen.

[SKiLLa]

Geen direct ervaringen met WM in C#, maar kijk eens op deze MSDN url. Je krijgt uiteraard wel unmanaged code op deze manier.

[Verwijderd]

Het is totaal niet de bedoeling om voor dit soort dingen de message queue te gebruiken, je kan hiermee een heel systeem op z'n gat laten gaan/ of vertragen.

Er zijn genoeg andere dingen die je kan gebruiken om berichten te versturen (DDE/RPC ETC ETC) / threading te gebruiken -> ik raad je echt sterk af om het op deze manier te doen.

[MLM]

je kan een eigen message-systeem bouwen (dat kan je simpel houden), of gewoon met behulp van een/meerdere loops over select() je systeem draaien...

[MrBucket]

@Skilla: dat was inderdaad mijn volgende probleem: hoe krijg ik mijn messages gequeued in de message-loop... Ik zal nog eens met reflector door de System.Windows.Forms namespace lopen, maar als ik daar niks bruikbaars (lees: niet internal) tegenkom, dan lijkt me jouw PostThreadMessage een goed startpunt.

@MLM: Ik zou inderdaad mijn eigen message-systeem in elkaar kunnen draaien, maar dan zit ik weer met het probleem dat het niet direct bruikbaar is in een windows form applicatie. En waarom dan niet gebruik maken van iets wat al voor handen is? Ik meen me trouwens te herinneren dat windows intern zelf ook gebruik maakt van de message loop om asynchrone calls uit te zetten.

@rvanleeuw: opmerkelijke post. Heb je zelf ervaring met het op z'n gat laten gaan van windows door de message-queue? Voor zover ik weet zijn de verschillende PostMessage- en GetMessage-calls allemaal atomic, en aan de hoeveelheid messages die er in geplaatst worden kan het ook niet liggen (heb je wel eens met Spy++ gekeken hoeveel messages er sowiezo al door je messageloop heenvliegen?).

[MTWZZ]

Wat je IMHO zou moeten doen is het volgende:
- Listening Socket maken
- Socket.Select() in een while() loop gebruiken om connections af te vangen
- Socket Accepten
- Thread starten in een ThreadPool

Op deze manier kun je heel snel een connection afvangen, doorgeven aan een aparte handler en die het werk laten doen terwijl de Select() loop verder kan om volgende connections af te vangen.

Als je een voorbeeldje nodig hebt moet je het maar ff laten weten.

[__fred__]

Kijk ook eens naar Backgroundworker in .NET 2.0

[MrBucket]

Ik maak gebruik van de asynchrone socket-calls (BeginReceive, EndReceive, BeginAccept, etc.), en deze starten zelf al een worker-thread. Het vervelende hieraan is alleen dat de callback methoden (waarin je EndRecieve moet aanroepen) niet in de hoofd-thread worden uitgevoerd, maar in de worker thread. En dat wil ik niet.

Ik zoek dus eigenlijk een manier om het resultaat van deze calls ook in dezelfde thread af te handelen als de thread waarin ik BeginReceive aanroep.

Vandaar mijn idee om hiervoor de windows message queue te willen gebruiken.

[MLM]

Hmm... ik denk dat select() de beste optie is.... in semi-code (geen .NET, maar .NET heeft vast soortgelijke calls)

code:

socket pool[1000];
int number = 0;

int main()
{
    socket listener;
    //initialiseer socket
    listen(listener);
    while(true)
    {
        poll(listener);
        if(connection_pending && number < 1000)
        {
            pool[number] = accept(listener);
            number++;
        }
        select(pool);
        foreach(socket s in selected_pool)
        {
            data = receive(s);
            //verwerk data
        }
    }
}

Aldus, alles in 1 thread, geen messageloop

[ Voor 6% gewijzigd door MLM op 28-01-2007 23:27 ]

[MTWZZ]

MrBucket schreef op zondag 28 januari 2007 @ 14:02:
Ik zoek dus eigenlijk een manier om het resultaat van deze calls ook in dezelfde thread af te handelen als de thread waarin ik BeginReceive aanroep.

Als je worker threadss gebruikt hoef je geen asynchrone functies te gebruiken, je thread is dan al asynchroon tov je main thread