From: <72...@in...> - 2003-11-30 20:24:28
|
Hi Martin. This is a more general GHC's issue you can fix linking with the -optl-mwindows flag. (ref. chapter 11.2 in the GHC User's guide). Regards. Jose David. --------------------------------------------- Este mensaje lo ha enviado un Alumno de la Universidad de Malaga. http://www.alumnos.uma.es/ |
From: Martin O. <re...@mn...> - 2003-11-30 21:31:15
|
Okay, I've tried both your trick and the other which was posted by Arjan. Thanks for the help, I really appreciate it! :-) Both tricks works perfectly, however the program launch still looks a bit nasty because the main window always starts up with a default width/height and the resizes to whatever I specified. This happens even though I use: f <- frameFixed [text := "Hello", clientSize := size 100 100] Is there a known work-around for this problem? Also, there is another issue which I'm abit worried about, the executable generated by GHC is 6.42 megs. Perhaps it's just me, but it's that alot for a program which just creates a window with title "hello" ?! Can I fix this without having to force the end-user to install some DLLs etc? Regards, /m At 12:24 2003-11-30, 72...@in... wrote: >Hi Martin. This is a more general GHC's issue you can fix linking with the >-optl-mwindows flag. (ref. chapter 11.2 in the GHC User's guide). |
From: Arjan v. I. <af...@cs...> - 2003-11-30 22:11:42
|
Hi Martin, > [..] the main window always starts up with a default width/height > and the resizes to whatever I specified. This happens even though I > use: > > f <- frameFixed [text := "Hello", clientSize := size 100 100] > > Is there a known work-around for this problem? Maybe creating it invisible and then setting visible to True after adding all your components...? Or you could buy a really fast computer :-) > Also, there is another issue which I'm abit worried about, the > executable > generated by GHC is 6.42 megs. You can "strip" the executable. This gets rid of everything that is linked to it but unnecessary. And then you can internally compress it using UPX ( http://upx.sourceforge.net/ ) The latter saves a lot. The Helium compiler goes from 6 megabytes to less than one. Regards, Arjan |
From: Daan L. <daa...@xs...> - 2003-12-01 12:32:49
|
Hi Martin, > Both tricks works perfectly, however the program launch still looks a bit > nasty because the main window always starts up with a default width/height > and the resizes to whatever I specified. This happens even though I use: > > f <- frameFixed [text := "Hello", clientSize := size 100 100] > > Is there a known work-around for this problem? This behaviour is a somewhat intertwined with wxWindows itself. The "WX" layer tries to abstract from the basic wxWindows calls (in WXCore) and is very dynamic: that is, a frame is first created with some unspecified width and height, and later it is changed to the "clientSize" specified in the attribute list. One would expect that the window would only be shown once the layout is set, but unfortunately, that is not how wxWindows works. I could solve this by requiring an initial widht and height as a parameter to "frame" (or "frameFixed") but I feel that is somewhat against the spirit of the WX design. Another solution that I am contemplating is the use of reflective attributes where the constructor would look in the list of attributes to see if an initial size is specified. This would solve your troubles but it is kind of unsatifying that this would create a distinction between: > f <- frame [attr := expr] and > f <- frame [] > set f [attr := expr] Anyhow, I think that I will implement the latter solution anyway, so your program will work as expected in the next release. All the best, Daan. |
From: David R. <dr...@jd...> - 2003-12-01 13:04:10
|
On Mon, Dec 01, 2003 at 01:32:39PM +0100, Daan Leijen wrote: > Another solution that I am contemplating is the use of reflective > attributes where the constructor would look in the list of attributes to > see if an initial size is specified. This would solve your troubles but > it is kind of unsatifying that this would create a distinction between: > > >f <- frame [attr := expr] > > and > > >f <- frame [] > >set f [attr := expr] > > > Anyhow, I think that I will implement the latter solution anyway, > so your program will work as expected in the next release. This does make the WX layer a bit confusing, but it would bring it closer to the way wxWindows works, which would make things a bit easier for people moving to wxHaskell from wxWindows, so I'm all for it. -- David Roundy http://www.abridgegame.org |