I found a solution to this, not a good one, but gets around the problem.
I compiled wxWidgets after a tweak to msw/Main.cpp.
const wxChar *cmdLine = ::GetCommandLine();
was changed to:
const wxChar *cmdLine = NULL;
This precludes passing any args to wxWidgets at startup, but at least the app runs.
In the long run it would help if wxHaskell stripped the RTS parameters, and then give the application some control over which args are passed to wxWidgets. (Assuming there is no way to do that today that I am unaware of.)
Compiling wxWidgets worked more or less like the docs on the web, but I did have to be careful with paths because the make was picking up the gcc in the Haskell tree. So I had to hack my path temporarily when compiling wxWidgets.
Having to deal with wxc.dll in a sandbox is a bit of a pain. I copied it to Windows/System32 as a hack. Is there a trick that would tell the wxHaskell app to add the sandbox dir to the DLL search so that things behaved more like Linux?
Mike
On Mar 24, 2015, at 9:20 PM, Michael Jones
I am seeing strange behavior with a wxHaskell app compiled on Windows 7.
On Linux, all is well. I can call my app like:
app +RTS -N4 -RTS myArg
And in the app I can process the myArg and start a wxHaskell frame.
When I compile the same application on Windows 7, I get an error dialog box that says:
“Unexpected parameter `+RTS`. And a second Usage dialog that looks like it comes from wxHaskell.
I am not sure why Windows is different, but perhaps it is the fact that on Windows 7 I compiled up wxHaskell 0.92, and on Linux I used 0.91 from a cabal update. I used 0.92 on on Windows because I could not get 0.91 to compile due to some type problems where the wxPack version was incompatible with a header file and the Haskell compiler related to 64 bit types long long. There is some noise about this on the web, but no solutions.
Nonetheless, I assume that args are grabbed directly by wxHaskell and Environment.getArgs does not consume them such that they are still available to wxHaskell.
Is there some way to consume arguments so they are no longer available or a way to modify them so that when wxHaskell starts up it sees arguments I can control in code?
In wx there is an API to set arguments, but it does not seem to be part of wxHaskell. So I think I need something I can do outside the wxHaskell API.
Mike _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe