Two customers EXE file not working. New Windows build 19041 in common

ricdam

New member
Both customers claim the exe file was working fine but stopped working recently. They both have the same OS build number which was released on the 11th of August 2020.
They try to open their xlsc file, it thinks for some seconds, and disappear. When they try to open the exe file directly, the “original workbook, last save, browse” screen opens, but once you select an option it thinks and stops thinking after some seconds. No error message displayed in both cases.

Customer 1:
Edition: MS Windows 10 Pro
Version: 2004
OS Build: 19041.450
Windows Feature Experience Pack 120.2212.31.0
MS Excel 2010: 14.0.7257.5000 (32 bit), Part of MS Office Professional Plus 2010

Customer 2:
Windows 10 build 19041.450
Microsoft Office Professional Plus 2013, version 15.0.5267.1000

Thoughts?
 
Which version of XLS Padlock did you use to build the EXE files? Please try version 2020.1 which adds improved compatibility for Windows 10 May 2020.
 
Similar thing happens with files built with 2020.1.
Several clients report critical issues after the recent Windows update.
  • Compiled exe doesn`t open
  • Compiled exe hangs on different functions
 
Problems occur on user PC with:
Windows 10 Pro
Version: 1903
OS build: 18362.1016

After update: KB4497165
 
As one client reverted Windows back to previous upgrade (and exe then works) can`t try this now.
Possibly can try with another client in the upcoming days.
 
My fix:

I believe it has to do when the customer opts to try Microsoft 365 when doing the last Windows update (the update asks to ‘get connected’ and ‘do you want to try 365’, etc).

It then sets 365 ‘apps’ to be the ‘default’ Excel version (XLS Padlock uses the ‘default’ version of Excel to run their exe program).

To test; have your customer close out of Excel and just double-click on any standard .xls or (.xlsm, etc) file to see what opens it.

If the Excel version that opens it says ‘click to run’ version, then that it their ‘default’ Excel (they are now defaulting to the online ‘click-to-run’ version of Excel and are now screwed as Excel must be locally installed for XLS to work) and user will now need to download and run the 365 removal tool from Microsoft to remove 365 (can’t just add/remove 365 as it will still be there).

After they completely remove 365, then may also need to do a ‘repair’ to their old Office version to make sure it sets their ‘real’ Excel as the default Excel that opens all .xls files.

XLS PADLOCK needs to have a way to easily pick which installed version of Excel that opens the program!
  • Especially since the user cannot just open their (installed) Excel first, and then open our file (like they can with their other Excel .xls files to fix this problem)
  • XLS Padlock please listen – as all I do now is fix my users default Excel issue every day now for weeks!
 
Last edited:
Can GDG please confirm this incompatibility with “click to run” Excel builds? It should be avoided both when building exe files and using them?
 
It gets worse; if the user is able to open the file using their Excel App and then they Save the file using the App, then the file is then corrupted (vba no longer works and file takes way longer to open).

I know this because I’ve had many customers email me the file after saving with the App, and it takes forever to open the file (very long delay) even when opening it in my Excel 2016 Pro or even Excel 2010 computer) and then it finally opens and it works except when pressing our vba buttons, I will get compile error: “Compile error in hidden module…" with every vba button!

I then have my users download the Microsoft 365 Office removal tool from Microsoft website, and have them buy Office 2016 or 2019 Professional, and then they have zero issues!

Also, some 365 versions will work as long as it has the desktop versions AND they are ‘downloaded and installed’, and then also set as the ‘default’ Excel version. For example, you can use Microsoft 365 Business, or Business Premier, and if the user also ‘downloads and install it’ (this is an option and not obvious to the that the user needs to download it in order to have the Desktop versions, and therefore it uses the App versions as the default version to open files). The user actually needs to sign in to their account afterwards and use the ‘Install Office’ button, because MS will use just the online versions of the above as the ‘default’ versions (even though the user thinks he is using the desktop version because they bought it!).
 
Last edited:
All recent versions of Excel are “click-to-run” and XLS Padlock works with them. However, it seems that Microsoft also published some light versions of Excel (for their Store) and we are looking for a way to detect them.

As a workaround, XLS Padlock has already a way to let users define the Excel they want to use.
To define the Excel you want, go to the folder with your EXE file: create a text file with NotePad, on the first line, enter the full path to the Excel.EXE file you want to use, and save the text file with that filename: EXEFilename.xlpath
For instance, if your EXE file is c:\my documents\myworkbook.exe, the text file should be named c:\my documents\myworkbook.xlpath
 
Why can’t G.D.G have an easier way for the customer to select which 'installed’ Excel to use on their computer? Not the weird lxpath.txt fix they have now.

This is an important issue as our customers are getting very upset because of this issue of MS forcing the Excel App all the time (just so MS Excel can be multi-platform and other reasons to broad for this forum). This is making us as developers and our products seem bad, not because of our Excel programming but because of the G.D.G exe wrapper.
Now our compiled programs all of a sudden either do not run at all, hangs up all day on the Splash screen (waiting to find Excel), or they get “compiler module missing errors” due to vba missing), as a result, our customers are now losing trust in us, and they are now looking for ‘cloud-based’ solutions (which we promised we have a much more stable solution).

Please G.D.G; you now know that MS keeps pushing their Excel App now and it will only get worse for us, whether it’s already installed on all new PCs, or the next Windows update, or next Excel release or re-branding, etc.

We must fight back to keep MS from dumping vba-enabled Excel all together (give it up MS, there is already Google Sheets, Zoho Sheets, and free Office, etc), the only thing MS has to offer is their VBA and they need to keep vba – not dump it.
 
Last edited:
TheUser said:
Why can’t G.D.G have an easier way for the customer to select whichinstalled’ Excel to use on their computer? Not the weird lxpath.txt fix they have now.
It’s scheduled for a next update. At least, you already have a workaround.
TheUser said:
This is making us as developers and our products seem bad, not because of our Excel programming but because of the G.D.G exe wrapper.
It’s also because Microsoft is switching to a new online model. But you are right that they seem to be willing to drop VBA in the future and replace it with Python. Hopefully, this won’t occur immediately.
It’s not the first time Microsoft tries something, and reverts back. Windows 8 and the missing start menu is a good example.
 
I agree. It seems MS is willing to lead everyone over a cliff again like they did with the Windows phone!
(What phone are you holding in your hand? It’s either an iPhone or Android, not a Windows phone!)

Remember, MS almost dumped their tried and proven Windows 7 o/s for a Windows phone o/s that nobody has or wants!

Or, how about MS Visio; which was and still is the only user-friendly (Office like) cad drawing program (it uses real drawing scale unlike Smart Draw, etc), and instead of becoming the #1 cad drawing program; the they decide instead to make it more of a ‘flowchart’ program – which are widely available for free and Visio has been doing since the 90s.

MS has truly lost their vision and leadership after Bill Gates left (in my opinion)
 
Last edited:
Back
Top