wxhaskell-users — General mailing list for wxhaskell users

Re: [wxhaskell-users] problems on Windows

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

Hi Dean,

I'm very sorry nobody got back to you.  Personally, I filed your message
away in my pending queue and marked it 'reread'.

By the way, it might help to attach your examples in an easy
compile-and-run format, as I have hopefully done.  It just smooths
out these discussions a little bit! :-)

On Thu, May 15, 2008 at 01:10:58 -0400, Dean Herington wrote:
> I reread Daan's original paper and found a hint that layouts need to 
> mention each widget exactly once (though I can't find anything 
> definitive in documentation for either wxhaskell or wxwidgets). 
> Obeying that "rule" avoids the garbling, but I'm still not able 
> successfully to change the layout repeatedly.

Could you attach your modified code?  My experience with wxhaskell is
that once you create a widget, it's going to be displayed, so you might
as well lay it out somewhere.

> Even if I could, how 
> then would I show different subsets of widgets at different times?

You could set the visible attribute.
See attachment.

I do not claim that this is the right way to go about things.  Maybe
somebody like Mads or Shelarcy would have a better idea.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] problems on Windows

[Dean H. <her...@mi...>]

Is anyone out there???

I reread Daan's original paper and found a hint that layouts need to 
mention each widget exactly once (though I can't find anything 
definitive in documentation for either wxhaskell or wxwidgets). 
Obeying that "rule" avoids the garbling, but I'm still not able 
successfully to change the layout repeatedly.  Even if I could, how 
then would I show different subsets of widgets at different times?

Is there any hope of getting a decent description of wxhaskell's 
(intended) semantics?  I'm getting exasperated.

At 12:08 AM -0400 5/9/08, Dean Herington wrote:
>I'm using wxhaskell 0.10.3 with ghc 6.8.2 on Windows XP Pro.  I'm
>trying to figure out how to change the content of a frame
>dynamically.  The program shown below has several problems:
>    * The initial text is garbled (a combination of "Screen 1" and "Screen 2").
>    * The button label doesn't change when first clicked.
>    * Nothing changes on subsequent button presses.
>Any ideas?
>
>>   module Main where
>>
>>   import Graphics.UI.WX
>>
>>   main = start gui
>>
>>   gui = do
>>     f    <- frame [text := "Test 1"]
>>     p    <- panel f []
>>     t1   <- staticText p [text := "Screen 1"]
>>     b1   <- button p [text := "switch to 2"]
>>     t2   <- staticText p [text := "Screen 2"]
>>     b2   <- button p [text := "switch to 1"]
>>     set b1 [on command := switch f p t2 b2]
>>     set b2 [on command := switch f p t1 b1]
>>     switch f p t1 b1
>>
>>   switch f p t b = set f [layout := fill $ container p $ margin 10 $
>  >column 5 [widget t, widget b]]

[wxhaskell-users] problems on Windows

[Dean H. <her...@mi...>]

I'm using wxhaskell 0.10.3 with ghc 6.8.2 on Windows XP Pro.  I'm 
trying to figure out how to change the content of a frame 
dynamically.  The program shown below has several problems:
   * The initial text is garbled (a combination of "Screen 1" and "Screen 2").
   * The button label doesn't change when first clicked.
   * Nothing changes on subsequent button presses.
Any ideas?

>  module Main where
>
>  import Graphics.UI.WX
>
>  main = start gui
>
>  gui = do
>    f    <- frame [text := "Test 1"]
>    p    <- panel f []
>    t1   <- staticText p [text := "Screen 1"]
>    b1   <- button p [text := "switch to 2"]
>    t2   <- staticText p [text := "Screen 2"]
>    b2   <- button p [text := "switch to 1"]
>    set b1 [on command := switch f p t2 b2]
>    set b2 [on command := switch f p t1 b1]
>    switch f p t1 b1
>
>  switch f p t b = set f [layout := fill $ container p $ margin 10 $ 
>column 5 [widget t, widget b]]

