wxhaskell-users — General mailing list for wxhaskell users

[wxhaskell-users] Taskbar Icon

[Jinwoo L. <jin...@gm...>]

Hi,

I want to show an icon on the taskbar, and if a user clicks a right 
mouse button, display a menu.
How can I do this using wxHaskell?

I see that there is a TaskBarIcon type in the module 
Graphics.UI.WXCore.WxcClassTypes like this:
    type TaskBarIcon a = EvtHandler (CTaskBarIcon a)
        Pointer to an object of type TaskBarIcon, derived from EvtHandler.
    type TTaskBarIcon a = TEvtHandler (CTaskBarIcon a)
        Inheritance type of the TaskBarIcon class.
    data CTaskBarIcon a
        Abstract type of the TaskBarIcon class.

But I can't figure out how to use this.

Can someone shed me a light?

Thanks,

-- 
Jinwoo Lee
Always remember that you are unique.  Just like everyone else.
jin...@gm...

[wxhaskell-users] config problems on linux

[Jens P. <pet...@ha...>]

Hi,

I built and installed wxhaskell-0.9 with ghc-6.2.2
on both i386 and x86_64. :)

However when I try to build any of the samples/ programs
I see:

% cd wxhaskell-0.9/samples/wx
% ghc -package wx HelloWorld.hs
/usr/lib64/ghc-6.2.2/libwxc-gtk2.4.2-0.9.so: undefined reference to 
`wxGLCanvas::SwapBuffers()'
/usr/lib64/ghc-6.2.2/libwxc-gtk2.4.2-0.9.so: undefined reference to 
`wxGLCanvas::SetColour(char const*)'
/usr/lib64/ghc-6.2.2/libwxc-gtk2.4.2-0.9.so: undefined reference to 
`wxGLCanvas::wxGLCanvas(wxWindow*, wxGLCanvas const*, int, wxPoint const&, 
wxSize const&, long, wxString const&, int*, wxPalette const&)'
/usr/lib64/ghc-6.2.2/libwxc-gtk2.4.2-0.9.so: undefined reference to 
`wxGLCanvas::SetCurrent()'
/usr/lib64/ghc-6.2.2/libwxc-gtk2.4.2-0.9.so: undefined reference to 
`wxGLCanvas::wxGLCanvas(wxWindow*, int, wxPoint const&, wxSize const&, long, 
wxString const&, int*, wxPalette const&)'
collect2: ld returned 1 exit status

With "ghc -package wx -o helloworld HelloWorld.hs `wxgtk2-2.4-config --gl-libs`"
it links, but then running it:

% ./helloworld ./helloworld: error while loading shared libraries: 
libwxc-gtk2.4.2-0.9.so: cannot open shared object file: No such file or directory

Filtering out of my spec file, this is how I build wxHaskell:

   ./configure --libdir=/usr/lib/ghc-6.2.2
   make all
   make install

Also for your information on x86_64 wxHaskell needs to
be built with -fPIC.

I know these things are easy to fix, but I thought
I'd report them here first. :)

Jens

[wxhaskell-users] announce: wxhaskell 0.9

[Daan L. <da...@cs...>]

Announcement: wxHaskell version 0.9
----------------------------------------------------------------------

<http://wxhaskell.sourceforge.net>

I am pleased to announce a new release of wxHaskell.

This new release has support for the printing and much improved
support for processes and the grid control.

Binary installers are provided for MacOS X, Linux (RPM), and Windows,
for use with ghc 6.2.2.

Have fun,
  Daan Leijen.


----------------------------------------------------------------------
wxHaskell is a portable GUI library for Haskell. The goal of the
project is to provide an industrial strength portable GUI library, but
without the burden of developing (and maintaining) one ourselves.

wxHaskell is therefore build on top of wxWidgets -- a comprehensive
C++ library that is portable across all major GUI platforms; including
GTK, Windows, X11, and MacOS X. Furthermore, it is a mature library
(in development since 1992) that supports a wide range of widgets with
native look-and-feel, and it has a very active community (ranked among
the top 25 most active projects on sourceforge).

Since most of the interface is automatically generated from the
wxEiffel binding, the current release of wxHaskell already supports
about 75% of the wxWindows functionality -- about 2900 methods in 500
classes with 1400 constant definitions.

wxHaskell has been build with GHC 6.x on Windows, MacOS X and
Unix systems with GTK. A binary distribution is available for Windows,
Linux (RPM) and MacOS X.

And even if you don't intend to write GUI's yourself, it will be fun
to check out the screenshots at <http://wxhaskell.sourceforge.net>.


----------------------------------------------------------------------
Version 0.9
-------------
Non backward compatible changes:
- Changed "image" attribute to "picture"

Backward compatible additions:
- Added Multiple OpenGL Canvas example and fixed old example.
- Much improved process support in WXCore.Process. Use
   "processExecAsyncTimed" instead of "processExecASync".
- Full printing support in WXCore.Print
- Added SpintControl events.
- Fixed bug in MultiListBoxes where selections would only be
   added.
- Added "pixelBufferGetPixels" and "pixelBufferSetPixels" and
   according functions for images.
- Added "image" and made it an instance of the "Sized" class
   exported "imageCreateFromPixels" and "imageCreateFromPixelArray"
- Added "drawImage"
- Removed dependency on "readline" package in ghc 6.2.2
- Added "--cache" argument to configure script

Bug fixes:
- fixed "on command" event handlers in submenus.

[wxhaskell-users] paintraw and setting layout

[Patrick S. <mai...@st...>]

Hi,

Is it possible that the layout is a bit strange when you use the paintRaw 
event in one panel.
When I use a glCanvas window (and set the paintRaw event) I'm unable to make 
something like

layout := row 0 
	   [ floatLeft $ widget glField
	   , floatRight $ widget anotherPanel]
				
Everyone expects that the "anotherPanel" appears on the right side of the 
frame. What really happened is that the glField glCanvas window is drawn on
the left side of the frame and the anotherPanel (which only consists of a 
single button) is placed in the left upper corner too.
The button is drawn over the glField.

Could it be that the paintRaw event influences the behavior of the layout?

Cheers
Patrick

Re: [wxhaskell-users] Event handling for CalendarCtrl.

[Lemmih <le...@gm...>]

On Fri, 11 Feb 2005 14:38:41 +0100, Daan Leijen <da...@cs...> wrote:
> Lemmih wrote:
> > Greetings,
> >
> > I couldn't find CalendarCtrl event handling code in the src tree so
> > wrote my own. Note that I'm new to wx(Haskell/Widgets).
> 
> Hi Lemmih,
> 
> Great work! Thanks for you contribution -- I will integrate in
> the forthcoming 0.9 release.
> 
> Thanks again, I can hardly believe you are new Haskell!

New to wxHaskell, not Haskell (:

-- 
Friendly,
  Lemmih

Re: [wxhaskell-users] Event handling for CalendarCtrl.

[Daan L. <da...@cs...>]

Lemmih wrote:
> Greetings,
> 
> I couldn't find CalendarCtrl event handling code in the src tree so
> wrote my own. Note that I'm new to wx(Haskell/Widgets).

Hi Lemmih,

Great work! Thanks for you contribution -- I will integrate in
the forthcoming 0.9 release.

Thanks again, I can hardly believe you are new Haskell!

-- Daan.



> 
> [Graphics.UI.WX.Controls]
> calendarEvent :: Event (CalendarCtrl a) (EventCalendar -> IO ())
> calendarEvent
>   = newEvent "calendarEvent" calendarCtrlGetOnListEvent calendarCtrlOnListEvent
> 
> [Graphics.UI.WXCore.Events]
> data EventCalendar
>     = CalendarDayChanged (DateTime ())
>     | CalendarDoubleClicked (DateTime ())
>     | CalendarMonthChanged (DateTime ())
>     | CalendarSelectionChanged (DateTime ())
>     | CalendarWeekdayClicked Int
>     | CalendarYearChanged (DateTime ())
>     | CalendarUnknown
> 
> fromCalendarEvent :: CalendarEvent a -> IO EventCalendar
> fromCalendarEvent calEvent
>     = do tp <- eventGetEventType calEvent
>          case lookup tp calEvents of
>            Just f  -> f calEvent
>            Nothing -> return CalendarUnknown
> 
> calEvents :: [(Int, CalendarEvent a -> IO EventCalendar)]
> calEvents
>     = [(wxEVT_CALENDAR_DAY_CHANGED    ,withDate CalendarDayChanged)
>       ,(wxEVT_CALENDAR_DOUBLECLICKED  ,withDate CalendarDoubleClicked)
>       ,(wxEVT_CALENDAR_MONTH_CHANGED  ,withDate CalendarMonthChanged)
>       ,(wxEVT_CALENDAR_SEL_CHANGED    ,withDate CalendarSelectionChanged)
>       ,(wxEVT_CALENDAR_WEEKDAY_CLICKED,withWeekday CalendarWeekdayClicked)
>       ,(wxEVT_CALENDAR_YEAR_CHANGED   ,withDate CalendarYearChanged)]
>     where withDate event calEvent
>               = do date <- dateTimeCreate
>                    withObjectPtr date $ calendarEventGetDate calEvent
>                    return (event date)
>           withWeekday event calEvent
>               = fmap event $ calendarEventGetWeekDay calEvent
> 
> -- | Set a calendar event handler.
> calendarCtrlOnCalEvent :: CalendarCtrl a -> (EventCalendar -> IO ()) -> IO ()
> calendarCtrlOnCalEvent calCtrl eventHandler
>   = windowOnEvent calCtrl (map fst calEvents) eventHandler calHandler
>   where
>     calHandler event
>       = do eventCalendar <- fromCalendarEvent (objectCast event)
>            eventHandler eventCalendar
> 
> -- | Get the current calendar event handler of a window.
> calendarCtrlGetOnCalEvent :: CalendarCtrl a -> IO (EventCalendar -> IO ())
> calendarCtrlGetOnCalEvent calCtrl
>   = unsafeWindowGetHandlerState calCtrl wxEVT_CALENDAR_SEL_CHANGED
> (\event -> skipCurrentEvent)
> 

[wxhaskell-users] wxhaskell for new ghc-6.5...

[Patrick S. <mai...@st...>]

Hi to all,

for everyone who isn't involved a short summary:

I try to compile wxhaskell for a very new version of the ghc (the=20
night-release of the 06.02.2005) because the development of HOpenGl is gone=
=20
ahead and I want the new features.
wxhaskell-0.8 crashes when you try to compile. Hopefully just because of th=
e=20
changing options of the new ghc. I "fixed" some of the errors.

The first thing was a depency problem. Daan creates some depency files, her=
e a=20
cut-out from a mail I sent him:

> the thing is, that your call
>
> ghc -M file.o file.hs -optdep-f -optdep.dependfile
>
> doesn't work in the new ghc. You can fix this by touching the .dependfile
> first. ghc shows following behavior:
>
> old ghc versions created the .dependfile even when this file doesn't exis=
t.
> The newer version (06.02.2005) don't make it in that way. If the
> .dependfile doesn't exist they append it to the Makefile. If there isn't
> any Makefile the ghc does nothing!!!

But there were still errors..

> /usr/local/bin/ghc-6.5.20050206 -c wxdirect/src/CompileDefs.hs -o
> out/wxdirect/CompileDefs.o -ohi out/wxdirect/CompileDefs.hi -odir
> out/wxdirect/  -package parsec -iout/wxdirect
> Could not find module `ParseEiffel':
>   use -v to see a list of the files searched for
>   (imported from wxdirect/src/CompileDefs.hs)
> make: *** [out/wxdirect/CompileDefs.o] Fehler 1
>
> Don't get confused. I'm very sure that this error comes from the ghc -M
> call and not from that above. Later I put the -M call in the "nonsilent"
> mode. It seems that ghcs searchpath is probably incorrect.=20

