wxhaskell-users — General mailing list for wxhaskell users

[wxhaskell-users] Problem with registering WxHaskell

[Rustam A. <ru...@gm...>]

Hi. i have downloaded
wxhaskell-bin-msw2.4.2-ghc6.4-0.9.4-1.zip<http://prdownloads.sourceforge.net/wxhaskell/wxhaskell-bin-msw2.4.2-ghc6.4-0.9.4-1.zip?download>
There wrote ->
"Unzip the release somewhere and click on the newly created
wxhaskell-0.9.4\bin\wxhaskell-register.bat program to
register the wxHaskell package. To uninstall,
you can click on wxhaskell-0.9.4\bin\wxhaskell-unregister.bat
and than remove the wxhaskell-0.9.4 directory."

I did like this but a got this error message ->
ghc-pkg: dependency lang doesn't exist (use --force to override)
Reading package info from "C:\\haskell\\wxhaskell 2.4.2\\bin\\wx.pkg" ...
done.
ghc-pkg: dependency wxcore-0.9.4 doesn't exist (use --force to override)
error:
  Unable to register the package using "ghc-pkg".
  Maybe you have an incompatible version of ghc installed?

I have installed Visual Haskell 0.2, and add  "visual haskell\bin" to path
enviroment.

may be i something missed...

Re: [wxhaskell-users] Playing sound

[shelarcy <she...@gm...>]

Hi Wouter,

Did you build wxWidgets with configuring --enable-sound
build option?

If you didn't use it, you can't use play and sound functions.

http://wxhaskell.sourceforge.net/building.html

Best Regards,

On Thu, 14 Dec 2006 23:03:52 +0900, Wouter Swierstra <ws...@Cs...> wrote:
> I've been trying to play a .wav file from wxHaskell using:
>
> play (sound "bla.wav")
>
> Unfortunately, my program crashes as soon as this is invoked. I get
> the following error message:
>
> user error (wxHaskell: NULL object: wavePlay)
>
> Is there some additional software that I need to install? I'd
> appreciate any pointers.

-- 
shelarcy <shelarcy    capella.freemail.ne.jp>
http://page.freett.com/shelarcy/

Re: [wxhaskell-users] Strange polygon behaviour

