Open mashingan opened 5 years ago
It works for me with MinGW under Windows 10 64-bit. I will try to compile with MSYS2.
Thanks for response.
I confirm I'm able to run it fine with mingw64. I installed mingw64 with SEH and win32 threading.
As gcc for MSYS2, the thread model is posix. I couldn't find whether its exception is SEH or sjlj.
When I try to compile with MSYS2 GCC:
Error: execution of an external compiler program 'C:\msys64\mingw64\bin\gcc.exe -c -w -mno-ms-bitfields -DWIN32_LEAN_AND_MEAN [...] stdlib_system.c' failed with exit code: 1
This is not an issue of NiGui. Closing.
How to resolve this?
I tried nim c --app:gui NiCalc.nim
and the build succeeds but the app upon opening gives this error.
It seems there is an problem with the call of CreateActCtxA()
in shell32.dll
on some systems.
Workaround I guess: Comment out pEnableVisualStyles()
in src/nigui/private/windows/platform_impl.nim
.
To find out the reason: Did you compile the app to 32 or 64 bit?
The reported error message appears when app.init()
is called twice.
Hey, I'm getting this same issue when running example_01_basic_app
. I'm using MSYS2, the problem occurs regardless of whether I build with mingw32 or mingw64.
Commenting out the call to pEnableVisualStyles()
does indeed fix things, but naturally this means I get the "Windows 95" UI.
One might call this a feature, but I'm not really feeling the retro aesthetic today ;)
From what I could find, the approach used by pEnableVisualStyles
is a bit of a hack, not a recommended way of doing things. But I don't know much about the win32 API, not sure if there's some simple change that would make it work.
I was able to enable visual styles using a resource file:
resources.rc (where 1 is "executable", 24 is "resource type: manifest")
1 24 "Application.manifest"
Application.manifest (where the dependency tells Windows to load V6 of the common controls library)
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" />
</dependentAssembly>
</dependency>
</assembly>
Then I compiled the resource with windres
and passed it to the linker:
$ windres resources.rc -o resources.o
$ nim c --app:gui --passL:"resources.o" example_01_basic_app.nim
$ ./example_01_basic_app.exe
So yeah that works, but I guess it's not ideal because it's no longer a self contained solution. How would we solve this? One option could be to assume that windres
exists and do some compile-time magic on when defined(windows) and defined(gcc)
, using staticExec
and {.passL.}
? Idk, seems like it makes a lot of assumptions. On the other hand, I believe there's a lot of other stuff that can be done with resource files, so it might be worth it in the long run...
It appears that this same thing could be achieved in MSVC with a C preprocessor pragma, but that's not very useful since I couldn't find anything similar that would work in MinGW GCC.
#pragma comment(linker,"\"/manifestdependency:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' processorArchitecture='*' publicKeyToken='6595b64144ccf1df' language='*'\"")
Regardless, it's also recommended to initialise the Common Controls library to prevent weirdness from occurring. One tutorial suggested to use ICC_WIN95_CLASSES, and another one suggested ICC_STANDARD_CLASSES, not really sure which flags are necessary here...
{.pragma: libComctl32, stdcall, dynlib: "Comctl32.dll".}
const
ICC_WIN95_CLASSES* = 0x000000FF
ICC_STANDARD_CLASSES* = 0x00004000
type InitCommonControlsExInfo* = object
dwSize*, dwICC*: int32
proc InitCommonControlsEx*(picce: ptr InitCommonControlsExInfo): bool {.importc: "InitCommonControlsEx", libComctl32.}
proc pInitCommonControls() =
var icc: InitCommonControlsExInfo
icc.dwSize = sizeof(icc).int32
icc.dwICC = ICC_WIN95_CLASSES or ICC_STANDARD_CLASSES
discard InitCommonControlsEx(addr icc)
Anyways, I think a lot of Windows users will be running into these issues, so they should definitely be addressed. Let me know what you think about any of this stuff!
Following up to this, I noticed that simply importing Winim in the project causes the correct visual styles to be applied.
Upon investigation it looks like they're doing something similar to what I suggested (see winimbase.nim) but using precompiled resources instead of doing any staticExec
trickery.
I think adopting Winim as a dependency for this project, in place of the current minimal Win32 bindings, could be a good idea. The author has done some things really well (e.g. correct handling of wide char strings, with directives to toggle which kind of string to use)
@exelotl Can you please create a new issue by giving detailed "steps to reproduce" including Windows version, how to install Nim, how to install MSYS2 and how to compile the example. I want to be able to reproduce the error.
When I tried to compile
example_01_basic_app.nim
, it gave me runtime errorI compiled with mingw64-gcc
When I tried and ran using tcc, it's working fine
I'm on Windows 10 64-bit.