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
pgpj5wzguMPLP.pgp
Description: PGP signature
------------------------------------------------------------------------- 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 wxhaskell-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wxhaskell-users