[Jeremy O'D. <jer...@gm...>]

Hi Chris,

On 15/12/06, Chris Mears <ch...@cm...> wrote:
> Chris Mears <ch...@cm...> writes:
>
> > I am using the wxHaskell library built from the Darcs repository at
> > haskell.org, with wxWidgets "gtk-2.6.3" and GHC 6.6.  I am trying to
> > draw a polygon with the "polygon" function, but it isn't doing what I
> > expected.
[...]
> I think I have tracked down the source of the problem.  It works
> correctly on my 32-bit computer, but misbehaves on the 64-bit one.
> Summary: On my 64-bit machine, Haskell Int is 64-bit, C int is 32-bit.

This makes perfect sense. I think you may well be the first person to
have tried wxHaskell on a 64 bit machine, so perhaps no surprise that
you are coming up with these issues.

> The polygon function takes a list of Point, where a Point is a pair
> (basically) of Ints.  On 64-bit GHC, an Int is 64-bits long, so each
> component of a Point is 64-bits.  The Point components are marshalled
> into an array and passed to C code (wxc/src/ewxw/eljdc.c).  The C code
> treats the array as an array of (C) int.  However, on the 64-bit machine
> a C int is 32-bits.
>
> So, when I passed the 64-bit points (50, 50), (100, 100), etc. as 32-bit
> points they were interpreted as (50, 50), (0, 0), (100, 100), etc.,
> which explains the strange drawing I saw.  Changing the cast in the C
> code from (int*) to (long*) corrects the problem, but is not a general
> fix.  Sadly, I don't know enough about FFI and marshalling to suggest
> the proper correction.

Unfortunately, I think your basic solution is the way forward, but
probably mapped onto a suitable set of macros to hide the platform
difference. We could probably do this by working through all of the
wxC implementation files and replacing all int with types of known
size and appropriate casts. Very tedious, but not difficult.

I think we, as the development team, need to put this on our TODO
list, and I am happy to do once I have finished cabalization (so it
may take a while). I'll need help to test it though - I have four
machines available to me, but none has a 64 bit CPU :-(

Regards
Jeremy

Re: [wxhaskell-users] Strange polygon behaviour

[Chris M. <ch...@cm...>]

Chris Mears <ch...@cm...> writes:

> I am using the wxHaskell library built from the Darcs repository at
> haskell.org, with wxWidgets "gtk-2.6.3" and GHC 6.6.  I am trying to
> draw a polygon with the "polygon" function, but it isn't doing what I
> expected.
[...]
> From some experimentation, it seems that the first line is drawn
> correctly, but the subsequent ones are drawn from the origin instead of
> from the previous point, and the last point is ignored altogether.

I think I have tracked down the source of the problem.  It works
correctly on my 32-bit computer, but misbehaves on the 64-bit one.
Summary: On my 64-bit machine, Haskell Int is 64-bit, C int is 32-bit.

The polygon function takes a list of Point, where a Point is a pair
(basically) of Ints.  On 64-bit GHC, an Int is 64-bits long, so each
component of a Point is 64-bits.  The Point components are marshalled
into an array and passed to C code (wxc/src/ewxw/eljdc.c).  The C code
treats the array as an array of (C) int.  However, on the 64-bit machine
a C int is 32-bits.

So, when I passed the 64-bit points (50, 50), (100, 100), etc. as 32-bit
points they were interpreted as (50, 50), (0, 0), (100, 100), etc.,
which explains the strange drawing I saw.  Changing the cast in the C
code from (int*) to (long*) corrects the problem, but is not a general
fix.  Sadly, I don't know enough about FFI and marshalling to suggest
the proper correction.

[wxhaskell-users] Strange polygon behaviour

[Chris M. <ch...@cm...>]

Hi,

I am using the wxHaskell library built from the Darcs repository at
haskell.org, with wxWidgets "gtk-2.6.3" and GHC 6.6.  I am trying to
draw a polygon with the "polygon" function, but it isn't doing what I
expected.  I wrote the following program:

> import Graphics.UI.WX
>
> main = start go
>
> go = frame [on paint := p]
>
> p dc view = polygon dc [(pt 50 50), (pt 100 50), (pt 75 100)] []

and I expected to get a an isosceles triangle like this (ASCII art):

  -------
   \   /
    \ /
     v

but instead, I get this:

http://www.cmears.id.au/triangle.png

>From some experimentation, it seems that the first line is drawn
correctly, but the subsequent ones are drawn from the origin instead of
from the previous point, and the last point is ignored altogether.

Also, I ran the "Camels" sample program in samples/contrib/ and it looks
like this:

http://www.cmears.id.au/camels.png

Can anyone help me understand what is happening?

Thanks,
Chris

[wxhaskell-users] Playing sound

[Wouter S. <ws...@Cs...>]

Dear all,

I've been trying to play a .wav file from wxHaskell using:

play (sound "bla.wav")

Unfortunately, my program crashes as soon as this is invoked. I get  
the following error message:

user error (wxHaskell: NULL object: wavePlay)

Is there some additional software that I need to install? I'd  
appreciate any pointers.

Thanks very much,

   Wouter

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: [wxhaskell-users] process crashes on second 'start'

[Conal E. <co...@co...>]

I did get wxHaskell-0.10.1 and wxWidgets-2.4.2 working together.  Multiple
'start's (hence ghci-friendly), and no string truncation, so I'm content.
And I prefer the more vertically compact visual style of sliders in 2.4.2over
2.6.3.  I was fooled at first in recompiling wxWidgets with
--enable-unicode.  I had to completely empty out my "mybuild" directory, not
just "make clean" to fix string truncation (unicode glitch).   - Conal

On 12/8/06, Jeremy O'Donoghue <jer...@gm...> wrote:
>
> Hi Conal,
>
> On 07/12/06, Conal Elliott <co...@co...> wrote:
> > Hi Jeremy,
> >
> > Thanks for the detailed pointers about wxWidgets, GUIs, and
> multi-threading.
> >  My use is actually very simple.  The only reason I wanted multiple
> > (sequential, not concurrent) invocations of 'start' is for convenience
> of
> > use in ghci.
> >
> > I recently switched from wxWidgets 2.4.2 to 2.6.3, and I remember that
> this
> > problem was worked around in 2.4.2 for use with ghci.  Is there really
> no
> > way to fix the situation with 2.6.3?
>
> This is what Daan said (in passing, in the context of another message
> about the new wxHaskell maintenance team):
>
> "Finally, I am not convinced that we should always use the latest
> wxWidgets version: In particular, the 2.4.2 version is the only one
> that lets you start and restart wxhaskell apps under GHCI under
> window. The newer versions use static c++ classes and the destructors
> are not called once the dll is loaded under GHCI (fixing this requires
> fixing wxWidgets or letting GHCI reload DLL's too)."
>
> > Do wxWidgets-2.4.2, wxHaskell-0.10.1 and ghc-6.6 get along together,
> > including unicode issues?
>
> I believe so (translation: I managed to get it to work on my PC under
> WinXP). I understand that Unicode support in 2.4.2 is not so thorough
> as for 2.6.3, although my Unicode requirements are minimal, so I
> wouldn't expect to have seen any significant issues. Eric is working
> on ways to test Unicode support more thoroughly. He's already
> published one darcs patch.
>
> In a couple of days (i.e. when it works...) I will be recompiling my
> wx 2.4.2 based installation to test the new NMAKE makefile for wxc
> (intention is to avoid the messy editing of Visual Studio project
> files and create something easier to maintain). I'll let you know how
> that goes.
>
> > Does anyone use ghci with wxHaskell-0.10.1 and ghc-6.6?
>
> Yes, although it's not my primary platform by a long way.
>
> Jeremy
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

Re: [wxhaskell-users] wxHaskell + ghc 6.6 + MacOS X (Intel)

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

On Sun, Dec 10, 2006 at 05:06:22 +0100, Thomas Schilling wrote:
> No, I didn't, because "make help" didn't show that option and there
> was no INSTALL or README file.  I probably missed it somewhere in the
> documentation.

Alas, it was not in the documentation, but when you run make install,
it does print out a banner asking you to run make wx and make
wx-install.

This build process is rather temporary, so it's probably not worth
documenting it yet.  We're aiming to have the Haskell bits Cabalised,
and when we have _that_, we should definitely improve the documentation.
Adding standard INSTALL and README files would be a very good idea
though, and I would welcome any such patches :-)

Best,

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

Re: [wxhaskell-users] Undefined reference to wxGLCanvas::*

[Bas v. D. <bas...@ho...>]

On Sunday 10 December 2006 02:07, Eric Y. Kow wrote:
> Does it help if you throw in something like -lwx_gtk2u_gl-2.6 whilst
> compiling the samples?

Yes this helps. Thanks very much! Now I can finally start playing with 
wxHaskell.

Bas.

Re: [wxhaskell-users] wxHaskell + ghc 6.6 + MacOS X (Intel)

[Thomas S. <nom...@go...>]

No, I didn't, because "make help" didn't show that option and there
was no INSTALL or README file.  I probably missed it somewhere in the
documentation.

Now it works. Thanks!

On 12/10/06, Eric Y. Kow <eri...@gm...> wrote:
> On Sat, Dec 09, 2006 at 18:41:48 +0100, Thomas Schilling wrote:
> > If I remove "-package wx" it doesn't find the package Graphics.UI.WX,
> > but I think that is expected.  I installed wxHaskell today from the
> > darcs-repo using the standard ./configure && make && sudo make
> > install (worked fine).
>
> Did you also do make wx and make wx-install?
>
> The build process is in two stages, the initial make and make install
> gives you wxcore and the next stage gives you wx.
>
> --
> Eric Kow                     http://www.loria.fr/~kow
> PGP Key ID: 08AC04F9         Merci de corriger mon fran=E7ais.
>
>
>


--=20
"Remember! Everytime you say 'Web 2.0' God kills a startup!" -
userfriendly.org, Jul 31, 2006

Re: [wxhaskell-users] Undefined reference to wxGLCanvas::*

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

On Thu, Nov 30, 2006 at 14:45:03 +0100, Bas van Dijk wrote:
> When making the wx samples I got the following error:
>=20
> bas@bassbox ~/development/haskell/wxhaskell/samples/wx $ make
> ghc -package wx -o BouncingBalls BouncingBalls.hs
> /usr/lib/libwxc-gtk2.6.2-0.10.1.so: undefined reference to=20
> `wxGLCanvas::SwapBuffers()'

Does it help if you throw in something like -lwx_gtk2u_gl-2.6 whilst
compiling the samples?

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

[wxhaskell-users] patches accepted 2006-12-09

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

Note: it's probably a good idea to keep your short patch names under 72
characters. You can use the long patch comments for more details.

Accepted since the last cycle (3)
---------------------------------
Wed Nov 29 05:22:30 CET 2006  Eric Kow <eri...@lo...>
  * Add an eyeball test for Unicode strings.

Thu Dec  7 01:43:27 CET 2006  she...@ca...
  * Correct previous patch for db.cpp

Thu Dec  7 01:59:46 CET 2006  she...@ca...
  * Added #ifndef compilation flag around <inttypes.h> to avoid building
problem under Visual C++ (VC). (VC doesn't have <inttypes.h>.)

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

Re: [wxhaskell-users] wxHaskell + ghc 6.6 + MacOS X (Intel)

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

On Sat, Dec 09, 2006 at 18:41:48 +0100, Thomas Schilling wrote:
> If I remove "-package wx" it doesn't find the package Graphics.UI.WX, =20
> but I think that is expected.  I installed wxHaskell today from the =20
> darcs-repo using the standard ./configure && make && sudo make =20
> install (worked fine).

Did you also do make wx and make wx-install?

The build process is in two stages, the initial make and make install
gives you wxcore and the next stage gives you wx.

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

Re: [wxhaskell-users] strings truncated to one character in wxhaskell-0.10.1 under ghc-6.6

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

Thanks for the patches, Shelarcy.  They are going in.

> Attached also includes another patch that fix building error if using
> wxWdgets with -enable-odbc or #define wxUSE_ODBC 1 in setup.h (under VC).
> It is lacked part of my previous patch.

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

Re: [wxhaskell-users] darcs patch: Add an eyeball test for Unicode strings.

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

> Wed Nov 29 05:22:30 CET 2006  Eric Kow <eri...@lo...>
>   * Add an eyeball test for Unicode strings.

I'm pushing this in.  It'd be great if you could play with it a bit and
suggest improvements.  I hope to eventually add other tests:
- menus
- dialog boxes
- file open/save dialogues (filenames worry me especially since I
  don't really know much about how encodings and filesystems go)

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

[wxhaskell-users] wxHaskell + ghc 6.6 + MacOS X (Intel)

[Thomas S. <nom...@go...>]

Hi,

I managed to successfully build wxHaskell using the darcs  
repository.  Unfortunately, it still doesn't work as expected.  For  
the example from <http://wxhaskell.sourceforge.net/quickstart.html>  
it fails with:

$ ghc -package wx -v --make Main.hs -o hello
Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by  
GHC version 6.6
Using package config file: /usr/local/lib/ghc-6.6/package.conf
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting:
ghc-6.6: unknown package: wx

If I remove "-package wx" it doesn't find the package Graphics.UI.WX,  
but I think that is expected.  I installed wxHaskell today from the  
darcs-repo using the standard ./configure && make && sudo make  
install (worked fine).

Any ideas?

- Thomas

Re: [wxhaskell-users] Use of Ptr type for calling treeCtrlHitTest

[Takano A. <al...@hy...>]

Hi Bernd,

On Fri, 08 Dec 2006 14:20:15 +0100
Bernd Holzm=FCller <ber...@ic...> wrote:

> I would like to use the function
>=20
> treeCtrlHitTest :: TreeCtrl a -> Point -> Ptr CInt -> IO TreeItem
>=20
> but I cannot find out from the wxHaskell documentation how to create /=20
> use the Ptr argument, which stands for an "out" parameter.

You can create a pointer using functions from Foreign.Marshal.Alloc,
and read/write it using functions from Foreign.Marshal.Storable.

For example, using alloca and peek, you can write a simple wrapper around
treeCtrlHitTest, which returns a pair instead of requiring a Ptr.

myHitTest :: TreeCtrl a -> Point -> IO (TreeItem, CInt)
myHitTest w point =3D alloca $ \ptr -> do
  r <- treeCtrlHitTest w point ptr
  flags <- peek ptr
  return (r, flags)

Regards,
Takano Akio

[wxhaskell-users] Use of Ptr type for calling treeCtrlHitTest

[<ber...@ic...>]

I would like to use the function

treeCtrlHitTest :: TreeCtrl a -> Point -> Ptr CInt -> IO TreeItem

but I cannot find out from the wxHaskell documentation how to create / 
use the Ptr argument, which stands for an "out" parameter.
Can someone tell me how to create a value of type Ptr CInt to apply it 
to the treeCtrlHitTest function?

Thanks,
Bernd

Re: [wxhaskell-users] strings truncated to one character in wxhaskell-0.10.1 under ghc-6.6

[shelarcy <she...@gm...>]

On Thu, 07 Dec 2006 11:55:29 +0900, shelarcy <she...@gm...> wrote:
> Because current VC project for wxWidgets-2.6.3 doesn't works well my
> environment, and I was busy. Jeremy changed VC project from
> "..\..\wxWidgets-2.6.3\lib\vc_lib\mswu" to "..\..\wxWidgets-2.6.3\lib\mswu"
> in "Update VC++ project file to reflect updated DLL version supporting
> wxWidgets 2.6.3" patch. It breaks building my environment but I don't find
> where causes problem, soonly.

Oops, I am wrong.

wxWidgets-2.6.x's wx_adv.dsp generate setup.h in lib\vc_lib
instead of just lib. So this is not my environments problem.

wx_adv.dsp:890:# Begin Custom Build - Creating ..\..\lib\vc_lib\mswu\wx\setup.h
wx_adv.dsp:893:"..\..\lib\vc_lib\mswu\wx\setup.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
wx_adv.dsp:894:	copy "$(InputPath)" ..\..\lib\vc_lib\mswu\wx\setup.h
wx_adv.dsp:900:# Begin Custom Build - Creating ..\..\lib\vc_lib\mswud\wx\setup.h
wx_adv.dsp:903:"..\..\lib\vc_lib\mswud\wx\setup.h" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
wx_adv.dsp:904:	copy "$(InputPath)" ..\..\lib\vc_lib\mswud\wx\setup.h

So I wonder about Jeremy changed this part that regardless of
lefting other chaged point /libpath:"..\..\wxWidgets-2.6.3\lib\vc_lib".

Best Regards,

-- 
shelarcy <shelarcy    capella.freemail.ne.jp>
http://page.freett.com/shelarcy/

Re: [wxhaskell-users] process crashes on second 'start'

[Jeremy O'D. <jer...@gm...>]

Hi Conal,

On 07/12/06, Conal Elliott <co...@co...> wrote:
> Hi Jeremy,
>
> Thanks for the detailed pointers about wxWidgets, GUIs, and multi-threading.
>  My use is actually very simple.  The only reason I wanted multiple
> (sequential, not concurrent) invocations of 'start' is for convenience of
> use in ghci.
>
> I recently switched from wxWidgets 2.4.2 to 2.6.3, and I remember that this
> problem was worked around in 2.4.2 for use with ghci.  Is there really no
> way to fix the situation with 2.6.3?

This is what Daan said (in passing, in the context of another message
about the new wxHaskell maintenance team):

"Finally, I am not convinced that we should always use the latest
wxWidgets version: In particular, the 2.4.2 version is the only one
that lets you start and restart wxhaskell apps under GHCI under
window. The newer versions use static c++ classes and the destructors
are not called once the dll is loaded under GHCI (fixing this requires
fixing wxWidgets or letting GHCI reload DLL's too)."

> Do wxWidgets-2.4.2, wxHaskell-0.10.1 and ghc-6.6 get along together,
> including unicode issues?

I believe so (translation: I managed to get it to work on my PC under
WinXP). I understand that Unicode support in 2.4.2 is not so thorough
as for 2.6.3, although my Unicode requirements are minimal, so I
wouldn't expect to have seen any significant issues. Eric is working
on ways to test Unicode support more thoroughly. He's already
published one darcs patch.

In a couple of days (i.e. when it works...) I will be recompiling my
wx 2.4.2 based installation to test the new NMAKE makefile for wxc
(intention is to avoid the messy editing of Visual Studio project
files and create something easier to maintain). I'll let you know how
that goes.

> Does anyone use ghci with wxHaskell-0.10.1 and ghc-6.6?

Yes, although it's not my primary platform by a long way.

Jeremy

Re: [wxhaskell-users] process crashes on second 'start'

[Conal E. <co...@co...>]

Hi Jeremy,

Thanks for the detailed pointers about wxWidgets, GUIs, and
multi-threading.  My use is actually very simple.  The only reason I wanted
multiple (sequential, not concurrent) invocations of 'start' is for
convenience of use in ghci.

I recently switched from wxWidgets 2.4.2 to 2.6.3, and I remember that this
problem was worked around in 2.4.2 for use with ghci.  Is there really no
way to fix the situation with 2.6.3?

Do wxWidgets-2.4.2, wxHaskell-0.10.1 and ghc-6.6 get along together,
including unicode issues?

Does anyone use ghci with wxHaskell-0.10.1 and ghc-6.6?

  - Conal


On 12/7/06, Jeremy O'Donoghue <jer...@gm...> wrote:
>
> Hi Conal,
>
> On 07/12/06, Conal Elliott <co...@co...> wrote:
> > I submitted this bug report at the sourceforge project.  Is this a known
> > problem?  Any work-arounds?
> >
> > > Running two 'start'ed actions kills the process under ghc and ghci.
> > Example:
> > >
> > > import Graphics.UI.WX
> > > main = io >> io where io = start (frame [] >> return ())
>
> I'm not sure whether anyone has tried this before, but I would fully
> expect it not to work for several reasons:
>
> * I'm pretty sure that wxHaskell only expects to see a single instance
> of a wxWidgets wxApp (which is what start boils down to creating,
> among other things).
>
> * In fact, I think the whole point about wxApp is that it encapsulates
> a process with an event loop for handling GUI events, so the
> limitation is probably with wxWidgets itself (as it happens, I'm
> sceptical that what you are trying would work on any common GUI
> framework, for much the same reason)
>
> Work-around will depend on what you are trying to do.
>
> You can certainly have multiple top level frames, but they will share
> the same event loop. This is, by some margin, the easiest approach.
>
> If you genuinely want two communicating processes, you most likely
> need to create two separate executables - let's call them A and B. As
> part of start-up of A, it spawns B as a forked process, and A abd B
> communicate via pipes, IP sockets or some other appropriate mechanism.
>
> Another wrinkle to watch out for (again, common to most GUIs) is that
> only one thread should perform all event handling (in practice, this
> usually ends up being simplest by running all GUI activities in a
> single thread). Windows is expecially strict about this - X is
> slightly more permissive, but you are much better off following the
> 'one GUI thread' rule.
>
> Assuming that you have a multi-threaded application, typical design is
> for GUI to signal other 'worker' threads (which signal back). Again,
> details are likely to be very application dependent.
>
> One  final, somewhat unrelated issue: if you are planning to use
> wxWidgets with GHCi, it is worth knowing that you can actually only
> issue one start command in a given GHCi session. This is an underlying
> wxWidgets issue (use of static destructors in C++ code, I believe)
> which means that wxWidgets can only be restarted by unloading and
> reloading the wxWidgets DLL. Since GHCi isn't capable of doing this,
> you basically need to quit and restart a new session.
>
> There *is* a workaround for this: use wxWidgets 2.4.2 or earlier,
> which have a different allocation/deallocation strategy. This is why
> we continue to support wxWidgets 2.4.2.
>
> Regards
> Jeremy
>

Re: [wxhaskell-users] strings truncated to one character in wxhaskell-0.10.1 under ghc-6.6

[Jeremy O'D. <jer...@gm...>]

Hi Shelarcy

On 07/12/06, shelarcy <she...@gm...> wrote:
>
> Because current VC project for wxWidgets-2.6.3 doesn't works well my
> environment, and I was busy. Jeremy changed VC project from
> "..\..\wxWidgets-2.6.3\lib\vc_lib\mswu" to "..\..\wxWidgets-2.6.3\lib\mswu"
> in "Update VC++ project file to reflect updated DLL version supporting
> wxWidgets 2.6.3" patch. It breaks building my environment but I don't find
> where causes problem, soonly.

The real issue here is that whatever is in the VC++ Project file
reflects the individual users configuration. The build instructions on
the website explain how to change this, but it requires careful
editing in a file which is autogenerated (so not meant to be edited).

I am working on a replacement for the VC++ project files - an NMAKE
file for building wxc. It should be much simpler to reconfigure this
to the user's environment. It should be ready in a few more days
(obviously patch coming once it works), but the general idea is that
the user will just modify a few entries in an nmake.cfg file to
reflect their environment, wxWidgets version etc. I'll be very happy
if you could test it once it is done (so maybe not worth building
2.6.3 DLL immediately).

Regards
Jeremy

Re: [wxhaskell-users] process crashes on second 'start'

[Jeremy O'D. <jer...@gm...>]

Hi Conal,

On 07/12/06, Conal Elliott <co...@co...> wrote:
> I submitted this bug report at the sourceforge project.  Is this a known
> problem?  Any work-arounds?
>
> > Running two 'start'ed actions kills the process under ghc and ghci.
> Example:
> >
> > import Graphics.UI.WX
> > main = io >> io where io = start (frame [] >> return ())

I'm not sure whether anyone has tried this before, but I would fully
expect it not to work for several reasons:

* I'm pretty sure that wxHaskell only expects to see a single instance
of a wxWidgets wxApp (which is what start boils down to creating,
among other things).

* In fact, I think the whole point about wxApp is that it encapsulates
a process with an event loop for handling GUI events, so the
limitation is probably with wxWidgets itself (as it happens, I'm
sceptical that what you are trying would work on any common GUI
framework, for much the same reason)

Work-around will depend on what you are trying to do.

You can certainly have multiple top level frames, but they will share
the same event loop. This is, by some margin, the easiest approach.

If you genuinely want two communicating processes, you most likely
need to create two separate executables - let's call them A and B. As
part of start-up of A, it spawns B as a forked process, and A abd B
communicate via pipes, IP sockets or some other appropriate mechanism.

Another wrinkle to watch out for (again, common to most GUIs) is that
only one thread should perform all event handling (in practice, this
usually ends up being simplest by running all GUI activities in a
single thread). Windows is expecially strict about this - X is
slightly more permissive, but you are much better off following the
'one GUI thread' rule.

Assuming that you have a multi-threaded application, typical design is
for GUI to signal other 'worker' threads (which signal back). Again,
details are likely to be very application dependent.

One  final, somewhat unrelated issue: if you are planning to use
wxWidgets with GHCi, it is worth knowing that you can actually only
issue one start command in a given GHCi session. This is an underlying
wxWidgets issue (use of static destructors in C++ code, I believe)
which means that wxWidgets can only be restarted by unloading and
reloading the wxWidgets DLL. Since GHCi isn't capable of doing this,
you basically need to quit and restart a new session.

There *is* a workaround for this: use wxWidgets 2.4.2 or earlier,
which have a different allocation/deallocation strategy. This is why
we continue to support wxWidgets 2.4.2.

Regards
Jeremy

[wxhaskell-users] process crashes on second 'start'

[Conal E. <co...@co...>]

I submitted this bug report at the sourceforge project.  Is this a known
problem?  Any work-arounds?

Running two 'start'ed actions kills the process under ghc and ghci. Example:
>
> import Graphics.UI.WX
> main = io >> io where io = start (frame [] >> return ())
>
> OS: Windows XP
> Software versions:
> ghc: 6.6
> wxWidgets: 2.6.3
> wxHaskell: 0.10.1
>

Thanks,  - Conal

Re: [wxhaskell-users] strings truncated to one character in wxhaskell-0.10.1 under ghc-6.6

[shelarcy <she...@gm...>]

Hi Eric,

On Thu, 07 Dec 2006 08:11:58 +0900, Eric Y. Kow <eri...@gm...> wrote:
>> One more small annoyance.  I get many compiler complaints about -fPIC, e.g.,
>>
>> g++ -c wxc/src/ewxw_main.cpp -o out/wxc/ewxw_main.o -MD
>> -IC:/cygwin/usr/local/include -IC:/cygwin/usr/local/lib/wx/include/msw-
>> unicode-release-static-2.6 -IC:/cygwin/usr/local/include/wx-2.6 -D__WIN95__
>> -D__WXMSW__ -fPIC -Iwxc/include
>> cc1plus.exe: warning: -fPIC ignored for target (all code is position
>> independent)
>
> Hmm, this comes from Ari's patch to add -fPIC to the Makefile.  Perhaps
> we need this to be set by the configure script.  Anyone volunteer to
> submit a patch?

I know another problem exist in Ari's patch if build under Visual C++.
Visual C++ doesn't have inttypes.h. So Visual C++ (VC) doesn't build wxc now.
I attached darcs patch for solving its problem.


I'm sorry for testing Ari's patch is late.

Because current VC project for wxWidgets-2.6.3 doesn't works well my
environment, and I was busy. Jeremy changed VC project from
"..\..\wxWidgets-2.6.3\lib\vc_lib\mswu" to "..\..\wxWidgets-2.6.3\lib\mswu"
in "Update VC++ project file to reflect updated DLL version supporting
wxWidgets 2.6.3" patch. It breaks building my environment but I don't find
where causes problem, soonly.

Nobody pointed out this problem. So I think this is just my envirnments
problem, and I don't send any patch for that.


Attached also includes another patch that fix building error if using
wxWdgets with -enable-odbc or #define wxUSE_ODBC 1 in setup.h (under VC).
It is lacked part of my previous patch.

Best Regards,

-- 
shelarcy <shelarcy    capella.freemail.ne.jp>
http://page.freett.com/shelarcy/