<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html>

<head>

  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">

</head>

<body bgcolor="#ffffff" text="#000000">

[ Old thread revived .... ]<br>

Since wxWindows was mentioned (nowadays called wxWidgets,

<a class="moz-txt-link-abbreviated" href="http://www.wxwidgets.org">www.wxwidgets.org</a>);<br>

Just want to point out the existence of wxHaskell,

<a class="moz-txt-link-freetext" href="http://wxhaskell.sourceforge.net">http://wxhaskell.sourceforge.net</a> , people thinking about GUIs for

Erlang might want to look into their experience.<br>

<br>

-- Thomas<br>

<br>

<br>

Vlad Dumitrescu XX (LN/EAB) wrote:

<blockquote

 cite="mid11498CB7D3FCB54897058DE63BE3897C4BE5D4@esealmw105.eemea.ericsson.se"

 type="cite">

  <pre wrap="">Hi,

  </pre>

  <blockquote type="cite">

    <pre wrap="">   << I think you could get a lot of mileage from just 

interfacing CreateWindowEx, SendMessage and PostMessage - but 

this might be incorrect << can a real windows expert comment 

on this>> >>

    </pre>

  </blockquote>

  <pre wrap=""><!---->

Just some quick 2 cents' thoughts: 

* With the above you can indeed go quite far, but it's only half the story - you must also be able to receive the messages on the Erlang side. This is more tedious, but doable (possibly at the expense of less flexibility in defining new widgets). 

Creating window procedures that just pass the message to the Erlang side is no good, because even if the no action or the default action should be taken, there is still a round-trip to Erlang. Imagine having one of those every time a key is pressed or the mouse is moved... So there will have to be a way to register interest in only some events, but then there has to exist a sensible default handling on the C side - see below.

* Also, not everything in a GUI is a window. For example, labels are handled by the parent window. The reason is that many windows are heavy on the system.

* Third, programming Windows applications like in the old days, is not fun. It's very easy to miss some important messages, and that's why there are frameworks around this basic API. They can also transparently handle widgets that aren't really windows. And some frameworks are also not Windows-only.

To sum it up, maybe it is better to not go all the way to the lowest level, but use some existing framework. wxWindows is being put to the test as we speak.

If you are going to say "but frameworks are heavy and there's a huge API to control all kinds of things" I am going to answer "such a framework must be built in any case! Using the bare-bones mechanisms will only work for simple applications" ;-) 

best regards,

Vlad

For more about Windows messaging, refer to <a class="moz-txt-link-freetext" href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/messagesandmessagequeuesreference/messagesandmessagequeuesfunctions/postmessage.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/messagesandmessagequeuesreference/messagesandmessagequeuesfunctions/postmessage.asp</a>

 (sorry about the long URL...)

  </pre>

</blockquote>

<br>

</body>

</html>