wxhaskell-users

[wxhaskell-users] Stop do not stop; not multi-threaded?

[<jmv...@gm...>]

Hi

=20

I=92m running a program with a graphical interface in wxHaskell.=20

My program have one button that starts a sometimes very long computation
that even could get cyclic in some cases. I created a Stop button that =
when
pressed changes the State of the application (type State =3D Var =
MyRecordType
from =
http://wxhaskell.sourceforge.net/doc/Graphics.UI.WX.Types.html#t%3AVar
). Then my very long computation, before calling the recursive call, =
checks
if the State is saying to continue or stop.

=20

In theory this seems the solution but when I tested it I find out that =
it
doesn=92t. The very long computation gets the attention of the processor =
and
blocks the graphical interface; clicking the Stop button don=92t fire =
the
actions.

=20

I=92m not sure but is this running sequencially? Which ways have I to =
overcome
this block?

=20

Best

Miguel=20

=20

=20

Re: [wxhaskell-users] Stop do not stop; not multi-threaded?

[Eric Y. K. <eri...@gm...>]

Hi,

On Mon, Feb 05, 2007 at 16:17:41 -0000, Jos=E9 Miguel Vila=E7a wrote:
> In theory this seems the solution but when I tested it I find out that it
> doesn=92t. The very long computation gets the attention of the processor =
and
> blocks the graphical interface; clicking the Stop button don=92t fire the
> actions.

Does calling wxcAppSafeYield in your long computation (look in the index
of the API) help?  I don't actually know the answer, just making some
guesses.  You might want to look into what Dazzle/XTC do, otherwise.

And if it does help, maybe you could write something up on the Haskell
wiki so that other programmers won't have to suffer!

Best,

--=20
Eric Kow                     http://www.loria.fr/~kow
PGP Key ID: 08AC04F9         Merci de corriger mon fran=E7ais.

Re: [wxhaskell-users] Stop do not stop; not multi-threaded?

[Arthur v. L. <art...@cs...>]

On 18-feb-2007, at 21:58, Eric Y. Kow wrote:

> Hi,
>
> On Mon, Feb 05, 2007 at 16:17:41 -0000, Jos=E9 Miguel Vila=E7a wrote:
>> In theory this seems the solution but when I tested it I find out =20
>> that it
>> doesn=92t. The very long computation gets the attention of the =20
>> processor and
>> blocks the graphical interface; clicking the Stop button don=92t =20
>> fire the
>> actions.
>
> Does calling wxcAppSafeYield in your long computation (look in the =20
> index
> of the API) help?  I don't actually know the answer, just making some
> guesses.  You might want to look into what Dazzle/XTC do, otherwise.

Just as a heads-up: Dazzle doesn't solve this problem at all. Long =20
computations
are split in parts, the (lazy) evaluation of which is driven from the =20=

UI, but any truly
long evaluation will still block the UI.

Doei, Arthur.

--=20

   /\    / |       art...@cs...       | Work like you don't need =20=

the money
/__\  /  | A friend is someone with whom | Love like you have never =20
been hurt
/    \/__ | you can dare to be yourself   | Dance like there's nobody =20=

watching

Re: [wxhaskell-users] Stop do not stop; not multi-threaded?

[<jmv...@di...>]

Hi,=20

After losts of surfing in Google and in wxHaskell Haddock documentation =
I
find out this possible solution that works fine for my case=20

wxcAppYield
(http://wxhaskell.sourceforge.net/doc/Graphics.UI.WXCore.WxcClassesMZ.htm=
l#v
%3AwxcAppYield )
or its variant=20
wxcAppSafeYield
(http://wxhaskell.sourceforge.net/doc/Graphics.UI.WXCore.WxcClassesMZ.htm=
l#v
%3AwxcAppSafeYield )

It is simple as calling this function before testing if a certain button =
had
been pressed and its call-back had update the state of the application
accordingly.

Thanks for your help.

Best
Miguel Vila=E7a=20

-----Mensagem original-----
De: Eric Y. Kow [mailto:eri...@gm...]=20
Enviada: domingo, 18 de Fevereiro de 2007 20:58
Para: Jos=E9 Miguel Vila=E7a
Cc: wxHaskell mailing list
Assunto: Re: [wxhaskell-users] Stop do not stop; not multi-threaded?

Hi,

On Mon, Feb 05, 2007 at 16:17:41 -0000, Jos=E9 Miguel Vila=E7a wrote:
> In theory this seems the solution but when I tested it I find out that =
it
> doesn=92t. The very long computation gets the attention of the =
processor and
> blocks the graphical interface; clicking the Stop button don=92t fire =
the
> actions.

Does calling wxcAppSafeYield in your long computation (look in the index
of the API) help?  I don't actually know the answer, just making some
guesses.  You might want to look into what Dazzle/XTC do, otherwise.

And if it does help, maybe you could write something up on the Haskell
wiki so that other programmers won't have to suffer!

Best,

--=20
Eric Kow                     http://www.loria.fr/~kow
PGP Key ID: 08AC04F9         Merci de corriger mon fran=E7ais.