I tested a bit around. When the makefile calls the ghc from outside the=20
directory it can't find out the depending modules. So the "ghc -M" call=20
prints this error.
I looked around and saw that the makefile is divided into 3 sections. The w=
x,=20
wxcore and wxd or something like that. I took the variables (WXfoobar-SRCDI=
R)=20
and added them to the searchpath of every "make-hs" call.
That fixed the error problem.

I have the slightly feeling that anyhow somethings are going wrong. The fir=
st=20
one is, that the opengl lib doesn't want to get compiled.. (I added some=20
extra printouts!)

ghc -iout/wxcore/imports/Graphics/UI/WXCore=20
wxcore/src/Graphics/UI/WXCore/OpenGL.hs  -fvia-C -package-name wxcore=20
=2Diout/wxcore/imports:wxcore/src -Iwxc/include -M -optdep-f=20
=2Doptdepout/wxcore/imports/Graphics/UI/WXCore/OpenGL.d.in && sed -e=20
's|wxcore/src/Graphics/UI/WXCore/OpenGL|out/wxcore/imports/Graphics/UI/WXCo=
re/OpenGL|'=20
=2De 's|\.hi|\.o|g' out/wxcore/imports/Graphics/UI/WXCore/OpenGL.d.in >=20
out/wxcore/imports/Graphics/UI/WXCore/OpenGL.d
make: *** Keine Regel vorhanden, um das Target=20
=BBwxcore/src/Graphics/UI/WXCore/OpenGL.o=AB,
  ben=F6tigt von =BBout/wxcore/imports/Graphics/UI/WXCore.o=AB, zu erstelle=
