viXen bug: -

[David Silverwood]

Dear Guy,

I'd like to inform you of a bug with viXen,
which occurred today: 14 November  2025, at 20:21:16 GMT.
GuiTellApiError: Last error code 32: The process cannot access the file because it is being used by another process.


Gen50ResourceFile: Can't copy RC File
C:\xblite\programs\guisrc\ressouce.rc
in directory
C:\Users\Watchman\Projects\

OS: Windows 10 ver  10.0-NT

For your review, I attach viXen's corresponding log vixen_log.bak.

This is how it happened:
viXen was re-loading my project when it displayed a technical error message
(see the attached screen capture).

Could you please publish a fix as soon as possible as I can't live with a buggy viXen?
Thanks in advance.

Regards, David

[Guy LONNE]

Hi David!

I got your bug report, which I experienced earlier. I have an idea of what it is, but I have to look up the log you sent. One thing I'll look up is the Windows version. Why? Because I had to go around Windows 10's new way to handle the permissions on files that are updated. I'm AFK, but I'll see what I can do just by memory.

Bye! Guy

--
You received this message because you are subscribed to the Google Groups "xblite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xblite+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/xblite/CAH_LReTQLk14LKrRTDjm0jGcZMX0nZTG3W0pUnx06T0R59uVRQ%40mail.gmail.com.

[Guy LONNE]

Hi David!

Since you are installing viXen in another folder than the dedicated C:/xblite/programs, you have a permission problem with viXen's work files.

Fix: Revoke manually the status "read only" of your installation folder to grant write rights to viXen's work files.

However, my experience has taught me that the only "safe" place to install anything XBLite is: C:/xblite/programs.

Why? Because /programs contains all the needed dll: xst.dll + xsx.dll at the very least, which I have to provide myself in viXen's Inno Setup installer for vxbl.exe to be self-sufficient.

Bye! Guy

[Guy LONNE]

Hi David.

I looked in the log you sent, and it seems to me that you ran ViXen from XSED. Better use the compiled version that you get from SourceForge as I compiled vxbl.x with the flag -rc to reduce the size of vxbl.asm. The reason is that because of bad design from my part, I allowed viXen to hit a size wall in memory. If you add XSED, you deprive GoAsm of RAM, and GoAsm can't assemble correctly vxbl.x from within XSED.

As soon as I can put my fingers on my computer (next week), I'll be able to reproduce your bug, and we can work on a fix.

Bye! Guy

[Guy LONNE]

Hi David.

In case there was a problem with your previous download, I've just re-uploaded the following to SourceForge:
1.vixen_setup_v1_99u_windows10.exe
2.vixen_v1_99u.zip
3.vixen_setup_v1_99u.exe

Explanation:
- vixen_setup_v1_99u_windows10.exe was generated under Windows 11, using the latest version of xblite.exe from vixen_v1_99u.zip.

- vixen_setup_v1_99u.exe was generated on my Thinkpad (from around 1996!), under Windows XP, using the older version of xblite.exe, from the same sources as vixen_v1_99u.zip: vxbl.x and /guisrc.

I've already successfully tested vixen_setup_v1_99u.exe on ReactOS and Linux Mint Wine. It should therefore work as a fallback solution for vixen_setup_v1_99u_windows10.exe if the latter fails.

So, try again and let me know if it solved your problem.

Bye! Guy

[Guy LONNE]

Hello David.

I remember of a bug that I experienced on 23 January 2023 totally by chance, and for which I wrote a fix in xsx.x.

The bug concerns XstFileExists, which I use extensively in viXen.

The bug: XstFileExists opens in read mode the file whose physical presence must be verified, but considers that any error indicates that file doesn't actually exist.

In fact, the file might be blocked by a system process, an antivirus program, or something else.

To make it worse, Windows has an optimization option that can play tricks on us: Windows can lock files and never forgets that locking, even after a reboot.

After this bug, I unchecked this optimization to avoid being caught out twice, because this bug persists, even after a million reboots.

I provided this fix to D., but I suppose he hadn't had time to fix it in xsx.x.

Bye! Guy

'
'
' ##############################
' #####  XstFileExists ()  #####
' ##############################
'
' GL-23jan23-old---
'' Determine if file exists. Returns 0 on success, -1 on failure.
''
'FUNCTION XstFileExists (file$)
'
' IFZ file$ THEN RETURN (-1)
' ofile = XxxOpen (file$, $$RD)
' IF ofile = -1 THEN RETURN (-1)
' XxxClose (ofile)
'
'END FUNCTION
' GL-23jan23-old===
' GL-23jan23-new+++
' New: RETURNs an error message on an OPEN fail.
'
' Determines if a file exists. Returns 0 on success, -1 on failure.
'
' New error message.
' For example (simplified):
' errNum = ERROR (0) ' clear last error code
' bErr = XstFileExists (file$)
' IF bErr THEN ' file does not exist
' errNum = ERROR (0) ' get current error, then clear it
' PRINT ERROR$ (errNum)
' ENDIF
'
FUNCTION XstFileExists (file$)
EXTERNAL /shr_data/ errno        ' run-time error number

