Search results

The function you're calling, XLSPL_GetActivationKey, does not exist in XLS Padlock — that's why Application.Run returns nothing. The same applies to names like XLSPL_GetLicenseExpirationDate. Copilot has likely invented them. The real VBA API is exposed through the GXLSForm.GXLSFormula...

Antes de nada, hay una confusión sobre las opciones que Copilot te ha indicado. Las casillas "Enable XLS Padlock VBA API" y "Expose VBA API via PLEval" no existen como tales en XLS Padlock 2025.2, y tampoco hay ningún fichero XLSPadlock.exe independiente que haya que activar...

Short answer: "Trial Days" in the XLS Padlock desktop UI and keymaxdays in the Woo Integration Kit's workbooks.json are the same field. They both set the maximum number of days the key remains valid from the date of first activation. "Display the nag screen" in the...

Thanks for sharing this data point! We've seen similar file-dialog crashes pinned on Norton's behavioral/exploit protection intercepting the Excel process when the Windows common dialog is spawned from inside a protected EXE. For anyone hitting this in the future, the usual fixes on the...

Paquet Builder 2026 — What's New We’re pleased to announce that our Windows installer and Self-Extracting archive creator Paquet Builder 2026 is out. Here's a rundown of the additions available in this major release: AI Assistant & MCP Server The IDE now includes an AI assistant that accepts...

OK, thanks for the extended testing. We'll focus on CEF then.

The syntax heexternal:// followed by a full URL should work correctly for opening external links in the user's default browser. Your code looks correct in principle: <a href="heexternal://https://411center.com/r/exeoutput-magicai">...</a> A few things to check: 1. Test with a simple text...

Glad to hear the issue is resolved! That setting is related to how secondary processes are named. It is mainly intended for companies with strict security rules regarding allowed processes. Since everything works correctly without it, we recommend keeping it disabled for your project.

Did disabling that option fix the issue? Please let us know if the error still occurs after unchecking it and rebuilding your EXE.

Could you check if the following option is enabled or not in your ExeOutput project?

When you use the SignTool Commands method in XLS Padlock, you should not type the actual path to your EXE file in the command line. Instead, use the placeholder {$OUTPUTFILE$} — XLS Padlock will automatically replace it with the real path to your compiled EXE at build time. For example, if your...

A few questions to help narrow this down: - Does this error happen every time you run the EXE, or is it random/intermittent? - Have you tried restarting your PC and running the EXE again? - Do you have any antivirus software that might be interfering (Windows Defender, or a third-party one)? -...

What is the Windows version are you running the EXE on?

You should replace the full path in the command line by "{$OUTPUTFILE$}".

We're unable to reproduce the issue. Would it be possible for you to provide us with your EXE file for internal review? Or to create a lite sample that would let us reproduce your problem? Please contact us with PM/DM if you don't want to publicly publish your file(s).

Can you show the entire line you entered in ?

Which Excel version are you using? And XLS Padlock version?

If Windows SDK is now set up, click Global Preferences in XLS Padlock (on code signing page) and let XLS Padlock auto-detect the path to SignTool.exe (click the appropriate button near the path field).

The behavior you describe is consistent with XLS Padlock disabling the Solver add-in when the protected workbook starts. By default, XLS Padlock disables most Excel add-ins in the secured environment for security reasons. Solver is one of the built-in “common Excel add-ins,” so if your workbook...

Are you running some antivirus software or maybe you're running on a virtual PC?