Improving Startup Performance

Are there any tips for improving:

  1. compiled file size
  2. file opening speed (30-60 seconds)

Also, on opening the compiled file, I am asked if I want to enable macros - every time; is there anyway to change this?

We are evaluating XLS Padlock using two of our typical spreadsheet programs:

  • large file version (~3Mb xlsm, 6+Mb compiled) with several tabs, graphics, macros (primarily for movement and display within the workbook), calculations.
  • smaller file version (~0.25Mb xlsm, 4+Mb compiled) with fewer tabs, very few macros

We are using Excel password protection.

I notice that the size of xlsc files is approximately the same as the original xlsm file.


Don’t actually have any tips for improving, but want to share my experience with using xlspadlock with large files.

We distribute a series of Excel systems with VBA macros for navigation and multiple sheets (between 10 - 75), all working on Pivot Tables from a very large SQL database.

The compiled files range in size from 4mb to 95mb depending on how much data the client requires.

We use a Logo on startup and set the display time to between 15 secs to 35secs, depending on the size of the file.

The files are passworded and the final file is locked to a generic Flash drive. This flash drive is distributed to the client, and the password emailed later.

Certain Clients receive more than one copy of these flash drives, which are then colour coded.

We reduced the file size dramatically by re-designing the pivots and reports to using the same pivot cache, and creating separate slicers to do the filtering.

What is VITAL when using files of these sizes is to make sure the user WAITS fully for the file to have loaded completely. If the user disturbs the process (by clicking on something, pressing the refresh button, etc) it will cause the system to crash, so we always inform our users to wait until the system loads fully.

We compile in 2010, and use the developer tab for the VBA. so far we have not seen the dialog asking to allow VBA in any shape or form.

We currently use xlspadlock 1.4, but will change to 2.0 in the near future.

I think thats all i can think of, if anything else springs to mind I will post it separately.


Mdw, ExTradStats-NG

I am also using big files with many sheets. I have found a few methods that help “reducing” the size of protected files.

  1. If you enter during the compilation process to have a password this can increase the file size (see other thread here on this forum) and make the opening time a lot longer.
  2. Try using as uncompiled base file a “binary” saved file. This will reduce the size of your file significantly and make all a lot faster.
  3. Last but not least - and this depends on the hardware of your computer - and if you are working with formula based cells and not just values - i have created a vba procedure that keeps only the minimum required cells with formula content and copies down those cells at the opening of the file creating in such a way the workbook each time new.

Hope this helps !

The size of the .EXE file is expected because XLS Padlock produces stand-alone EXE files that must work with different Excel and Windows versions. They also use full Unicode support, VBA interpreter and this has a “price” (large size).

Finally, EXE files have got anti-piracy protection which contributes to the size too.

If you don’t use our advanced protection features, you can disable formula protection and you’ll get a smaller EXE file.

Loading time especially depends on the computer performance and complexity of the workbook. You must also give some time for the EXE file to decompress the workbook to memory.