wxhaskell-users

[wxhaskell-users] event objects

[Robert D. <rob...@fa...>]

As a resent poster to this thread, I'm interested in multithreaded programs 
with wxHaskell.  The 'evtHandlerAddPendingEvent' function mentioned in that 
thread would solve my issue, except that I can't figure out how to create 
event objects (those with type Graphics.UI.WXCore.WxcClassTypes.Event).  
There don't appear to be constructors for these object types.

For example, KeyEvent 
(http://wxhaskell.sourceforge.net/doc/Graphics.UI.WXCore.WxcClassesAL.html#99) 
doesn't have the expected 'keyEventCreate' funciton and PaintEvent, which 
only has a constructor, doesn't appear in the function listings at all. 
What's the deal?

Rob Dockins

Re: [wxhaskell-users] event objects

[Robert D. <rob...@fa...>]

On Feb 11, 2006, at 7:22 PM, Robert Dockins wrote:

> As a resent poster to this thread, I'm interested in multithreaded  
> programs
> with wxHaskell.  The 'evtHandlerAddPendingEvent' function mentioned  
> in that
> thread would solve my issue, except that I can't figure out how to  
> create
> event objects (those with type  
> Graphics.UI.WXCore.WxcClassTypes.Event).
> There don't appear to be constructors for these object types.
>
> For example, KeyEvent
> (http://wxhaskell.sourceforge.net/doc/ 
> Graphics.UI.WXCore.WxcClassesAL.html#99)
> doesn't have the expected 'keyEventCreate' funciton and PaintEvent,  
> which
> only has a constructor, doesn't appear in the function listings at  
> all.
> What's the deal?
>
> Rob Dockins


Ping.  Is anyone reading this list?

Rob Dockins

Re: [wxhaskell-users] event objects

[Anatoly Z. <ana...@gm...>]

On 2/20/06, Robert Dockins <rob...@fa...> wrote:
>
> > There don't appear to be constructors for these object types.
> >
> > For example, KeyEvent
> > (http://wxhaskell.sourceforge.net/doc/
> > Graphics.UI.WXCore.WxcClassesAL.html#99)
> > doesn't have the expected 'keyEventCreate' funciton and PaintEvent,
> > which
> > only has a constructor, doesn't appear in the function listings at
> > all.
>

Hi!

It's not very difficult to add them though the entire Haskell part of
wxHaskell should be rebuilt then. But if you need some custom events
you can use the following hack (trick, technique...):

import Control.Concurrent.Chan
import Graphics.UI.WX
import Graphics.UI.WXCore

makeEvent :: EvtHandler a -> IO (IO (), IO () -> IO ())
makeEvent target =3D
  do
    id <- idCreate
    evt <- commandEventCreate wxEVT_COMMAND_MENU_SELECTED id
    let sender =3D evtHandlerAddPendingEvent target evt
        binder =3D evtHandlerOnMenuCommand target id
    return (sender, binder)

gui =3D do
  f <- frame [text :=3D "Some frame"]

  let newFrameEvent =3D makeEvent f
  (oneThreadReport, reactToOneThread) <- newFrameEvent
  (anotherOneReport, reactToAnotherThread) <- newFrameEvent

  reactToOneThread (putStrLn "OneThread sent event")

  dataChan <- newChan
  reactToAnotherThread $ do
    d <- readChan dataChan
    putStrLn ("Data from AnotherThread: " ++ show d)

  createOneThread oneThreadReport
  createAnotherOne anotherOneReport dataChan

Performing those report actions threads can send events.

My program worked properly only with threaded rts, possibly because
addPendingEvent performs mutex locking. I am not sure about the exact
reason, 'cause there was also some network I/O.

--
Best regards,
Tolik

Re: [wxhaskell-users] event objects

[Robert D. <rob...@fa...>]

On Feb 23, 2006, at 6:33 AM, Anatoly Zaretsky wrote:

> On 2/20/06, Robert Dockins <rob...@fa...> wrote:
>>
>>> There don't appear to be constructors for these object types.
>>>
>>> For example, KeyEvent
>>> (http://wxhaskell.sourceforge.net/doc/
>>> Graphics.UI.WXCore.WxcClassesAL.html#99)
>>> doesn't have the expected 'keyEventCreate' funciton and PaintEvent,
>>> which
>>> only has a constructor, doesn't appear in the function listings at
>>> all.
>>
>
> Hi!
>
> It's not very difficult to add them though the entire Haskell part of
> wxHaskell should be rebuilt then.

How would one go about adding them?  I'm not familiar with the how  
WxEiffel and the WxHaskell build system works.  Is there a particular  
reason they aren't exposed already?

> But if you need some custom events
> you can use the following hack (trick, technique...):

I'm not sure I fully understand, so let me paraphrase and see if I've  
got this right:

'makeEvent' takes an object which can handle events and returns a  
pair where
   -- the first element triggers an event by via the menu event  
handler on the passed in object
   -- the second element lets you set the event handler

If you want to pass additional data beyond the simple occurance of  
the event, you need external concurrency primitives.


> import Control.Concurrent.Chan
> import Graphics.UI.WX
> import Graphics.UI.WXCore
>
> makeEvent :: EvtHandler a -> IO (IO (), IO () -> IO ())
> makeEvent target =
>   do
>     id <- idCreate
>     evt <- commandEventCreate wxEVT_COMMAND_MENU_SELECTED id
>     let sender = evtHandlerAddPendingEvent target evt
>         binder = evtHandlerOnMenuCommand target id
>     return (sender, binder)
>
> gui = do
>   f <- frame [text := "Some frame"]
>
>   let newFrameEvent = makeEvent f
>   (oneThreadReport, reactToOneThread) <- newFrameEvent
>   (anotherOneReport, reactToAnotherThread) <- newFrameEvent
>
>   reactToOneThread (putStrLn "OneThread sent event")
>
>   dataChan <- newChan
>   reactToAnotherThread $ do
>     d <- readChan dataChan
>     putStrLn ("Data from AnotherThread: " ++ show d)
>
>   createOneThread oneThreadReport
>   createAnotherOne anotherOneReport dataChan
>
> Performing those report actions threads can send events.
>
> My program worked properly only with threaded rts, possibly because
> addPendingEvent performs mutex locking. I am not sure about the exact
> reason, 'cause there was also some network I/O.

Ahh.  That's unfortunate.  I'll have to think on this.


Thank you for your reply!


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG

Re: [wxhaskell-users] event objects

[Anatoly Z. <ana...@gm...>]

On 2/23/06, Robert Dockins <rob...@fa...> wrote:
>
> How would one go about adding them?  I'm not familiar with the how
> WxEiffel and the WxHaskell build system works.  Is there a particular
> reason they aren't exposed already?

WxHaskell uses wxc part of wxEiffel -- basically, C wrappers around
C++ classes methods. And as far as I know wxEiffel doesn't evolve
anymore, so there's noone to add wrappers for missing classes.

> I'm not sure I fully understand, so let me paraphrase and see if I've
> got this right:
>
> 'makeEvent' takes an object which can handle events and returns a
> pair where
>    -- the first element triggers an event by via the menu event
> handler on the passed in object
>    -- the second element lets you set the event handler

Exactly. I am sorry for omitting the description. Just to note: every
makeEvent generates distinct event object.

> If you want to pass additional data beyond the simple occurance of
> the event, you need external concurrency primitives.

Yes, but I personaly think that passing haskell data between haskell
threads through C-land is less natural (and heavier) than using native
primitives.

Re: [wxhaskell-users] event objects

[Robert D. <rob...@fa...>]

On Feb 23, 2006, at 1:03 PM, Anatoly Zaretsky wrote:

> On 2/23/06, Robert Dockins <rob...@fa...> wrote:
>>
>> How would one go about adding them?  I'm not familiar with the how
>> WxEiffel and the WxHaskell build system works.  Is there a particular
>> reason they aren't exposed already?
>
> WxHaskell uses wxc part of wxEiffel -- basically, C wrappers around
> C++ classes methods. And as far as I know wxEiffel doesn't evolve
> anymore, so there's noone to add wrappers for missing classes.


OK.  So its not likely to happen soon unless I decide to do it...


>> I'm not sure I fully understand, so let me paraphrase and see if I've
>> got this right:
>>
>> 'makeEvent' takes an object which can handle events and returns a
>> pair where
>>    -- the first element triggers an event by via the menu event
>> handler on the passed in object
>>    -- the second element lets you set the event handler
>
> Exactly. I am sorry for omitting the description. Just to note: every
> makeEvent generates distinct event object.
>
>> If you want to pass additional data beyond the simple occurance of
>> the event, you need external concurrency primitives.
>
> Yes, but I personaly think that passing haskell data between haskell
> threads through C-land is less natural (and heavier) than using native
> primitives.

Yeah, it just brings up thorny questions about synchronizing what are  
essentially two parallel message queues.  I know that a Chan will  
guarantee inorder delivery without dropped messages, but I don't know  
what the properties of the wx event queues are.  Is it possible that  
they could become out of sync?  I don't want to deadlock because wx  
dropped an event, and I'll have to be pretty careful if events can be  
delivered out-of-order.

Thanks again.


Rob Dockins

Speak softly and drive a Sherman tank.
Laugh hard; it's a long way to the bank.
           -- TMBG