Re: [wxhaskell-users] ;-{{ wx haskell distribution

[Mads L. <mad...@ya...>]

Hi,

> Do I understand correctly that there are now three places where I can  
> find wxHaskell:
> 
>   - http://wxhaskell.sourceforge.net/download.html
>   - darcs.haskell.org
>   - http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wx-0.10.3
> 

Is most Haskell projects not in this situation? You want to be on
Hackage, but it do not do version control or binary packages. Thus, we
use darcs.haskell.org and the SourceForge download service.

And I do not really see it as a problem, as long as there is one central
place where everything is linked from and explained. If there is one
central place, I cannot see how it makes a difference to users, that the
different methods of obtaining WxHaskell is located on different
servers.

Do you have a proposal for a better way to do it?

> and two place for the documentation:
> 
>   - http://wxhaskell.sourceforge.net/
>   - http://haskell.cs.yale.edu/haskellwiki/WxHaskell
> 

Yes, this is not optimal. If we are to continue having two places, then
there should be a clear and transparent (to users) distinction of what
goes where. I cannot see that this is currently the case.

What do people think of working towards using only the wiki?

> whereas I would expect for the latter one to have to go to:
> 
>   - http://www.haskell.org/haskellwiki/Category:Haskell ???, where  
> there is no refernce to
>   - http://www.haskell.org/haskellwiki/WxHaskell
> 
> Please, I do not want to complain, but I think that if we ever want  
> people to use (wx)Haskell we need to update this situation?

Good critique is always welcome.

> 
> Am I missing other places?
> 
>   Doaitse


Greetings,

Mads Lindstrøm


> 
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] ;-{{ wx haskell distribution

[S. D. S. <do...@sw...>]

Do I understand correctly that there are now three places where I can  
find wxHaskell:

  - http://wxhaskell.sourceforge.net/download.html
  - darcs.haskell.org
  - http://hackage.haskell.org/cgi-bin/hackage-scripts/package/wx-0.10.3

and two place for the documentation:

  - http://wxhaskell.sourceforge.net/
  - http://haskell.cs.yale.edu/haskellwiki/WxHaskell

whereas I would expect for the latter one to have to go to:

  - http://www.haskell.org/haskellwiki/Category:Haskell ???, where  
there is no refernce to
  - http://www.haskell.org/haskellwiki/WxHaskell

Please, I do not want to complain, but I think that if we ever want  
people to use (wx)Haskell we need to update this situation?

Am I missing other places?

  Doaitse

[wxhaskell-users] wxWidgets 2.8 support

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

Just a little heads up: I've pushed in set of patches from Jeremy
O'Donoghue which should make it possible to use wxhaskell with
wxWidgets 2.8.

For MacOS X Leopard users, yes, this means that you can run the darcs
version wxhaskell (it runs fine on my machine).

Unfortunately, this means breaking support for prior versions of
wxWidgets.  We are working out what to do about this...

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] .so/.DLL

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

Sorry to be unhelpful, but I've updated the wiki with a placeholder,
should you ever find a solution for this
  http://www.haskell.org/haskellwiki/WxHaskell/Install

Also, Adrian Neumann and Conal Elliot have experienced the same
problem (see list archives), so you're not alone.  If you're reading
this, Conal, did you ever sort it out?

I've tried googling "ghci adddll unknown error" and noticed that
people using other libraries seem to have a similar problem.   I
wonder if this is related:

http://www.mail-archive.com/has...@ha.../msg32740.html

Could prefixing that wxc-msw with a 'lib' do the trick?

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] .so/.DLL

[Jaap v. d. W. <j.c...@tu...>]

Dear Jeremy

Thanks for your prompt reply.
I'm sorry to bother you again, but the wish to use wxHaskell exceeds the
reluctance to steal your time you with my ignorance.

I did check the package.conf and everything is allright
(directly and using your "decribe"-trick).
The directories and libraries are there and the registration succeeded
perfectly (for path-names without spaces, so the directory "program
files" is off limits). Changing drives, directories, even library-names
did not change anything: Still GHCi complains about  not being able to
load the .dll for wxc-msw2.6.4-0.10.3, (not about finding it)
(addDLL:unknown error).

I hope you or any of the other readers of this message can solve this
problem. (it is also mentioned on the fa.haskell "forum", directly after
you announcing the new wxHaskell being released.)

best regards
Jaap



On Thu, 2008-04-17 at 18:54 +0100, Jeremy O'Donoghue wrote:
> Dear Jaap,
> 
> On Thu, 17 Apr 2008 13:25:43 +0200, "Woude, J.C.S.P. van der"
> <J.C...@TU...> said:
> > 
> > After some trouble with paths with spaces in their names I got it
> > registered
> > 
> > But...Ghci cannot find the library for wxc-msw2.... Etc (screenshot
> > included)
> > 
> > What can I do to make it work properly?
> 
> This is probably an installation issue. This is how to start to 
> diagnose:
> 
> Type the following at a command prompt: ghc-pkg describe wxcore
> 
> You should get something like (less important lines for this
> investigation have been deleted):
> 
> name: wxcore
> version: 0.10.3
> ...
> import-dirs: C:\utils\wxhaskell-0.10.3\lib\imports
> library-dirs: C:\utils\wxhaskell-0.10.3\lib
> hs-libraries: wxcore wxcore0 wxcore1 wxcore2
> extra-libraries: wxc-msw2.6.4-0.10.3
> ...
> 
> The key parts are the lines starting 'library-dirs:', 'extra-libraries'
> and 'hs-libraries', which describe where the libraries are loaded from
> by GHC, and which libraries are loaded. The 'extra-libraries:' are DLLs
> loaded by GHCi and/or any generated executable. 
> 
> In my case, what this says is that the extra library wxc-msw2.6.4-0.10.3
> (which is actually called wxc-msw2.6.4-0.10.3
> .dll) will be loaded from library directory
> C:\utils\wxhaskell-0.10.3\lib. The first thing you need to do is to
> check that a DLL of the correct name is in the library-dirs directory
> you have selected. 
> 
> If this is not the case, the simplest thing would be to move the DLL to
> wherever GHCi is expecting it, although it would be cleaner to
> reregister
> the package with the details corrected to match your installation.
> 
> If this doesn't help to fix the problem, please feel free to mail back.
> I'd recommend including wxh...@li... in the CC
> on mail as others may have come across the same problem as you.
> 
> Good luck, and thank you for trying wxHaskell.
> 
> Best regards
> Jeremy
-- 
Jaap van der Woude <j.c...@tu...>

Re: [wxhaskell-users] Installation on Windows, DLL can't be loaded

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

Hi Adrian,

On Mon, 07 Apr 2008 15:17:46 +0900, Adrian Neumann <ane...@in...> wrote:
> I did. Windows throws an error. Something like "program cannot be
> initialized". The same thing I assume.

Pleas check error number. Is your error same this one?

http://www.mail-archive.com/wxh...@li.../msg00441.html

If so, you can fix problem by installing Microsoft Visual C++ 2005
SP1 Redistributable Package.

http://www.mail-archive.com/wxh...@li.../msg00457.html
http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en


> José Miguel Vilaça schrieb:
>> Hi ADrian,
>>
>> Did you tried to compile that?
>> ghc -package wx Helloword.hs
>>
>> And running Helloword.exe is ok?

Best Regards,

-- 
shelarcy <shelarcy    hotmail.co.jp>
http://page.freett.com/shelarcy/

Re: [wxhaskell-users] Installation on Windows, DLL can't be loaded

[Adrian N. <ane...@in...>]

I did. Windows throws an error. Something like "program cannot be 
initialized". The same thing I assume.

Adrian

José Miguel Vilaça schrieb:
> Hi ADrian,
> 
> Did you tried to compile that?
> ghc -package wx Helloword.hs
> 
> And running Helloword.exe is ok?
> 
> Best
> Miguel Vilaça
> 
> 
> -----Mensagem original-----
> De: wxh...@li...
> [mailto:wxh...@li...] Em nome de Adrian
> Neumann
> Enviada: sábado, 5 de Abril de 2008 18:09
> Para: wxh...@li...
> Assunto: [wxhaskell-users] Installation on Windows, DLL can't be loaded
> 
> Hi,
> 
> I just installed ghc6.8, wxWidgets2.6 and wxHaskell10.3. I tried to run 
> the HelloWorld program from the samples directory, but ghci gives me
> 
> C:\ghc\wxhaskell-0.10.3\samples\wx>ghci -package wx HelloWorld.hs
> GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
> Loading package base ... linking ... done.
> Loading package old-locale-1.0.0.0 ... linking ... done.
> Loading package old-time-1.0.0.0 ... linking ... done.
> Loading package filepath-1.1.0.0 ... linking ... done.
> Loading package directory-1.0.0.0 ... linking ... done.
> Loading package random-1.0.0.0 ... linking ... done.
> Loading package process-1.0.0.0 ... linking ... done.
> Loading package array-0.1.0.0 ... linking ... done.
> Loading package haskell98 ... linking ... done.
> Loading package wxcore-0.10.3 ... : can't load .so/.DLL for: 
> wxc-msw2.6.4-0.10.3
>   (addDLL: unknown error)
> 
> That's strange, since the DLL is in Windows/system32, which is naturally 
> in my PATH.
> 
> I googled, but to no avail. Nobody seems to share my problem. Does 
> anybody on this mailing-list know what to do?
> 
> Adrian
> 
> 

Re: [wxhaskell-users] Installation on Windows, DLL can't be loaded

[José M. V. <jmv...@di...>]

Hi ADrian,

Did you tried to compile that?
ghc -package wx Helloword.hs

And running Helloword.exe is ok?

Best
Miguel Vilaça


-----Mensagem original-----
De: wxh...@li...
[mailto:wxh...@li...] Em nome de Adrian
Neumann
Enviada: sábado, 5 de Abril de 2008 18:09
Para: wxh...@li...
Assunto: [wxhaskell-users] Installation on Windows, DLL can't be loaded

Hi,

I just installed ghc6.8, wxWidgets2.6 and wxHaskell10.3. I tried to run 
the HelloWorld program from the samples directory, but ghci gives me

C:\ghc\wxhaskell-0.10.3\samples\wx>ghci -package wx HelloWorld.hs
GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
Loading package base ... linking ... done.
Loading package old-locale-1.0.0.0 ... linking ... done.
Loading package old-time-1.0.0.0 ... linking ... done.
Loading package filepath-1.1.0.0 ... linking ... done.
Loading package directory-1.0.0.0 ... linking ... done.
Loading package random-1.0.0.0 ... linking ... done.
Loading package process-1.0.0.0 ... linking ... done.
Loading package array-0.1.0.0 ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading package wxcore-0.10.3 ... : can't load .so/.DLL for: 
wxc-msw2.6.4-0.10.3
  (addDLL: unknown error)

That's strange, since the DLL is in Windows/system32, which is naturally 
in my PATH.

I googled, but to no avail. Nobody seems to share my problem. Does 
anybody on this mailing-list know what to do?

Adrian

Re: [wxhaskell-users] Installation on Windows, DLL can't be loaded

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

On Sat, Apr 05, 2008 at 19:09:27 +0200, Adrian Neumann wrote:
> Loading package wxcore-0.10.3 ... : can't load .so/.DLL for: 
> wxc-msw2.6.4-0.10.3
>  (addDLL: unknown error)

If you do find an answer, could you please update the wiki?
http://www.haskell.org/haskellwiki/WxHaskell/Install#Troubleshooting

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

[wxhaskell-users] Installation on Windows, DLL can't be loaded

[Adrian N. <ane...@in...>]

Hi,

I just installed ghc6.8, wxWidgets2.6 and wxHaskell10.3. I tried to run 
the HelloWorld program from the samples directory, but ghci gives me

C:\ghc\wxhaskell-0.10.3\samples\wx>ghci -package wx HelloWorld.hs
GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
Loading package base ... linking ... done.
Loading package old-locale-1.0.0.0 ... linking ... done.
Loading package old-time-1.0.0.0 ... linking ... done.
Loading package filepath-1.1.0.0 ... linking ... done.
Loading package directory-1.0.0.0 ... linking ... done.
Loading package random-1.0.0.0 ... linking ... done.
Loading package process-1.0.0.0 ... linking ... done.
Loading package array-0.1.0.0 ... linking ... done.
Loading package haskell98 ... linking ... done.
Loading package wxcore-0.10.3 ... : can't load .so/.DLL for: 
wxc-msw2.6.4-0.10.3
  (addDLL: unknown error)

That's strange, since the DLL is in Windows/system32, which is naturally 
in my PATH.

I googled, but to no avail. Nobody seems to share my problem. Does 
anybody on this mailing-list know what to do?

Adrian

[wxhaskell-users] ANN: wxHaskell 0.10.3

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

The wxHaskell development team is pleased to announce the release of
wxHaskell 0.10.3, a Haskell binding
for the wxWidgets GUI library.

The Haskell support is built on a reasonably complete C language
binding, which
could be used as the basis for wxWidgets support on other
languages/platforms
which do not have easy mechanisms for linking with C++ code.

The feature set is the same as wxHaskell 0.10.3 rc1 and rc2, with a
number of
additional bugfixes.

This is the first full release since June 2005, and is the result of a
great deal of work by a new team of contributors.

Highlights of 0.10.3 include:

- Support for Unicode builds of wxWidgets
- Support for additional widgets including calendar, toolbar divider,
  styled text control (wxScintilla), media control
- Support for clipboard, drag and drop
- Support for 64bit (Linux) targets
- Support for wxWidgets 2.6.x (support for wxWidgets 2.4.2 if
  you compile from source). wxWidgets 2.8 is not yet supported
- Support for building with GHC 6.6.x and 6.8.x
- Parts of wxHaskell are now built with Cabal
- New test cases
- Removed support GHC version < 6.4
- Profiling support
- Smaller generated binary sizes (using --split-objs)

Binary packages are available from the wxHaskell download site at
http://sourceforge.net/project/showfiles.php?group_id=73133, for the
following platforms:

- Debian
- Windows
- OS X (Intel and PPC platforms)
- Source code .tar.gz and .zip
- Documentation (cross-platform)

The wxHaskell libraries (wxcore and wx) are also available from Hackage
(http://hackage.haskell.org).

About wxHaskell
---------------

wxHaskell is a Haskell binding to the wxWidgets GUI library for recent
versions
of the Glasgow Haskell Compiler. It provides a native look and feel on
Windows,
OS X and Linux, and a medium level programming interface.

The main project page for wxHaskell is at
http://wxhaskell.sourceforge.net.
The latest source code for wxHaskell can always be obtained from
http://darcs.haskell.org/wxhaskell.
There are developer (wxh...@li... and user
(wxh...@li...) mailing lists, and a wiki page
at http://haskell.org/haskellwiki/WxHaskell which can provide more
information to those interested.

wxHaskell was originally created by Daan Leijen. The contributors to
this new release include:

- Eric Kow
- shelarcy
- Arie Middelkoop
- Mads Lindstroem
- Jeremy O'Donoghue
- Lennart Augustson

The C language binding for wxHaskell was derived from an original C
language binding created for the Eiffel programming language by the
ELJ project (http://elj.sourceforge.net).
-- 
  Jeremy O'Donoghue
  jer...@gm...

[wxhaskell-users] ANN: wxHaskell 0.10.3

[Jeremy O'D. <je...@o-...>]

The wxHaskell development team is pleased to announce the release of
wxHaskell 0.10.3, a Haskell binding
for the wxWidgets GUI library. 

The Haskell support is built on a reasonably complete C language
binding, which
could be used as the basis for wxWidgets support on other
languages/platforms
which do not have easy mechanisms for linking with C++ code. 

The feature set is the same as wxHaskell 0.10.3 rc1 and rc2, with a
number of
additional bugfixes.

This is the first full release since June 2005, and is the result of a
great deal of work by a new team of contributors.

Highlights of 0.10.3 include:

- Support for Unicode builds of wxWidgets
- Support for additional widgets including calendar, toolbar divider,
  styled text control (wxScintilla), media control
- Support for clipboard, drag and drop
- Support for 64bit (Linux) targets
- Support for wxWidgets 2.6.x (support for wxWidgets 2.4.2 if 
  you compile from source). wxWidgets 2.8 is not yet supported
- Support for building with GHC 6.6.x and 6.8.x
- Parts of wxHaskell are now built with Cabal
- New test cases
- Removed support GHC version < 6.4
- Profiling support
- Smaller generated binary sizes (using --split-objs)

Binary packages are available from the wxHaskell download site at
http://sourceforge.net/project/showfiles.php?group_id=73133, for the
following platforms:

- Debian
- Windows
- OS X (Intel and PPC platforms)
- Source code .tar.gz and .zip
- Documentation (cross-platform)

The wxHaskell libraries (wxcore and wx) are also available from Hackage
(http://hackage.haskell.org).

About wxHaskell
---------------

wxHaskell is a Haskell binding to the wxWidgets GUI library for recent
versions
of the Glasgow Haskell Compiler. It provides a native look and feel on
Windows, 
OS X and Linux, and a medium level programming interface.

The main project page for wxHaskell is at
http://wxhaskell.sourceforge.net.
The latest source code for wxHaskell can always be obtained from
http://darcs.haskell.org/wxhaskell.
There are developer (wxh...@li... and user
(wxh...@li...) mailing lists, and a wiki page
at http://haskell.org/haskellwiki/WxHaskell which can provide more
information to those interested.

wxHaskell was originally created by Daan Leijen. The contributors to
this new release include:

- Eric Kow
- shelarcy
- Arie Middelkoop
- Mads Lindstroem
- Jeremy O'Donoghue
- Lennart Augustson

The C language binding for wxHaskell was derived from an original C
language binding created for the Eiffel programming language by the 
ELJ project (http://elj.sourceforge.net).

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

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

Hi,

I start this when i read in  
http://wxhaskell.sourceforge.net/download.html that concerning  
binaries for version 0.10.3:
"All packages have ODBC support (but not OpenGL)."

But at least the windows binary (as stated by shelarcy) and the  
wxhaskell-bin-powerpc-mac2.6.4-ghc6.8.2-0.10.3-0.dmg have opengl  
enabled.

I tested those two packages my self with code using opengl.

So, is just that the information at the webpage is more restricted  
than the packages :-)

best
Miguel Vilaça


Quoting Conal Elliott <co...@co...>:

> As long as there's a single binary (per release per platform) I'm for opengl
> being part of it.
>
> On Sat, Mar 29, 2008 at 6:56 AM, Eric Y. Kow <eri...@gm...> wrote:
>
>> Hi,
>>
>> Answering the one question I know an answer to.
>>
>> > In the meanwhile, I also found that the 0.10.3 binaries loose the
>> > opengl support compared with 0.9.4 as pointed in
>> > http://wxhaskell.sourceforge.net/download.html.
>> > Is there some reason for this?
>>
>> There used to be a flag bug in wxWidgets/wxHaskell, where (1)
>> wxWidgets/wxHaskell would include opengl support even if you did not
>> ask for it and (2) you still needed to pass --with-opengl in order
>> for the appropriate right set of linker flags to be used when building
>> applications.  Otherwise, people got strange GL-related errors when
>> compiling their apps, even if they weren't using OpenGL in any way.
>>
>> We have now fixed that error so that you can now compile it without that
>> flag and still link your applications succesfully.
>>
>> That said, we have not established a policy on what extra batteries
>> should be included with the default binaries.  I guess a good thing to
>> aim for is the most extras we can get that also come with a vanilla
>> wxWidgets on all platforms.  If you're willing to do research on that,
>> we can go re-think what flags to use.  I'm guessing that since prior
>> versions of wxHaskell had opengl support, this kind of thing is OK.
>>
>> I'm personally hoping that a future wxhaskell will allow to install
>> extras separately (e.g., that you could download just a binary for
>> opengl support), but we haven't really worked out the right way to
>> do this right.
>>
>> So what does this mean for you?  Well, if you're willing to do so, you
>> could recompile it yourself with flags.  Otherwise, we could think about
>> making yet another release (0.10.3-1) with opengl and some minor fixes
>> in the makefile/configure script.
>>
>> --
>> Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
>> PGP Key ID: 08AC04F9
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>>
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>> _______________________________________________
>> wxhaskell-users mailing list
>> wxh...@li...
>> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>>
>>
>

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

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

As long as there's a single binary (per release per platform) I'm for opengl
being part of it.

On Sat, Mar 29, 2008 at 6:56 AM, Eric Y. Kow <eri...@gm...> wrote:

> Hi,
>
> Answering the one question I know an answer to.
>
> > In the meanwhile, I also found that the 0.10.3 binaries loose the
> > opengl support compared with 0.9.4 as pointed in
> > http://wxhaskell.sourceforge.net/download.html.
> > Is there some reason for this?
>
> There used to be a flag bug in wxWidgets/wxHaskell, where (1)
> wxWidgets/wxHaskell would include opengl support even if you did not
> ask for it and (2) you still needed to pass --with-opengl in order
> for the appropriate right set of linker flags to be used when building
> applications.  Otherwise, people got strange GL-related errors when
> compiling their apps, even if they weren't using OpenGL in any way.
>
> We have now fixed that error so that you can now compile it without that
> flag and still link your applications succesfully.
>
> That said, we have not established a policy on what extra batteries
> should be included with the default binaries.  I guess a good thing to
> aim for is the most extras we can get that also come with a vanilla
> wxWidgets on all platforms.  If you're willing to do research on that,
> we can go re-think what flags to use.  I'm guessing that since prior
> versions of wxHaskell had opengl support, this kind of thing is OK.
>
> I'm personally hoping that a future wxhaskell will allow to install
> extras separately (e.g., that you could download just a binary for
> opengl support), but we haven't really worked out the right way to
> do this right.
>
> So what does this mean for you?  Well, if you're willing to do so, you
> could recompile it yourself with flags.  Otherwise, we could think about
> making yet another release (0.10.3-1) with opengl and some minor fixes
> in the makefile/configure script.
>
> --
> Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
> PGP Key ID: 08AC04F9
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
>
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

[José M. V. <jmv...@di...>]

Hi,

The Microsoft Visual C++ 2005 SP1 Redistributable Package solves the
problem. Just great! 

If anyone with access to wxHaskell webpage at sourceforge could add a note
in downloads page about this issue, could avoid others to have this problem.
Something like
You may need to install Microsoft Visual C++ 2005 SP1 Redistributable
Package
(http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14
-984d-389c36f85647&DisplayLang=en) or else you may see the error message
"The applicattion failed to initialize properly (0xc0150002). Click OK to
terminate the application." when you compile your wxHaskell dependent code
and run those executables.

Many thanks!
Miguel Vilaça


-----Mensagem original-----
De: shelarcy [mailto:she...@gm...] 
Enviada: sábado, 29 de Março de 2008 14:34
Para: José Miguel Vilaça
Cc: wxhaskell-users
Assunto: Re: RE: wxHaskell 0.10.3: problems in Windows XP

Hi,

On Thu, 27 Mar 2008 07:55:50 +0900, José Miguel Vilaça
<jmv...@di...> wrote:
> I successfully installed Visual C++ 2005 Redistributable Package on
Windows
> XP but the same error remains. I even rebooted (for some reason this
usually
> solve many problems) the machine but no luck either.
>
> I'll take more time around this during the weekend, to see if I discover
the
> reason for this error.

Oops ... I found "SP1" Redistributable Package is different from non-SP
Redistributable Package.

Please try to use Microsoft Visual C++ 2005 SP1 Redistributable Package
(x86).

http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-
984d-389c36f85647&DisplayLang=en

-- 
shelarcy <shelarcy    hotmail.co.jp>
http://page.freett.com/shelarcy/

Re: [wxhaskell-users] Binding wxImage::Get/SetOption and InMemoryStream constructor

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

Hi,

On Sat, 29 Mar 2008 23:29:08 +0900, Eric Y. Kow <eri...@gm...> wrote:
>> What's the EXWXEXPORT() macro for? It didn't seem very useful to me...
>
> (snip)
>
> I get the impression that it's there for some kind of portability reasons.
> Will need to do research on this mysterious __declspec(dllexport), __cdecl and
> _cdecl business to understand better.  Anyone already know what these do?

__declspec(dllexport) is a calling convention to export functions in DLL,
on Windows platform (Visual Studio). This convention's advantage is efficiency.

http://msdn2.microsoft.com/en-us/library/3y1sfaz2(VS.80).aspx
http://msdn2.microsoft.com/en-us/library/9h658af8(VS.80).aspx

So, EXWXEXPORT is important for Windows user.


Best Regards,

-- 
shelarcy <shelarcy    hotmail.co.jp>
http://page.freett.com/shelarcy/

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

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

On Sat, 29 Mar 2008 22:41:19 +0900, Miguel Vilaça <jmv...@di...> wrote:
> Some pratical, to find a solutions is pointed in
> http://www.tech-archive.net/Archive/VC/microsoft.public.vc.mfc/2006-09/msg02020.html:
> "To see dependent DLLs, open your application with the dependency
> viewer (depends.exe)."
>
> Can you please take a look on this and see if everything needed is
> going into the DLL?

Dependency Walker is free. So, I think you can look that yourself.

http://www.dependencywalker.com/

Anyway I saw that.

> Error: At least one required implicit or forwarded dependency was not found.
> Warning: At least one delay-load dependency module was not found.
> Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

This error come from MSVCR80.DLL.
And I found SP1's DLL is different from non-SP one today that I told you in previous mail.
So, please test SP1's DLL.


> In the meanwhile, I also found that the 0.10.3 binaries loose the
> opengl support compared with 0.9.4 as pointed in
> http://wxhaskell.sourceforge.net/download.html.
> Is there some reason for this?

I always enable opengl support to release Windows binary.
(Because previous version (include 0.9.4) is built by that policy.)

I think this difference is come from ghc's behavior change.
Please use -package OpenGL or --make to build executable files.

Best Regards,

-- 
shelarcy <shelarcy    hotmail.co.jp>
http://page.freett.com/shelarcy/

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

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

Hi,

On Thu, 27 Mar 2008 07:55:50 +0900, José Miguel Vilaça <jmv...@di...> wrote:
> I successfully installed Visual C++ 2005 Redistributable Package on Windows
> XP but the same error remains. I even rebooted (for some reason this usually
> solve many problems) the machine but no luck either.
>
> I'll take more time around this during the weekend, to see if I discover the
> reason for this error.

Oops ... I found "SP1" Redistributable Package is different from non-SP
Redistributable Package.

Please try to use Microsoft Visual C++ 2005 SP1 Redistributable Package (x86).

http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&DisplayLang=en

-- 
shelarcy <shelarcy    hotmail.co.jp>
http://page.freett.com/shelarcy/

Re: [wxhaskell-users] Binding wxImage::Get/SetOption and InMemoryStream constructor

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

Hi,

By the way, if I haven't already mentioned this, there is a wxhaskell-devel
that you may prefer to discuss this on.  Personally, I'm happy either way.

> The code is so short that I embed it in this email. I'd be interested
> to hear any comments on the way I did this, and what you would want to
> change before committing it to wxhaskell.

Sorry, I can't offer much insight here.  Hoping somebody else pipes up.
Looking forward to your patch, in any case.

> Then a haskell stub file to wrap a Ptr version of this and two
> bytestring versions:

Note that wxhaskell doesn't currently use the bytestring package.  I
guess this would be a pretty safe thing to add, since if I understand
correctly, it's been around since GHC 6.6.  On the other hand, unless
we're willing to say that we only support GHC 6.8.2+, starting from
wxhaskell 0.11

> It works, anyhow. I am able to load images from bytestreams (as it
> happens, the cover art from an M4A file). The magic invocation to get
> ghc to link it correctly seems to be:
> 
> ghc --make main.hs cstub.o -lstdc++ `wx-config --libs` -optl -fexceptions

I think that by rights, it should be possible to modify wxcore, so that
the right linker flags get used when you use the wxcore package (e.g.
with ghc --make)

> For return types of type String, looking at the examples in elj*.cpp,
> why does it sometimes use copyStrToBuf to unpack the WxString on the
> C++ side in combination with withWStringResult on the haskell side,
> and other times just pass back the a freshly allocated WxString* from
> C++ in combination with withManagedStringResult?

Not sure.  In case you were curious, copyStrToBuf was something I
had introduced in my Unicode patches to replace

  if (_buf) memcpy (_buf, result.c_str(), result.Length());
  return result.Length();

The reason for doing it this way was quite simply that I had gotten
sick of repeating

  if (dst) wxStrcpy ((wxChar*) dst, src.c_str());
  return src.Length();

In any case, I guess it doesn't answer your question.  I just wanted to
point our that there isn't anything particularly special about this
helper, which you probably realise anyway.

> For arguments of object types, why do some bindings use withObjectPtr
> and some use withObjectRef?

I don't know.  Anybody else?

> What's the EXWXEXPORT() macro for? It didn't seem very useful to me...

You meant EWXWEXPORT :-D  Again, I do not know.  I guess that you have also had
a look at wxc/include/ewxw_def.h.  Looking at it...

#ifdef __WATCOMC__
  #include <windows.h>
  #define EWXWEXPORT(TYPE,FUNC_NAME) TYPE __export __cdecl FUNC_NAME
#else
  #ifdef _WIN32
    #define EWXWEXPORT(TYPE,FUNC_NAME) __declspec(dllexport) TYPE __cdecl FUNC_NAME
    #undef EXPORT
    #define EXPORT extern "C" __declspec(dllexport) 
  #else
    #define EWXWEXPORT(TYPE,FUNC_NAME) TYPE FUNC_NAME
  #endif
  #ifndef _cdecl
    #define _cdecl
  #endif
#endif

I get the impression that it's there for some kind of portability reasons.
Will need to do research on this mysterious __declspec(dllexport), __cdecl and
_cdecl business to understand better.  Anyone already know what these do?
 
I did not find any (relevant) instances of the string 'EWXW' in wxdirect, and
thus surmise that (unlike TSelf), it is not used for generating the Haskell
binding.  One possibility is that it's just some vestigal code from the
wxEiffel days, and isn't actually useful anymore.

Sorry to be unhelpful :-/

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

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

Hi,

Answering the one question I know an answer to.

> In the meanwhile, I also found that the 0.10.3 binaries loose the  
> opengl support compared with 0.9.4 as pointed in  
> http://wxhaskell.sourceforge.net/download.html.
> Is there some reason for this?

There used to be a flag bug in wxWidgets/wxHaskell, where (1)
wxWidgets/wxHaskell would include opengl support even if you did not
ask for it and (2) you still needed to pass --with-opengl in order
for the appropriate right set of linker flags to be used when building
applications.  Otherwise, people got strange GL-related errors when
compiling their apps, even if they weren't using OpenGL in any way.

We have now fixed that error so that you can now compile it without that
flag and still link your applications succesfully.

That said, we have not established a policy on what extra batteries
should be included with the default binaries.  I guess a good thing to
aim for is the most extras we can get that also come with a vanilla
wxWidgets on all platforms.  If you're willing to do research on that,
we can go re-think what flags to use.  I'm guessing that since prior
versions of wxHaskell had opengl support, this kind of thing is OK.

I'm personally hoping that a future wxhaskell will allow to install
extras separately (e.g., that you could download just a binary for
opengl support), but we haven't really worked out the right way to
do this right.

So what does this mean for you?  Well, if you're willing to do so, you
could recompile it yourself with flags.  Otherwise, we could think about
making yet another release (0.10.3-1) with opengl and some minor fixes
in the makefile/configure script.

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP

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

Hi again,

After several unsuccesseful tries, and some googling, I found out many  
complains   of people seeing the message "The applicattion failed to  
initialize properly (0xc0150002). Click OK to terminate the  
application." when they run their executables out of the devellopment  
machine.

The error also seems to be often related with:
* DXUT - related with images and DirectX SDK - (see  
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1048802&SiteID=1)
* MS Office (see  
http://support.microsoft.com/search/default.aspx?mode=r&catalog=LCID%3d1033&1033comm=1&spid=global&query=0xc0150002   
)

Some pratical, to find a solutions is pointed in  
http://www.tech-archive.net/Archive/VC/microsoft.public.vc.mfc/2006-09/msg02020.html:
"To see dependent DLLs, open your application with the dependency  
viewer (depends.exe)."

Can you please take a look on this and see if everything needed is  
going into the DLL?


In the meanwhile, I also found that the 0.10.3 binaries loose the  
opengl support compared with 0.9.4 as pointed in  
http://wxhaskell.sourceforge.net/download.html.
Is there some reason for this?

In my specific case that will also be a problem.
But the 0xc0150002 is not related to this since the simple (and not  
opengl related) HelloWorld.exe continues failling in my machine.

Since I found one machine that runs the code and one that doesn't, I  
comparing the software installed on them. Maybe I found a solution  
this way!!

best
Miguel Vilaça



Quoting José Miguel Vilaça <jmv...@di...>:

> Hi Shelarcy,
>
> Thanks for your quick help.
>
> I successfully installed Visual C++ 2005 Redistributable Package on Windows
> XP but the same error remains. I even rebooted (for some reason this usually
> solve many problems) the machine but no luck either.
>
> I'll take more time around this during the weekend, to see if I discover the
> reason for this error.
>
> In the meanwhile, I would appreciate any report of a successful installation
> of wxHaskell binary on Windows XP (without the development stuff). Anyone?
> Just to check if this is a specific error (of this machine) or a global one.
>
> Best
> Miguel Vilaça
>
>
> -----Mensagem original-----
> De: wxh...@li...
> [mailto:wxh...@li...] Em nome de shelarcy
> Enviada: quarta-feira, 26 de Março de 2008 14:20
> Para: Miguel Vilaça
> Cc: wxhaskell-users
> Assunto: Re: [wxhaskell-users] wxHaskell 0.10.3: problems in Windows XP
>
> Hi Miguel,
>
> On Wed, 26 Mar 2008 21:21:47 +0900, Miguel Vilaça <jmv...@di...>
> wrote:
>> "The applicattion failed to initialize properly (0xc0150002). Click OK
>> to terminate the application."
>
> I searched this error using goole, then I found similar problem form
> websites
> and forums. Some of them advice to install Visual C++ 2005 Redistributable
> Package.
>
> http://www.issociate.de/board/post/474708/Xampp_Apache_Install_Problem.html
>
> How about install that?
> You can get that from below page.
>
> http://www.microsoft.com/Downloads/details.aspx?FamilyID=32bc1bee-a3f9-4c13-
> 9c99-220b62a191ee&displaylang=en
>
> Best Regards,
>
> --
> shelarcy <shelarcy    hotmail.co.jp>
> http://page.freett.com/shelarcy/
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>

[wxhaskell-users] Binding wxImage::Get/SetOption and InMemoryStream constructor

[Jules B. <ju...@je...>]

So, I have successfully added some of the missing bindings that I needed.

The code is so short that I embed it in this email. I'd be interested
to hear any comments on the way I did this, and what you would want to
change before committing it to wxhaskell.

1) Loading images from in-memory blocks

Stub C++ file to bind to the appropriate wxImage constructor:

#include "wx/wx.h"
#include "wx/image.h"
#include "wx/mstream.h"

extern "C"
{
   void * wxImage_CreateFromFileInMemory(void* data,int length,int type) {
     wxMemoryInputStream in(data,length);
     return (void*) new wxImage(in,type);
   }
}

You can compile this with "g++ -c `wx-config --cppflags` cstub.cpp"

Then a haskell stub file to wrap a Ptr version of this and two
bytestring versions:

{-# OPTIONS -fglasgow-exts #-}
module ImageExtras where

import qualified Data.ByteString.Lazy as LB
import qualified Data.ByteString as B
import Foreign
import Foreign.C
import Graphics.UI.WXCore.WxcTypes
import Graphics.UI.WXCore.WxcClassTypes

imageCreateFromPtrFile :: Ptr b -> Int -> Int -> IO (Image ())
imageCreateFromPtrFile ptr len typ
   = withManagedObjectResult $
     wxImage_CreateFromFileInMemory ptr (fromIntegral len) (fromIntegral 
typ)
foreign import ccall "wxImage_CreateFromFileInMemory"
   wxImage_CreateFromFileInMemory :: Ptr b -> CInt -> CInt -> IO (Ptr 
(TImage ()))
imageCreateFromLBytestringFile :: LB.ByteString -> Int -> IO (Image  ())
imageCreateFromLBytestringFile bs typ
   = withArray (LB.unpack bs) $ \ptr ->
   imageCreateFromPtrFile ptr (fromIntegral $ LB.length bs) typ

imageCreateFromBytestringFile :: B.ByteString -> Int -> IO (Image  ())
imageCreateFromBytestringFile bs typ
   = withArray (B.unpack bs) $ \ptr ->
   imageCreateFromPtrFile ptr (B.length bs) typ

I'm not sure if you can make these a bit more efficient by attacking
the underlying bytestring rep, but I didn't try.

It works, anyhow. I am able to load images from bytestreams (as it
happens, the cover art from an M4A file). The magic invocation to get
ghc to link it correctly seems to be:

ghc --make main.hs cstub.o -lstdc++ `wx-config --libs` -optl -fexceptions

2) GetOption / SetOption for Images

Slightly more fiddly. The C++ stub looks like this:

#include "wx/wx.h"
#include "wx/image.h"

extern "C"
{
   void wxImage_SetOption(void *_obj, void* key,void *value) {
     ((wxImage*)_obj)->SetOption((wxChar*)key,(wxChar*)value);
   }
   wxString* wxImage_GetOption(void *_obj, void* key) {
     return new wxString(((wxImage*)_obj)->GetOption((wxChar*)key));
   }
}

(it took me quite a while to understand why casting to wxChar* works
when the underlying type is WxString&; there is an implicit conversion
because of a constructor)

The haskell stub is this:

{-# OPTIONS -fglasgow-exts #-}
module ImageOptions where

import Graphics.UI.WXCore.WxcTypes
import Graphics.UI.WXCore.WxcClassTypes

imageSetOption :: Image a -> String -> String -> IO ()
imageSetOption _obj key value =
   withObjectRef "imageSetOption" _obj $ \cobj ->
   withCWString key $ \cstr_key ->
   withCWString value $ \cstr_value ->
   wxImage_SetOption cobj cstr_key cstr_value
foreign import ccall "wxImage_SetOption" wxImage_SetOption ::
   Ptr (TImage a) -> CWString -> CWString -> IO ()

imageGetOption :: Image a -> String -> IO String
imageGetOption _obj key =
   withManagedStringResult $
   withObjectRef "imageGetOption" _obj $ \cobj ->
   withCWString key $ \cstr_key ->
   wxImage_GetOption cobj cstr_key
foreign import ccall "wxImage_GetOption" wxImage_GetOption ::
   Ptr (TImage a) -> CWString -> IO (Ptr (TWxString ()))


3) Points of confusion:

For return types of type String, looking at the examples in elj*.cpp,
why does it sometimes use copyStrToBuf to unpack the WxString on the
C++ side in combination with withWStringResult on the haskell side,
and other times just pass back the a freshly allocated WxString* from
C++ in combination with withManagedStringResult?

For arguments of object types, why do some bindings use withObjectPtr
and some use withObjectRef?

What's the EXWXEXPORT() macro for? It didn't seem very useful to me...

Thanks,

Jules