n. =20
Schluss.

When I compile it without it than i runs through without errors. When I swi=
tch=20
to root to make install the compiling process starts again (ends with=20
failure) and I have no idea why.

Anyhow I tried to compile as root and the install process started correctly=
=20
and ends up with a error from the ghc-pkg programm.
It wants a colon after the first line in the wxcore.pkg.

I hope there are people who are also interested in wx for new ghc and who h=
ave=20
had a closer look to the makefile and the source (not like me:).
I have no idea what I should try next.

Cheers
Patrick

[wxhaskell-users] Event handling for CalendarCtrl.

[Lemmih <le...@gm...>]

Greetings,

I couldn't find CalendarCtrl event handling code in the src tree so
wrote my own. Note that I'm new to wx(Haskell/Widgets).

[Graphics.UI.WX.Controls]
calendarEvent :: Event (CalendarCtrl a) (EventCalendar -> IO ())
calendarEvent
  = newEvent "calendarEvent" calendarCtrlGetOnListEvent calendarCtrlOnListEvent

[Graphics.UI.WXCore.Events]
data EventCalendar
    = CalendarDayChanged (DateTime ())
    | CalendarDoubleClicked (DateTime ())
    | CalendarMonthChanged (DateTime ())
    | CalendarSelectionChanged (DateTime ())
    | CalendarWeekdayClicked Int
    | CalendarYearChanged (DateTime ())
    | CalendarUnknown

fromCalendarEvent :: CalendarEvent a -> IO EventCalendar
fromCalendarEvent calEvent
    = do tp <- eventGetEventType calEvent
         case lookup tp calEvents of
           Just f  -> f calEvent
           Nothing -> return CalendarUnknown

calEvents :: [(Int, CalendarEvent a -> IO EventCalendar)]
calEvents
    = [(wxEVT_CALENDAR_DAY_CHANGED    ,withDate CalendarDayChanged)
      ,(wxEVT_CALENDAR_DOUBLECLICKED  ,withDate CalendarDoubleClicked)
      ,(wxEVT_CALENDAR_MONTH_CHANGED  ,withDate CalendarMonthChanged)
      ,(wxEVT_CALENDAR_SEL_CHANGED    ,withDate CalendarSelectionChanged)
      ,(wxEVT_CALENDAR_WEEKDAY_CLICKED,withWeekday CalendarWeekdayClicked)
      ,(wxEVT_CALENDAR_YEAR_CHANGED   ,withDate CalendarYearChanged)]
    where withDate event calEvent
              = do date <- dateTimeCreate
                   withObjectPtr date $ calendarEventGetDate calEvent
                   return (event date)
          withWeekday event calEvent
              = fmap event $ calendarEventGetWeekDay calEvent

-- | Set a calendar event handler.
calendarCtrlOnCalEvent :: CalendarCtrl a -> (EventCalendar -> IO ()) -> IO ()
calendarCtrlOnCalEvent calCtrl eventHandler
  = windowOnEvent calCtrl (map fst calEvents) eventHandler calHandler
  where
    calHandler event
      = do eventCalendar <- fromCalendarEvent (objectCast event)
           eventHandler eventCalendar

-- | Get the current calendar event handler of a window.
calendarCtrlGetOnCalEvent :: CalendarCtrl a -> IO (EventCalendar -> IO ())
calendarCtrlGetOnCalEvent calCtrl
  = unsafeWindowGetHandlerState calCtrl wxEVT_CALENDAR_SEL_CHANGED
(\event -> skipCurrentEvent)

-- 
Friendly,
  Lemmih

Re: [wxhaskell-users] Multiple GL Canvases

[Georg M. <mai...@st...>]

On Tue, 08 Feb 2005 20:10:08 +0100, Daan Leijen <da...@cs...> wrote:

>>> However, the printing support refers only at the moment to just norma=
l
>>> printing. I have not studied Postscript devices yet... Isn't it
>>> always possible to just select a postscript printer and print to file=
?
>>> Or do you have something special in mind?
>>
>>
>> perhaps I'm misunderstanding something here. It's been a while since
>> I looked into this, but when I wanted a way to convert the graphs I
>> draw on wxWidgets to print in scalable form, the way to go seemed to
>> be to create a Postscript context and pass that to the normal repaint
>> function, so that it would draw in Postscript commands instead of on
>> the screen. Seemed almost too easy, only that I couldn't find a way to
>> create such things in wxHaskell.
>
> I added support for drawing onto printer device contexts. This means
> that you have printer support -- a user gets a printer dialog etc. and
> can print, while the haskell code just draws to a DC -- either the
> screen or a printer. On windows, I can simply select a postscript
> printer and print to a file to get postscript output.
>
> However, I have not added specific support for getting postscript
> output directly, even though I can vagelue remember that wxWidgets
> has such support -- if I find time, I'll look into it, but I am
> hoping that also on unix, one can emulate this behaviour by selecting
> a postscript printer and printing to file.

On unix it is even more natural to print to a file in postscript format. =
However, the question is how the content is represented for printing. I'a=
m not sure whether the content of the DC in wx is sent to the printer as =
a bitmap or as vector graphics. The latter would be certainly prefered fo=
r ps-files.

  Georg

Re: [wxhaskell-users] Multiple GL Canvases

[Daan L. <da...@cs...>]

>>However, the printing support refers only at the moment to just normal
>>printing. I have not studied Postscript devices yet... Isn't it
>>always possible to just select a postscript printer and print to file?
>>Or do you have something special in mind?
> 
> 
> perhaps I'm misunderstanding something here. It's been a while since
> I looked into this, but when I wanted a way to convert the graphs I
> draw on wxWidgets to print in scalable form, the way to go seemed to 
> be to create a Postscript context and pass that to the normal repaint 
> function, so that it would draw in Postscript commands instead of on
> the screen. Seemed almost too easy, only that I couldn't find a way to 
> create such things in wxHaskell.

I added support for drawing onto printer device contexts. This means
that you have printer support -- a user gets a printer dialog etc. and
can print, while the haskell code just draws to a DC -- either the
screen or a printer. On windows, I can simply select a postscript 
printer and print to a file to get postscript output.

However, I have not added specific support for getting postscript
output directly, even though I can vagelue remember that wxWidgets
has such support -- if I find time, I'll look into it, but I am
hoping that also on unix, one can emulate this behaviour by selecting
a postscript printer and printing to file.

-- Daan.

Re: [wxhaskell-users] Multiple GL Canvases

[Claus R. <cla...@ta...>]

> Yes!! The cvs contains a brand new process handler which seems
> much more stable. I am currently testing on macOSX and Linux boxes.
> Since there will be a new release of Helium sometime soon with a
> wxHint interface, we desparetely needed a better process handler here :-)

