Talk:Message loop in Microsoft Windows

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
???	This article has not yet received a rating on the project's importance scale.

Microsoft Windows: Computing Mid‑importance

	This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows articles
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is supported by WikiProject Computing.

While this code has been antiquated by modern frameworks accompanying high-level languages [...]

I find this statement quite ambiguous. Is it the general use of event loops in Windows systems that has been antiquated, or the particular use of GetMessage(), TranslateMessage() and DispatchMessage(&msg)?

Either way, what is actually used by modern frameworks? --Abdull 12:42, 15 April 2007 (UTC)[reply]

I replaced the text with something a little better. As for what the frameworks use, it varies; the two examples illustrate two different approaches: one with a straightforward callback mechanism (VB), the other using a signal/slot mechanism to mediate the callbacks. Others such as MFC and Wx use message maps which can be seen as being somewhat inbetween, and there are yet more exotic mechanisms out there for connecting guis to code, though the toolkits using them tend to be equally esoteric as well. 206.173.243.159 (talk) 15:42, 24 June 2008 (UTC)[reply]