Minimizable and non-maximizable window

michyo · 2023-04-04T08:37:37+02:00

I want to open a window that has a minimize button but no maximize button (or disabled). This is because I want my app to be minimizable for user convenienc...

Samir

Yes I'm working on a better implémentation 👍🏻

Samir

Update :

The Window.fullscreen property now works as expected.
When returning from fullscreen, the original Window position will be restored.

It will be available in next bugfix release, and will be committed today on the GitHub repository

michyo

Thank you very much!
Immediately I tried to build it from source code, but I couldn't get past the make error like these.

[@MinGW]
X:\xxxxxx\LuaRT\src>make PLATFORM=x86 ▸ Building Lua 5.4.5 VM ■■■■■■■■■■■■■■■■■■■ ▸ Building LuaRT core framework Makefile:145: recipe for target 'libsensapi.a' failed make[1]: *** [libsensapi.a] Error 1 Makefile:21: recipe for target 'core/.' failed make: *** [core/.] Error 2

[@MSYS2]
xxxxx@XXXXXXXX MINGW64 /x/xxxxxx/luart/src $ make make: *** [Makefile:21: core/.] Error 127

Something I must be making a simple mistake, but I don't have much more time to fight this now, so I'll look forward to your next release. 😅

Samir

You must probably compile LuaRT on an x86 version of Windows.
Try replacing line 145 with the following in the Makefile in src\core\ :

@gendef $(call normalize-path,$(firstword $(wildcard $(windir)\syswow64\SensApi.dll $(windir)\system32\SensApi.dll))) >nul 2>&1

(the check with the $firstword macro don't seem to work as expected)

Sorry for this !

PS: Msys2 build is not supported

michyo

1️⃣ I have tried it. And it still output similar error.

▸  Building Lua 5.4.5 VM
▸  Building LuaRT core framework  Makefile:145: recipe for target 'libsensapi.a' failed
make[1]: *** [libsensapi.a] Error 1
Makefile:21: recipe for target 'core/.' failed
make: *** [core/.] Error 2

2️⃣ Next I installed MinGW-W64-binaries and tried. It caused yet another error.
[Login to see the link]

━━━━━━━━━━━━━━━━━━━━  Building LuaRT 1.4.0 for x64  ━━━━━━━━━━━━━━━━━━━━

▸  Building Lua 5.4.5 VM          ■■■■■■■■■■■■■■■■■■■
▸  Building LuaRT core framework  ■■■■■■■■■■■■■■■■■■■■■sys\File.c: In function 'File_getbuffered':
sys\File.c:582:44: error: 'FILE' {aka 'struct _iobuf'} has no member named '_flag'
  582 |         return lua_self(L, 1, File)->stream->_flag & 0x100 ? _IOFBF : _IONBF;
      |                                            ^~
sys\File.c:583:1: warning: control reaches end of non-void function [-Wreturn-type]
  583 | }
      | ^
make[1]: *** [Makefile:140: sys\File.o] Error 1
make: *** [Makefile:22: core/.] Error 2

I have tried many things but have not been able to solve the error.

▶️ I am beginning to think that maybe this is caused by the MinGW-W64 I installed is UCRT ver. and not MSVCRT ver. I would like to see if that hunch is correct, but now my time is up...😢

michyo

I read this and changed my environment to WinLibs standalone build and tried.
[Login to see the link]

But now, I got another error...

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”  Building LuaRT 1.4.0 for x64  â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

▸  Building Lua 5.4.5 VM          ■■■■■■■■■■■■■■■■■■■
▸  Building LuaRT core framework  ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
▸  Building LuaRT toolchain       ■C:/apps/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o:crtexe.c:(.xdata+0x2c): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against symbol `__C_specific_handler' defined in *UND* section in C:/apps/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe generated
C:/apps/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o:crtexe.c:(.xdata+0x50): relocation truncated to fit: IMAGE_REL_AMD64_ADDR32NB against symbol `__C_specific_handler' defined in *UND* section in C:/apps/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe generated
collect2.exe: error: ld returned 1 exit status
make[1]: *** [makefile:191: luart.exe] Error 1
make[1]: write error: stdout
make: *** [makefile:22: core/.] Error 1

I'll try again when I have more time.

Samir

I'm very sorry for that...
I'm using mingw-w64 8.1.0 SEH from [Login to see the link]

I realize how unreliable this development environment is because of the different distributions and versions of mingw-w64...

I'm really wondering about switching to the Microsoft C compiler cl.exe...

michyo

Thanks for the information of the environment you are using. 😊
I downloaded it and tried, however unfortunately my situation did not improve much.

â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”  Building LuaRT 1.4.0 for x64  â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”â”

▸  Building Lua 5.4.5 VM          ■■■■■■■■■■■■■■■■■■■
▸  Building LuaRT core framework  ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
▸  Building LuaRT toolchain       ■■■■■■■■■■■■■■■■■■
make[1]: write error
Makefile:21: recipe for target 'core/.' failed
make: *** [core/.] Error 1

At the moment I don't know what that is, but my environment may be under some unique kind of curse... In this matter, since I don't do anything patchy deal with MinGW and since I clean everything and install a new environment each time, I have a feeling that this is somehow a problem that is not caused by the individual MinGW environment. 🤔

Samir

The write error means the compiler have been prevented to generate a file... Maybe an antivirus issue ? 🤔

michyo

Since I do development all the time every day, the only antivirus tool I have is the standard Windows Defender. And I am confident that I'm not affected by it because I'm used to dealing with it. (In the past days, I was sick and tired of the days that every time I compile something, it is disinfected as a virus immediately...) 🙂

Until my previous post, I had been working on a Windows 11 PC, but now I tried the same process on another Windows 10 old PC and immediately the build succeeded with no error.