Great!-) instable Haskell programs are always somewhat embarrasing,
even if one can blame external sources.

> However, the printing support refers only at the moment to just normal
> printing. I have not studied Postscript devices yet... Isn't it
> always possible to just select a postscript printer and print to file?
> Or do you have something special in mind?

perhaps I'm misunderstanding something here. It's been a while since
I looked into this, but when I wanted a way to convert the graphs I
draw on wxWidgets to print in scalable form, the way to go seemed to 
be to create a Postscript context and pass that to the normal repaint 
function, so that it would draw in Postscript commands instead of on
the screen. Seemed almost too easy, only that I couldn't find a way to 
create such things in wxHaskell.

I don't have a Postscript printer, I just want the eps in vector form, not 
bitmap, for embedding in papers and the like. How does the printer 
support you're talking about work, then?

Claus

> > ps is the sourceforge bug tracker maintained/up to date? it seems 
> >     to list mostly bugs in older releases, but neither printing nor
> >     Process problems.
> 
> Ehm, no it is not. I do not get emails from it and I don't quite
> understand how to manage it... I'll try to look into that.

:-)

Re: [wxhaskell-users] Multiple GL Canvases

[Daan L. <da...@cs...>]

Claus Reinke wrote:
> I had the nagging feeling that printing was not the only outstanding 
> issue, but a quick scan through my inbox only brought up one other 
> critical point (assuming that printer support refers to  Postscript device 
> contexts), namely the instability of Graphics.UI.WXCore.Process - 
> any progress on this front?

Yes!! The cvs contains a brand new process handler which seems
much more stable. I am currently testing on macOSX and Linux boxes.
Since there will be a new release of Helium sometime soon with a
wxHint interface, we desparetely needed a better process handler here :-)

However, the printing support refers only at the moment to just normal
printing. I have not studied Postscript devices yet... Isn't it
always possible to just select a postscript printer and print to file?
Or do you have something special in mind?

-- Daan.

> ps is the sourceforge bug tracker maintained/up to date? it seems 
>     to list mostly bugs in older releases, but neither printing nor
>     Process problems.

Ehm, no it is not. I do not get emails from it and I don't quite
understand how to manage it... I'll try to look into that.


> 
> 
> 

Re: [wxhaskell-users] Multiple GL Canvases

[Claus R. <cla...@ta...>]

> I am currently gearing up for the wxHaskell 0.9 release this week (?) 
> (with great printer support :-)  so if anyone has good samples or 
> suggestions, please tell me so.

I had the nagging feeling that printing was not the only outstanding 
issue, but a quick scan through my inbox only brought up one other 
critical point (assuming that printer support refers to  Postscript device 
contexts), namely the instability of Graphics.UI.WXCore.Process - 
any progress on this front?

Cheers,
Claus

ps is the sourceforge bug tracker maintained/up to date? it seems 
    to list mostly bugs in older releases, but neither printing nor
    Process problems.
     

Re: [wxhaskell-users] Porting wxScintilla to wxHaskell

[Daan L. <da...@cs...>]

David Waern wrote:
> be really happy. We have tried to contact Daan Leijen, but he seems to be 
> a busy man :)

Hi David,

Well, I was mostly busy with my snowboard in the French Alps the past 
week :-)  Sorry for not replying earlier.

 > We are a group of students at Chalmers doing a project with the aim of
 > building an IDE for Haskell written in Haskell. We would like to use
 > the Scintilla widget together with wxHaskell to do this, so now we are
 > trying to make a proper wxHaskell binding for Scintilla.

It is a long-time wish for me to have the scintilla control as part
of wxHaskell and it would be great if someone would do this!
The scintilla editor is really a great tool.

Anyway, I see two problems, uhh, challenges I mean:

1) The component uses its own protocol to call methods
2) The component uses its own protocol to send events

So, first of all, I think it is necessary for you to run
a basic C++ wxWidgets sample with wxScintilla. Next, you need
to somehow make a "C" wrapper (in wxc) for some scintilla methods
and add the signatures to the "wxc.h" header file (so they get
marshalled by wxDirect). Furthermore, I think it would be much
better if you use the wxWidgets standard event model. Actually,
you can see how you can make custom events by looking at the
"wxcHtmlEvent" class in the "wxc/src/extra.cpp" file (this is
all a bit of mess, so carefully navigate aroung :-)

Well, I hope this helps you to get started, feel free to
write to me personally to get more help -- I would really like
to see scintilla as part of wxHaskell.

-- Daan.

Re: [wxhaskell-users] Multiple GL Canvases

[Daan L. <da...@cs...>]

Patrick Scheibe wrote:
> PS @developers: I have updated my cvs and THE ONE glSample is just the (non 
> running) same. Will anyone make a fix on this sample so everybody can have a  
> running one. If nobody will have time to to this I can send a fixed version. 
> Interested??

Hi Patrick,

Please send me your GL samples and I will include them!
I don't know anything about openGL and have never gotten it to work
on my system, so all help is highly appreciated. I am currently gearing
up for the wxHaskell 0.9 release this week (?) (with great printer 
support :-)  so if anyone has good samples or suggestions, please tell
me so.

-- Daan.

