On Win 7...

The latest code on github seems to result in a wxWidgets call to LPTSTR WINAPI 

This results in popping a dialog complaining about command options. On Linux 
this does not happen. Looks like wxWidgets is trying to use this call to deal 
with unicode, but it unfortunately bypasses the Haskell argument mechanism and 
grabs everything including +/-RTS and passes it to wxWidgets for consideration. 
Perhaps wxHaskell should manage the arguments and strip off any arguments that 
are not destined for wxWidgets, or at least let the Haskell code intercept and 
manage the problem.

Is there some way to effect the wxHaskell initialization so that it prevents 
this call, so that an wxHaskell application running on Windows 7 can accept 
command line arguments properly?

I handling initialization with a start call within Haskell. Perhaps there is an 
alternate approach I am unaware of.


Not knowing the code base, and by searching, it seems it is probably calling 
this wxWidgets code:

static bool
wxMSWEntryCommon(HINSTANCE hInstance, int nCmdShow)
    // remember the parameters Windows gave us
#ifdef __WXMSW__
    wxApp::m_nCmdShow = nCmdShow;

    // parse the command line: we can't use pCmdLine in Unicode build so it is
    // simpler to never use it at all (this also results in a more correct
    // argv[0])

    // break the command line in words
    wxArrayString args;

    const wxChar *cmdLine = ::GetCommandLine();
    if ( cmdLine )
        args = wxCmdLineParser::ConvertStringToArgs(cmdLine);
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
wxhaskell-users mailing list

Reply via email to