━━━━━━━━━━━━━━━━━━━━  Building LuaRT 1.4.0 for x64  ━━━━━━━━━━━━━━━━━━━━

▸  Building Lua 5.4.5 VM          ■■■■■■■■■■■■■■■■■■■
▸  Building LuaRT core framework  ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
▸  Building LuaRT toolchain       ■■■■■■■■■■■■■■■■■■

▸  Building module audio 0.2      ■■■
▸  Building module canvas 0.3     ■■■■
▸  Building module crypto 1.0
▸  Building module json 0.5       ■
▸  Building module net 1.2
▸  Building module webview 0.5    ■■■

I seem to have gotten 6 EXEs and 1 DLL now in bin dir. I will try them. Thanks for your support‼😊

michyo

I am writing this for the benefit of those who follow me in trying the same thing.

1️⃣ I rewrited line 145 of src/core/Makefile as follows.

gendef C:\Windows\SysWOW64\SensApi.dll

2️⃣ I added these lines at the top of /src/modules/crypto/Makefile.

libsensapi.a:
	gendef C:\Windows\SysWOW64\SensApi.dll

3️⃣ I added these lines at the top of /src/modules/net/Makefile.

libsensapi.a:
	gendef C:\Windows\SysWOW64\SensApi.dll

▶️ With these 3 changes, and with this MinGW-W64 distro, I got 32-bit version of the LuaRT EXEs & DLL on the 64-bit Windows.

MinGW-W64 GCC-8.1.0 i686-posix-dwarf
[Login to see the link]

I hope this information is useful to someone‼😉

cos00kun

michyo
You write all the problems very neatly and very descriptively. Your students must be very lucky 🙂

Samir

Thank you so much for this !!
My Mingw-w64 8.1.0 has both 32 and 64bits support so by using the PLATFORM value it works directly.

MIngw-w64 is not very suited to Windows development in an easy way... I'm working on supporting Visual C++ toolchain which might provide easier compilation and some other advantages... 🤔

michyo

Samir

First I tried "make PLATFORM=x86" with Mingw-w64 8.1.0 SEH you taught me, but on my PC it failed with massive error log output.

▸  Building Lua 5.4.5 VM          ■■■■■■■■■■■■■■■■■■■
▸  Building LuaRT core framework  ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■C:/apps/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: skipping incompatible C:/apps/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/lib/libm.a when searching for -lm
~~~~~~~~~~ MANY LINES OMITTED ~~~~~~~~~~
C:/apps/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lmsvcrt
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:183: lua54.dll] Error 1
make: *** [Makefile:22: core/.] Error 2

Next I tried making the changes you described and "make PLATFORM=x86", but it failed with shorter error logs.
[Login to see the link]

▸  Building Lua 5.4.5 VM          ■■■■■■■■■■■■■■■■■■■
▸  Building LuaRT core framework  dlltool: Can't open def file: SensApi.def
make[1]: *** [Makefile:146: libsensapi.a] Error 1
make: *** [Makefile:22: core/.] Error 2

I have not explored where the root cause lies, but I only wanted to get the 32bit version of the executables ASAP, so I tried a simple solution to achieve that goal. 🙂

I personally prefer MinGW than VC++, because VC++ is not open source and so it makes me fear that it might abandon us and leave us today or tomorrow. But certainly, VC++ toolchain could offer convenience.

cos00kun

Thank you‼ I always hope I can provide as many "I got it!"s as possible. 😊

cos00kun

You are the only flower here and you haven't come for 4 days 😀 we are writing new basic programs, we need your comments as a teacher 😎

michyo

In addition to being a programming instructor, I have been slammed these days with another work as a live audio engineer for stage shows. But nevertheless I recently taught few of my students a step-by-step process of building and distributing EXEs with LuaRT. 🙂

One of them asked me to show how to create a slider control in LuaRT, and I am struggling with it now. I thought I could use HTML's range sliders if I could display a locally placed HTML file in WebView, but I wrote the same code as in the image here, but the local HTML file is not displayed.
[Login to see the link]

And then I tried to draw on the canvas but could not catch the drag operation. Oh no... I have a long way to go before I can answer this question. 😂

Anyway, Now that I have confirmed that all of the non-maximizable window, fullscreen, and canvas work well, I am now developing a little convenience library that will be useful for development in LuaRT and sooner or later will be released as open source.

At least I love LuaRT and I shall never go away from here. I will be back.
Thank you!! ☺️

michyo

After making change as this, WebView displayed the local HTML files.

ui.Webview(win, "file://" ..sys.currentdir.. "\\index.html")

But the current directory may change during execution, and then, if possible, I would like to get a fixed path of the folder where the files embedded in the EXE are expanded/placed, but I haven't found any way to do so. In that sense, I feel this is still a slightly risky approach. 🤔

michyo

Thus, I was able to get the path to the file using embed.

htmlpath = (embed and embed.File("index.html").fullpath) or (sys.currentdir .. "\\index.html")

The files under embed cannot be used when non-compiled testing with wluart, so I separated it by conditions, but it still has the risk that the current directory may be different from the source module directory.

I hope there is a way to get the path where the source module exists when running with wluart.

Samir

In this case, you can get the application folder (ie where the main script/executable is running) by using :

-- Get the path of the current executable (LuaRT interpreter or a compiled executable)
sys.File(arg[0]).directory.path

michyo

Yes‼ That's it‼ 🤩 Surely that can be got from Command Line Arguments❗

htmlpath = (embed and embed.File("index.html").fullpath) or (sys.File(arg[1]).directory.path .. "\\index.html")

I can relax now. Thank you‼ ☺️

« Previous Page