> 
> 
> <Code>
> module Main
> where
>     
> import Data.List ( transpose )
> import Graphics.UI.WX
> import Graphics.UI.WXCore
> import Graphics.Rendering.OpenGL
> -- Many code and Type are ambiguous, so we must qualify names.
> import qualified Graphics.UI.WX as WX
> import qualified Graphics.Rendering.OpenGL as GL
> 
> main :: IO()
> main = start gui
> 
> 
> defaultWidth  = 320
> defaultHeight = 200
> 
> gui = do
>    f <- frame [ text := "Simple OpenGL" ]
> 
> -- We just create two glCanvas
> 
>    glCanvas <- glCanvasCreateEx f 0 (Rect 0 0 defaultWidth defaultHeight)
>         0 "GLCanvas" [GL_RGBA] nullPalette
>    glCanvas2 <- glCanvasCreateEx f 0 (Rect 0 0 defaultWidth defaultHeight)
>         0 "GLCanvas" [GL_RGBA] nullPalette
> 
>    let glWidgetLayout = fill $ row 5 [widget glCanvas2,  widget glCanvas]
> 
> -- Hint: You have to use the paintRaw event. For switching between the two
> --   glwindows you can give both of them as parameter
>    WX.set f [ layout := glWidgetLayout
>             , on paintRaw := paintGL glCanvas glCanvas2
>             ]
> 
> 
> convWG (WX.Size w h) = (GL.Size (convInt32  w) (convInt32  h))
> convInt32 = fromInteger . toInteger
> 
> paintGL :: GLCanvas a -> GLCanvas a -> DC() -> WX.Rect -> [WX.Rect]-> IO ()
> paintGL gl1 gl2 dc myrect _ = do
> 
> -- Now we switch to the first one
> -- and do all init and painting stuff
> -- Hint: I changed the backgroundcolor for clearance
> 
>    glCanvasSetCurrent gl1
>    myInit
>    reshape $ convWG $ rectSize myrect
>    -- Or not reshape the size.
>    reshape (GL.Size 320 200)
>    GL.clearColor GL.$= GL.Color4 1 0 0 0
>    display
>    glCanvasSwapBuffers gl1
> 
> -- All the same for the second one
>    glCanvasSetCurrent gl2
>    myInit
>    reshape $ convWG $ rectSize myrect
>    -- Or not reshape the size.
>    reshape (GL.Size 320 200)
>    GL.clearColor GL.$= GL.Color4 0 2 0 0
>    display
>    glCanvasSwapBuffers gl2
>    return ()
> 
> 
> ctrlPoints :: [[GL.Vertex3 GL.GLfloat]]
> ctrlPoints = [
>    [ GL.Vertex3 (-1.5) (-1.5)   4.0,  GL.Vertex3 (-0.5) (-1.5)   2.0,
>      GL.Vertex3   0.5  (-1.5) (-1.0), GL.Vertex3   1.5  (-1.5)   2.0 ],
>    [ GL.Vertex3 (-1.5) (-0.5)   1.0,  GL.Vertex3 (-0.5) (-0.5)   3.0,
>      GL.Vertex3   0.5  (-0.5)   0.0,  GL.Vertex3   1.5  (-0.5) (-1.0) ],
>    [ GL.Vertex3 (-1.5)   0.5    4.0,  GL.Vertex3 (-0.5)   0.5    0.0,
>      GL.Vertex3   0.5    0.5    3.0,  GL.Vertex3   1.5    0.5    4.0 ],
>    [ GL.Vertex3 (-1.5)   1.5  (-2.0), GL.Vertex3 (-0.5)   1.5  (-2.0),
>      GL.Vertex3   0.5    1.5    0.0,  GL.Vertex3   1.5    1.5  (-1.0) ]]
> 
> initlights :: IO ()
> initlights = do
>    GL.lighting GL.$= GL.Enabled
>    GL.light (GL.Light 0) GL.$= GL.Enabled
> 
>    GL.ambient  (GL.Light 0) GL.$= GL.Color4 0.2 0.2 0.2 1.0
>    GL.position (GL.Light 0) GL.$= GL.Vertex4 0 0 2 1
> 
>    GL.materialDiffuse   GL.Front GL.$= GL.Color4 0.6 0.6 0.6 1.0
>    GL.materialSpecular  GL.Front GL.$= GL.Color4 1.0 1.0 1.0 1.0
>    GL.materialShininess GL.Front GL.$= 50
> 
> myInit :: IO ()
> myInit = do
> --   GL.clearColor GL.$= GL.Color4 1 0 0 0
>    GL.depthFunc GL.$= Just GL.Less
>    m <- GL.newMap2 (0, 1) (0, 1) (transpose ctrlPoints)
>    GL.map2 GL.$= Just (m :: GLmap2 GL.Vertex3 GL.GLfloat)
>    GL.autoNormal GL.$= GL.Enabled
>    mapGrid2 GL.$= ((20, (0, 1)), (20, (0, 1 :: GL.GLfloat)))
>    initlights  -- for lighted version only
> 
> display = do
>    GL.clear [ GL.ColorBuffer, GL.DepthBuffer ]
>    GL.preservingMatrix $ do
>      GL.rotate (85 :: GL.GLfloat) (GL.Vector3 1 1 1)
>      evalMesh2 Fill (0, 20) (0, 20)
>    GL.flush
> 
> reshape mysize@(GL.Size w h) = do
>    GL.viewport GL.$= (GL.Position 0 0, mysize)
>    GL.matrixMode GL.$= GL.Projection
>    GL.loadIdentity
>    let wf = fromIntegral w
>        hf = fromIntegral h
>    if w <= h
>       then GL.ortho (-4.0) 4.0 (-4.0*hf/wf) (4.0*hf/wf) (-4.0) 4.0
>       else GL.ortho (-4.0*wf/hf) (4.0*wf/hf) (-4.0) 4.0 (-4.0) 4.0
>    GL.matrixMode GL.$= GL.Modelview 0
>    GL.loadIdentity
> 
> 
> 
> </Code>
> 
> 
> 
> On Sunday 30 January 2005 21:44, Jan Rochel wrote:
> 
>>Hello.
>>
>>I can't get a program using multiple GLCanvases working properly.
>>The first canvas in the first (MDIChild)Frame works perfectly fine,
>>but the second GLCanvas that is created (in another (MDIChild)Frame) is
>>just black. Trying out several things with glCanvasSetCurrent didn't
>>help. Could anybody please provide some example program that uses two
>>GLCanvases at the same time? This is quite important to me.
>>
>>Thanks
>>Jan
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
>>Tool for open source databases. Create drag-&-drop reports. Save time
>>by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
>>Download a FREE copy at http://www.intelliview.com/go/osdn_nl
>>_______________________________________________
>>wxhaskell-users mailing list
>>wxh...@li...
>>https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
>>
>>
>> ------------------------------------------------------------------------
>>

[wxhaskell-users] Porting wxScintilla to wxHaskell

[David W. <da...@dt...>]

Hi!
	 
We are a group of students at Chalmers doing a project with the aim of
building an IDE for Haskell written in Haskell. We would like to use the
Scintilla widget together with wxHaskell to do this, so now we are trying
to make a proper wxHaskell binding for Scintilla. Any advice on how to do
this would be really appreciated. More specifically, we are struggling
with the problem of how to design the event handling. Should it be done 
via the event handler system of wxcore or should we roll on our own 
stuff? The backend of wxcore is a pretty complicated beast, but using
it would mean not having to do that much hacking in wxdirect. Atleast that's
what we think. If someone with more insight would like to comment we would
be really happy. We have tried to contact Daan Leijen, but he seems to be 
a busy man :)
 
David Waern 

Re: [wxhaskell-users] Multiple GL Canvases

[Patrick S. <mai...@st...>]

Hi there, 

The one important thing is, that the gl commands are sent to the actual 
gldevice context. To set the actual context you have to use 
glCanvasSetCurrent.

So when you want two gl windows just do it and befor drawing in one switch the 
contex to this one.

Here is the modified GlCanvas.hs from the sample directory the should answer 
all your questions.

Cheers
Patrick

