If I create a Workbook called WB1.00a.xlsm and compile it into an executable and then realise I want to make a change I am getting annoying results.
I will go back to WB1.00a make the necessary change; save it (still as WB1.00a) and then re-compile into the executable. However when I open the new exe file I find that it is identical to the first workbook – i.e. the one before the changes. Naturally if I go back to the WB1.00a I find it is as expected i.e. incorporating the changes. It is as if the newly executable is still using the original version even though it has been compiled with a new version of the .xlsm file.
Hi Dave,
I have experienced exactly this, although it I can’t identify exactly what it is. On some occassions I found simply deleting the existing executable file before compiling has resolved the issue (if it is going to overwrite the executable), but not always.
The most reliable solution for me, has been to delete the existing executable, then compiling it to a new file name, and then recompiling to the filename I want it to be.
I have also noticed that, although again, this is not every time, if I leave the xlspadlock application open, it occassionally fails if I’ve made changes to the application, saved, and then try to recompile, it can fail to update the executable as well.
Afraid it is all fairly random for me, but like to say I am able to work around it this way, but have learnt to double-check the newly compiled version after a number of instances of distributing incorrect versions.
Probably like you I started out thinking I compiled the wrong version and then after proving this was not the case started looking for explanations. One thing that seemed to work – but equally unsure whether it was just a coincidence – is that I deleted the saved XLSPadlock settings from template that I was restoring and re-created it. I was telling myself that the saved template was using the original xlsm version – much like the use of “Original Workbook”. It seemed to work then; but sort of defeats the purpose of the template being to re-use on other applications. Maybe that is not the intention of the templates.
Not sure I understood your possible reliable solution. When you say compile to a new filename – do you mean save the xlsm to a new filename – the compile that to its executable? If so that is what I have done so without success (but of course using the saved settings from template).
Also probably like you – you want the original filename to be v1.0 and further testing means it isn’t!
I am currently in the executable test mode trying to make sure all the features that work in the xlsm work in the exe. Getting your head around checking whether the XLSPadlock objects exists (meaning in executable environment [I think!]) and using PathToFile and EXEPath etc. all gets rather daunting at times!
Still not fully worked out how to do Save, SaveAs and Close without Saving, from VBA code rather than the inbuilt procedure. The inbuilt one frightens the life out of me; so dread to think of the user experience.
The code Signing issue is unrelated. The interaction process seems bizarre – but as the above issues requires multiple re-compiling you become familiar with its operation.
Might have to resort to direct contact with Support.
Dave
PS After compiling with XLSPadlock I tend to close everything as without doing so I am never too sure what file I might be in e.g. xlsm or exe - so saves me the bother - and possible avoids another issue that you have.
It is a possibility as I was experimenting with various settings.
Are you saying that using the “Save changes automatically and load then without prompt next time” would render a new build pointless, if you wanted the WorkBook with new content (data not VBA code) as it would just defer to the previously saved WorkBook file rather than the new compiled WorkBook file? I am sure I deleted the .xlsc files anyway – so presumably it must be reverting back to the Original WorkBook from the original compile?
Would an uninstall feature help prevent this?