XLONG fileNumber        ' system file number
'
' To convert errno into an XBLite error.
'
XLONG error        ' for XstSystemErrorToError()
XLONG errLast        ' for ERROR()

XLONG bErr        ' returned error indicator (-1 for any fail, 0 for file exists)
'
' Start clean.
'
bErr = -1 ' Assume fail
errno = 0 ' clear any run-time error
SetLastError (0) ' clear any system error
'
' Try to open the passed file.
'
fileNumber = XxxOpen (file$, $$RD) ' Reading only of course!
IF fileNumber < 0 THEN
' Fail to get a system file number!
errno = GetLastError () ' get system error
XstSystemErrorToError (errno, @error) ' move system error to high word of error value
errLast = ERROR (error) ' set current run-time error, to inform the caller of the exact failure
ELSE
' Success!
bErr = 0        ' (0 indicates that the file exists)
'
' GL-23jan23-fix+++
XxxClose (fileNumber) ' release this good file handle to avoid a permanent lock
' GL-23jan23-fix===
'
fileNumber = 0 ' served its purpose
ENDIF
'
' Clean-up.
'
IFF bErr THEN
SetLastError (0) ' clear any system error
errno = 0 ' clear run-time error
ENDIF
RETURN bErr

END FUNCTION
' GL-23jan23-new===
'

[Guy LONNE]

Hi Silver David.

I think I've fixed the viXen bug that made it unsafe to use in your latest version of XbLite. I can't really test it in my development environment because I work in a controlled environment with many assertions and internal checks.

Could you please download my latest version of viXen from SourceForge and let me know if everything works correctly?

Thanks in advance, and thank you for taking the time to report this bug; my motto: No Bug, No Use!

Bye! Guy

[David Silverwood]

Thanks Guy. I'll test it on my Win10 machine later and see what happens. Much appreciated, especially for the time you still take to look into these little things

To view this discussion visit https://groups.google.com/d/msgid/xblite/307669ff-af76-4b63-b09a-ebfa23646e4cn%40googlegroups.com.

[Watchman]

Hi Guy

New bug. First time I actually really used WinX. 

Anyway, I created the window with vixen earlier and when vixen created the source it did the following:

' auto-resize for #lblCash
series = WinXGroupBox_GetAutosizerSeries (#grp1, 0) ' #### vixen error #### (#grp1, 0)

WinXAutoSizer_SetSimpleInfo (#lblCash, series, 0, 1, 0)

Checking the WinX docs the actual code would be :
' auto-resize for #lblCash
series = WinXGroupBox_GetAutosizerSeries (#grp1) ' #### vixen error #### (#grp1, 0)

WinXAutoSizer_SetSimpleInfo (#lblCash, series, 0, 1, 0)

In case you would want to look into it.

Bye

David 

[Guy Lonne]

Object: Quick Test Request: WinXGroupBox_GetAutosizerSeries Parameter

Hi Silver David!

Thank you for flagging the issue with viXen’s XBLite code generation: Invalid parameter list for the call of WinXGroupBox_GetAutosizerSeries() from WinX.dll.

To confirm my comprehension of the root cause, could you please help test both versions of the call in your environment?

Quick and Dirty Test Cases:

1. viXen’s Generated Code (with 0): (probable bug)

2. Documented Code (without 0): (probably correct)

Questions:

• Does the first version (with 0) work, fail, or behave unexpectedly?

• Does the second version (without 0) work as intended?

This will help us determine if the issue lies in viXen’s logic.

I’m currently AFK for two months, so your feedback would be invaluable.

Let me know the results at your earliest convenience.

viXen says: "May your code compile on the first try!"

Bye! Guy

[Guy Lonne]

Object: Bug Fix: Superfluous Parameter in WinXGroupBox_GetAutosizerSeries

Hi Silver David!

I’ve addressed the bug you reported in WinXGroupBox_GetAutosizerSeries.

After investigating, I found that the issue stemmed from your use of an outdated version of viXen (specifically, a version predating 13 July 2020).

The latest release, viXen v1.99u, includes fixes for this issue, as evidenced by the updated vxbl.x (dated 13 June 2026) and WinX.x source files (dated 31 May 2026). Upgrading to this version will resolve the superfluous parameter problem you encountered.

Here’s how to update your viXen environment on your dev machine:

1. Download the latest viXen installer from SourceForge: [viXen v1.99u Windows 10 Installer]
https://sourceforge.net/projects/visual-xblite/files/vixen%20version%201/VIXEN%20v1.99/vixen_setup_v1_99u_windows10.exe/download

2. Download the viXen source code (contains the latest WinX.x): [viXen v1.99u Source Code]
https://sourceforge.net/projects/visual-xblite/files/vixen%20version%201/VIXEN%20v1.99/vixen_v1_99u.zip/download

3. Back up your old viXen installation (just in case!).
4. Compile WinX.x and generate the updated `C:\xblite\programs\WinX.dll` file using XSED.
5. Run the viXen installer to update your environment.
6. Rebuild your WinX project—the bug should now be resolved.

Always update your tools before reporting a bug,
unless you enjoy debugging the past!

-- 
Bye! Guy