PS @developers: I have updated my cvs and THE ONE glSample is just the (non 
running) same. Will anyone make a fix on this sample so everybody can have a  
running one. If nobody will have time to to this I can send a fixed version. 
Interested??


<Code>
module Main
where
    
import Data.List ( transpose )
import Graphics.UI.WX
import Graphics.UI.WXCore
import Graphics.Rendering.OpenGL
-- Many code and Type are ambiguous, so we must qualify names.
import qualified Graphics.UI.WX as WX
import qualified Graphics.Rendering.OpenGL as GL

main :: IO()
main = start gui


defaultWidth  = 320
defaultHeight = 200

gui = do
   f <- frame [ text := "Simple OpenGL" ]

-- We just create two glCanvas

   glCanvas <- glCanvasCreateEx f 0 (Rect 0 0 defaultWidth defaultHeight)
        0 "GLCanvas" [GL_RGBA] nullPalette
   glCanvas2 <- glCanvasCreateEx f 0 (Rect 0 0 defaultWidth defaultHeight)
        0 "GLCanvas" [GL_RGBA] nullPalette

   let glWidgetLayout = fill $ row 5 [widget glCanvas2,  widget glCanvas]

-- Hint: You have to use the paintRaw event. For switching between the two
--   glwindows you can give both of them as parameter
   WX.set f [ layout := glWidgetLayout
            , on paintRaw := paintGL glCanvas glCanvas2
            ]


convWG (WX.Size w h) = (GL.Size (convInt32  w) (convInt32  h))
convInt32 = fromInteger . toInteger

paintGL :: GLCanvas a -> GLCanvas a -> DC() -> WX.Rect -> [WX.Rect]-> IO ()
paintGL gl1 gl2 dc myrect _ = do

-- Now we switch to the first one
-- and do all init and painting stuff
-- Hint: I changed the backgroundcolor for clearance

   glCanvasSetCurrent gl1
   myInit
   reshape $ convWG $ rectSize myrect
   -- Or not reshape the size.
   reshape (GL.Size 320 200)
   GL.clearColor GL.$= GL.Color4 1 0 0 0
   display
   glCanvasSwapBuffers gl1

-- All the same for the second one
   glCanvasSetCurrent gl2
   myInit
   reshape $ convWG $ rectSize myrect
   -- Or not reshape the size.
   reshape (GL.Size 320 200)
   GL.clearColor GL.$= GL.Color4 0 2 0 0
   display
   glCanvasSwapBuffers gl2
   return ()


ctrlPoints :: [[GL.Vertex3 GL.GLfloat]]
ctrlPoints = [
   [ GL.Vertex3 (-1.5) (-1.5)   4.0,  GL.Vertex3 (-0.5) (-1.5)   2.0,
     GL.Vertex3   0.5  (-1.5) (-1.0), GL.Vertex3   1.5  (-1.5)   2.0 ],
   [ GL.Vertex3 (-1.5) (-0.5)   1.0,  GL.Vertex3 (-0.5) (-0.5)   3.0,
     GL.Vertex3   0.5  (-0.5)   0.0,  GL.Vertex3   1.5  (-0.5) (-1.0) ],
   [ GL.Vertex3 (-1.5)   0.5    4.0,  GL.Vertex3 (-0.5)   0.5    0.0,
     GL.Vertex3   0.5    0.5    3.0,  GL.Vertex3   1.5    0.5    4.0 ],
   [ GL.Vertex3 (-1.5)   1.5  (-2.0), GL.Vertex3 (-0.5)   1.5  (-2.0),
     GL.Vertex3   0.5    1.5    0.0,  GL.Vertex3   1.5    1.5  (-1.0) ]]

initlights :: IO ()
initlights = do
   GL.lighting GL.$= GL.Enabled
   GL.light (GL.Light 0) GL.$= GL.Enabled

   GL.ambient  (GL.Light 0) GL.$= GL.Color4 0.2 0.2 0.2 1.0
   GL.position (GL.Light 0) GL.$= GL.Vertex4 0 0 2 1

   GL.materialDiffuse   GL.Front GL.$= GL.Color4 0.6 0.6 0.6 1.0
   GL.materialSpecular  GL.Front GL.$= GL.Color4 1.0 1.0 1.0 1.0
   GL.materialShininess GL.Front GL.$= 50

myInit :: IO ()
myInit = do
--   GL.clearColor GL.$= GL.Color4 1 0 0 0
   GL.depthFunc GL.$= Just GL.Less
   m <- GL.newMap2 (0, 1) (0, 1) (transpose ctrlPoints)
   GL.map2 GL.$= Just (m :: GLmap2 GL.Vertex3 GL.GLfloat)
   GL.autoNormal GL.$= GL.Enabled
   mapGrid2 GL.$= ((20, (0, 1)), (20, (0, 1 :: GL.GLfloat)))
   initlights  -- for lighted version only

display = do
   GL.clear [ GL.ColorBuffer, GL.DepthBuffer ]
   GL.preservingMatrix $ do
     GL.rotate (85 :: GL.GLfloat) (GL.Vector3 1 1 1)
     evalMesh2 Fill (0, 20) (0, 20)
   GL.flush

reshape mysize@(GL.Size w h) = do
   GL.viewport GL.$= (GL.Position 0 0, mysize)
   GL.matrixMode GL.$= GL.Projection
   GL.loadIdentity
   let wf = fromIntegral w
       hf = fromIntegral h
   if w <= h
      then GL.ortho (-4.0) 4.0 (-4.0*hf/wf) (4.0*hf/wf) (-4.0) 4.0
      else GL.ortho (-4.0*wf/hf) (4.0*wf/hf) (-4.0) 4.0 (-4.0) 4.0
   GL.matrixMode GL.$= GL.Modelview 0
   GL.loadIdentity



</Code>



On Sunday 30 January 2005 21:44, Jan Rochel wrote:
> Hello.
>
> I can't get a program using multiple GLCanvases working properly.
> The first canvas in the first (MDIChild)Frame works perfectly fine,
> but the second GLCanvas that is created (in another (MDIChild)Frame) is
> just black. Trying out several things with glCanvasSetCurrent didn't
> help. Could anybody please provide some example program that uses two
> GLCanvases at the same time? This is quite important to me.
>
> Thanks
> Jan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> wxhaskell-users mailing list
> wxh...@li...
> https://lists.sourceforge.net/lists/listinfo/wxhaskell-users

[wxhaskell-users] Multiple GL Canvases

[<jan...@t-...>]

Hello.

I can't get a program using multiple GLCanvases working properly.
The first canvas in the first (MDIChild)Frame works perfectly fine,
but the second GLCanvas that is created (in another (MDIChild)Frame) is
just black. Trying out several things with glCanvasSetCurrent didn't
help. Could anybody please provide some example program that uses two
GLCanvases at the same time? This is quite important to me.

