Installing in user accounts

[jmk_phd]

Someone installed my LC app on his new Windows11 laptop (presumably in his administrator user account). He was pleased that it worked as promised. He then created a new user account and installed it again. Now he reports that the app will not launch from either account.

I’m pretty sure that this is not a LC problem – except possibly if it is that I’ve been using a function for saving a prefs file that I found here back in 2017. (In deference to its original author, I always refer to it in my code as the “Klaus function.”) In my preOpenStack handler it refers to “specialfolderpath(35)” to create or find the prefs file needed to validate the program at startup when running in Windows.

Of course, it might be that the freeware version of “Advanced Installer” used to create the installer is at fault. Or perhaps that I’m simply too ignorant as to how things work in Windows.

I wouldn’t bother you all about this except that the person experiencing the problem is a bigshot in the American Psychological Association, whose opinion could make or break the prospect of marketing to my target audience.

[SparkOut]

Hi and happy new year

specialFolderPath(35) resolves (I believe, these days) to C:\ProgramData which is sandboxed (and virtualised, I gather). I found a succinct description on Microsoft technet:

C:\ProgramData permissions, which are a bit weird. Basically users can create files and modify files they created; but they cannot delete or modify any files created by another user (such as those delivered with the package).

You might switch to a per user appdata install with specialFolderPath (26) or switch to using public documents folder specialFolderPath (46)

However, I am very rusty on these rights and permissions so you may still encounter problems. You may have to set permissions explicity on the target folder in the installer. Certainly you need for the app to check on startup what files exist in a given location, and copy or recopy accordingly.

[jacque]

You've hit this bug: https://quality.livecode.com/show_bug.cgi?id=23659 The fix is supposed to be in the next release, which should be soon.

[jmk_phd]

Thanks SparkOut and Jacque for your very helpful replies.

If Jacque’s guess is correct that the problem involves a known bug involving Windows 11, I suppose there’s not much to be done except to wait for the next LC release. (Out of curiosity I did email the user to ask whether by chance he was using an Epson printer and will report back if that’s the case.)

As regards the specialFolderPath function, might it be more prudent to employ the folderIdentifier “support” – which is common to Mac and Windows – and rely upon LC resolve this to the appropriate location for each platform? (I currently employ “preferences” if Mac and “35” if Windows, only because that’s the strategy I’d borrowed from an example found here years ago.)

It’s used in my app simply to manage an encrypted license key file, which is created when the user first unlocks the app by entering a license code, then checked via preOpenStack at each subsequent startup. Frankly, I don’t care where it is stored on each platform, except that it can be located at startup and cannot easily be deleted accidentally by the user.

jeff k

[jacque]

My client and I are waiting for the fix too. But it isn't always just Epson printers, we've seen the bug where no printer was selected at all. A workaround for now is to either download the correct driver from the manufacturer's site, or if the user doesn't print at all, delete all the print drivers.

It's a weird bug. Not all users see it and LC couldn't reproduce it for months. Only a few of our users report problems, others have no trouble with the drivers that ship with Windows.

@Jeff, I don't think it matters where you store the file, but users are generally less likely to fiddle with support files. Prefs are usually considered expendable.

[mwieder]

That is a bizarre sequence of symptoms and side effects in that bug report.
Glad the team got to the bottom of it to find the source of the error.

[jacque]

That is a bizarre sequence of symptoms and side effects in that bug report.
Glad the team got to the bottom of it to find the source of the error.

Yeah, and even now they're not sure they've fixed it. We'll find out soon. Fingers crossed.

@Jeff, I don't think it matters where you store the file but users are less likely to fiddle with the support folder. Prefs are generally considered expendable.

[mwieder]

Jeff- "support" might well be a better specialFolderPath solution for you, although note that it's a per-user setting, so if you need to store it once for multiple user logins on a single computer you'll have to store it multiple times. But otherwise it should be a safe setting for your file. It also means you don't need to check the platform to decide between Windows and Mac <g>.

[jmk_phd]

I’ve just received a reply from my user. He wrote:

“It looks like the Windows 11 built in Epson ET-3760 driver was the culprit causing the program not to start up. Now it starts seamlessly. Good work on your end. Problem appears to be fully solved. I would have never figured this one out absent your guidance. Thank you.”

Although I’m happy to bask in the credit, it really belongs to Jacque for having alerted me to the problem, and to the several LiveCoders who worked so hard for several months last spring to track down this peculiar problem.

I’m very lucky also that my user was so patient and diligent in trying to get my app to work. He’d mentioned that his elder brother was literally a “garage tinkerer” back in the 1970s (like Jobs and Wozniak) and later went on to write over a dozen books on programming for Microsoft and O’Reilly Press. So, unlike many casual users, he understood that bugs are an inevitable reality in programming.

This experience proves to me yet again that it’s not so much what one knows as it is knowing who to consult when tackling a problem. This forum is a treasure, as are its members who so graciously share their time and wisdom. Thank you.

jeff k