Thanks
Jan

Re: [wxhaskell-users] Some Contributed Sample uses Old function

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

This chage have a mistake here.
I think this mistake effect enable to edit log box.

textlog <- textCtrl p [wrap := WrapLine, enabled := False]

On Fri, 21 Jan 2005 20:41:27 +0900, shelarcy  
<she...@ca...> wrote:
> NotebookRight uses WrapLine old way, so I changed
>
> textlog <- textCtrl p [wrap := WrapLine]


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

[wxhaskell-users] Some Contributed Sample uses Old function

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

Hi.
I tested some contributed samples a few month ago, and
I knew some samples doesn't work becase, some sample
uses old function or old way,
I changed some sample to able to work.

PaintDirect uses size, this is ambgious function name
bettween WXCore or Graphics.UI.WX.Classes. So I chage
to use sz.

NotebookRight uses WrapLine old way, so I changed

textlog <- textCtrl p [wrap := WrapLine]

But NotebookRight sample is not work on Windows 2000.
Ok, I knew this, first time (this sample was added)
I tested this sample doen't work Windows 2000.

This problem's reson is Windows 2000 doen't support
some Windows XP's new API. So NotebookRights doen't
call this API.

So I want to know that somebody else success to run
this sample other plattform?


71756AA0  cmp         dword ptr [edx+28h],eax

> 	comctl32.dll!71756aa0() 	
  	comctl32.dll!71756b25() 	
  	comctl32.dll!7171469b() 	
  	comctl32.dll!71714846() 	
  	comctl32.dll!71714867() 	
  	comctl32.dll!71714f35() 	
  	comctl32.dll!71713665() 	
  	NTDLL.DLL!77f82a8c() 	
  	USER32.DLL!77e0a420() 	
  	USER32.DLL!77de6b41() 	
  	USER32.DLL!77de6b64() 	
  	wxc-msw2.4.2-0.8.dll!10061957() 	
  	wxc-msw2.4.2-0.8.dll!10062683() 	
  	USER32.DLL!77dea366() 	
  	wxc-msw2.4.2-0.8.dll!100740e8() 	
  	wxc-msw2.4.2-0.8.dll!1008350a() 	
  	wxc-msw2.4.2-0.8.dll!10062a51() 	
  	wxc-msw2.4.2-0.8.dll!10061de7() 	
  	USER32.DLL!77e0a420() 	
  	USER32.DLL!77de4750() 	
  	USER32.DLL!77de55b0() 	
  	NTDLL.DLL!77f9ff57() 	
  	USER32.DLL!77de63e1() 	
  	USER32.DLL!77de68c4() 	
  	wxc-msw2.4.2-0.8.dll!1006a2c7() 	
  	wxc-msw2.4.2-0.8.dll!100d212b() 	
  	wxc-msw2.4.2-0.8.dll!100d12a2() 	
  	msvcrt.dll!780014cf() 	
  	wxc-msw2.4.2-0.8.dll!100d08cd() 	
  	wxc-msw2.4.2-0.8.dll!100d1b13() 	
  	wxc-msw2.4.2-0.8.dll!100d12a2() 	
  	msvcrt.dll!780014cf() 	
  	wxc-msw2.4.2-0.8.dll!100d08cd() 	
  	wxc-msw2.4.2-0.8.dll!100d1b13() 	
  	wxc-msw2.4.2-0.8.dll!100d1122() 	
  	wxc-msw2.4.2-0.8.dll!1006711a() 	
  	wxc-msw2.4.2-0.8.dll!100d1281() 	
  	wxc-msw2.4.2-0.8.dll!10067efd() 	
  	wxc-msw2.4.2-0.8.dll!1005fe61() 	
  	wxc-msw2.4.2-0.8.dll!100327af() 	
  	wxc-msw2.4.2-0.8.dll!1003269c() 	
  	wxc-msw2.4.2-0.8.dll!10064308() 	
  	wxc-msw2.4.2-0.8.dll!10061ecd() 	
  	USER32.DLL!77dea366() 	
  	wxc-msw2.4.2-0.8.dll!100740e8() 	
  	wxc-msw2.4.2-0.8.dll!1008350a() 	
  	wxc-msw2.4.2-0.8.dll!10062a51() 	
  	wxc-msw2.4.2-0.8.dll!10061de7() 	
  	USER32.DLL!77e0a420() 	
  	USER32.DLL!77de4750() 	
  	USER32.DLL!77de55b0() 	
  	NTDLL.DLL!77f9ff57() 	
  	USER32.DLL!77de6407() 	
  	USER32.DLL!77de4c3a() 	
  	USER32.DLL!77de479a() 	
  	wxc-msw2.4.2-0.8.dll!10061970() 	
  	wxc-msw2.4.2-0.8.dll!10062683() 	
  	USER32.DLL!77dea366() 	
  	wxc-msw2.4.2-0.8.dll!100740e8() 	
  	wxc-msw2.4.2-0.8.dll!1008350a() 	
  	wxc-msw2.4.2-0.8.dll!10062a51() 	
  	wxc-msw2.4.2-0.8.dll!10061de7() 	
  	USER32.DLL!77e0a420() 	
  	USER32.DLL!77de4750() 	
  	USER32.DLL!77de74d4() 	
  	NTDLL.DLL!77f9ff57() 	
  	wxc-msw2.4.2-0.8.dll!100614df() 	
  	wxc-msw2.4.2-0.8.dll!10061605() 	
  	wxc-msw2.4.2-0.8.dll!100d0aeb() 	
  	wxc-msw2.4.2-0.8.dll!100d16fe() 	
  	wxc-msw2.4.2-0.8.dll!100d1a61() 	
  	wxc-msw2.4.2-0.8.dll!100d1129() 	
  	wxc-msw2.4.2-0.8.dll!100d1281() 	
  	wxc-msw2.4.2-0.8.dll!10067efd() 	
  	wxc-msw2.4.2-0.8.dll!100a679b() 	
  	wxc-msw2.4.2-0.8.dll!100327af() 	
  	wxc-msw2.4.2-0.8.dll!1003269c() 	
  	wxc-msw2.4.2-0.8.dll!10064308() 	
  	wxc-msw2.4.2-0.8.dll!100b1bc0() 	
  	wxc-msw2.4.2-0.8.dll!100b1e19() 	
  	wxc-msw2.4.2-0.8.dll!10062a51() 	
  	wxc-msw2.4.2-0.8.dll!10061de7() 	
  	USER32.DLL!77e0a420() 	
  	USER32.DLL!77de4750() 	
  	USER32.DLL!77de55b0() 	
  	NTDLL.DLL!77f9ff57() 	
  	USER32.DLL!77de6407() 	
  	USER32.DLL!77de4c3a() 	
  	USER32.DLL!77de479a() 	
  	wxc-msw2.4.2-0.8.dll!10061970() 	
  	wxc-msw2.4.2-0.8.dll!10062683() 	
  	wxc-msw2.4.2-0.8.dll!10061f73() 	
  	wxc-msw2.4.2-0.8.dll!10061f73() 	
  	USER32.DLL!77dea366() 	
  	wxc-msw2.4.2-0.8.dll!100b1f08() 	
  	wxc-msw2.4.2-0.8.dll!10062a51() 	
  	wxc-msw2.4.2-0.8.dll!10061de7() 	
  	USER32.DLL!77e0a420() 	
  	USER32.DLL!77de4750() 	
  	USER32.DLL!77de74d4() 	
  	NTDLL.DLL!77f9ff57() 	
  	wxc-msw2.4.2-0.8.dll!100614df() 	
  	wxc-msw2.4.2-0.8.dll!100616da() 	
  	wxc-msw2.4.2-0.8.dll!100b11f5() 	
  	wxc-msw2.4.2-0.8.dll!10023006() 	
  	main.exe!005fcf17() 	

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

Re: [wxhaskell-users] GLCanvas doesn't work

[Patrick S. <mai...@st...>]

Hi to all,

My application runs fine. I think I have found the problem but it could 
probably be something more.

Here are some hints relating to the (old) GlCanvas.hs sample from the source.

1. I use glCanvasSetCurrent as first command in the opengl display function
and before doing any gl commands. This seems to be nesassary and is done in 
every wxGTK sample. 

2. You have to do a glCanvasSwapBuffers at the end of the display function.
Because I thing thinks like doublebuffering are done by the gui and every 
animated thing use doublebuffers.

3. The third hint is probably the most important. The on paintRaw is a bit 
different from the on paint event (yes, it have to.. :-). I think the one big 
difference is that it doesn't clean the dc before drawing on it if I 
understand the documentation in the right way. And thats the big mistake. 
When you just use the on paint recall nothing appears except of when you 
resize or move your frame. Then in a part of a millisecond your opengl screen 
appears. So here is the hint: Do what you want in the frame or other panels, 
but the glcanvas have to had the on paintRaw recall and everything is fine.

4. This isn't related direct to the "nothing appears" problem but I spent a 
full night to find the mistake and think its helpfull to know.
When you want some initializations do it after all frames and panels are 
created and the event functions are set.
I tried to switch light and depthbuffer on and did it directly after creating 
the glCanvas. It drove me mad because I searched the whole lighting stuff and 
didn't find the mistake..

I hope I figured this stuff in the right way out. It works for me.

Cheers
Patrick


On Wednesday 12 January 2005 14:36, shelarcy wrote:
> Hmm, Keeping my eyes on this discussion, I have to chage my sample code.
> So I chage the sample following Patrick Scheibe sample.
> Here is a newer version.
>
> On Tue, 11 Jan 2005 12:15:38 +0100, Daan Leijen <da...@cs...> wrote:
> >>  A friend of mine helped me solving the problem.
> >> It was really confusing. I just added any printouts in the display
> >> function of opengl and found out that wxhaskell called this display
> >> func. But why should it be called and even though nothing appeared in
> >> the frame.
> >
> > Ah, this is really good to hear,
> > I have been playing with the sample but couldn't find
> > a solution myself.
> >
> > Good luck with your further experiments,

Re: [wxhaskell-users] Problems running minimal wxHaskell program

[Dmitri P. <mai...@da...>]

Hello!

Thanks for the advice!

I installed GHC 6.2.1 and now it works.

Best regards

Dmitri Pissarenko
--
Dmitri Pissarenko
Software Engineer
http://dapissarenko.com

Re: [wxhaskell-users] Problems running minimal wxHaskell program

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

On Thu, 13 Jan 2005 23:43:46 +0900, shelarcy
<she...@ca...> wrote:
> I hesitated saying that you must use VC 7.1, Because current version  
> wxWidget
> made by VC6, and I don't jugde the problems in wxc code or wxWidget code.
> But you must (* notice *) that on wxHaskell website. Becase Microsoft  
> campaign
> theSpoke Premium supply the VC7.1 low price for student, then  perhaps  
> newbie must use VC 7.1....and he see same problem.

I forgot tell that. This is GLCavas's problem.
http://sourceforge.net/mailarchive/message.php?msg_id=10201165

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

Re: [wxhaskell-users] Problems running minimal wxHaskell program

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

> Maybe, but you can always build with mingw32 or visual C 6.0.
>
On Thu, 13 Jan 2005 15:07:28 +0100, Daan Leijen <da...@cs...> wrote:
>> Current Version developed on VC6, then CVS version doen't fix VC 7,1's
>> problem. (VC 7.1 supplied for VC7 user by Microsoft (without Academic
>> version user), so you don't care about VC7.)
>
> Uuh, I do not understand what you say here. However, you are right that
> I only use visual C 6.0 since I do not have visual C 7.0 -- I do care
> about it -- I have written parts of it :-) -- but I don't think it is
> currently worth the effort to see how it can work wxHaskell. One problem
> might be that you compile .NET code?

OK. I see.

I hesitated saying that you must use VC 7.1, Because current version  
wxWidget
made by VC6, and I don't jugde the problems in wxc code or wxWidget code.
But you must (* notice *) that on wxHaskell website. Becase Microsoft  
campaign
theSpoke Premium supply the VC7.1 low price for student, then  perhaps  
newbie
must use VC 7.1....and he see same problem.

I usally use VC 7.1, because I compile C++ hard template code, for example,
Boost library. But It has no relation with wxHaskell project.
If I bind hard template C++ code to wxc, I will negociate improve that  
problem
that time.

Thank you.

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

Re: [wxhaskell-users] Problems running minimal wxHaskell program

[Daan L. <da...@cs...>]

Hi Shelarcy,

>> - moderate: get the latest wxHaskell from cvs and build it yourself with
>>    ghc-6.2.2 (doable if you follow the build instructions *exactly*)
> 
> 
> But cvs-version has many probrem that build on Visual Studio .NET 2003 (VC
> 7.1).

Maybe, but you can always build with mingw32 or visual C 6.0.

> Current Version developed on VC6, then CVS version doen't fix VC 7,1's
> problem. (VC 7.1 supplied for VC7 user by Microsoft (without Academic
> version user), so you don't care about VC7.)

Uuh, I do not understand what you say here. However, you are right that
I only use visual C 6.0 since I do not have visual C 7.0 -- I do care
about it -- I have written parts of it :-) -- but I don't think it is
currently worth the effort to see how it can work wxHaskell. One problem
might be that you compile .NET code?

-- Daan.