When the setup wizard reached the "Creating shortcuts" step near the end of the install, it threw this error twice in a row... Runtime Error (at 33:218): Internal error: Unknown constant "allusersprofile" Unsure what causes this as I only saw it happen on 1 out of 3 Windows upgrades so far.
It means that that user wasn't created correctly, see https://docs.microsoft.com/en-us/windows/deployment/usmt/usmt-recognized-environment-variables. One site I saw suggested that running the installer as an Administrator would fix it, another suggested deleting the user and recreating it. If neither works you may need to wipe the disk and reinstall Windows from the distribution or recovery DVD.
The environment variable on the machine that threw the error has the correct default value ALLUSERSPROFILE=C:\ProgramData I would point out this is not a constant, and that sounds like something internal to GnuCash.
Could it be something in this file? https://github.com/Gnucash/gnucash-on-windows/blob/7ac93fe12789a6718c3741c9419b3146bd5b0a58/inno_setup/gnucash-mingw64.iss
Yes and no. That file is a recipe to generate the installer package. It does refer to the ALLUSERSPROFILE environment variable, but it's not this recipe itself actually causing your errors. It's worth noting this recipe only attempts to expand allusersprofile if it failed to expand "userdocs". So the first question is really why "userdocs" didn't expand properly on your system. How did you determine ALLUSERSPROFILE was set to C:\ProgramData ? And does that folder effectively exist ? In addition does USERDOCS expand properly on your failing system (and does the directory it points at exist and is writeable) ? Any difference with your working systems ?
Assuming you are referring only to the environment variables, the userdocs may or may not exist. I will check if there is any more info about that. Environment values are managed by the old MS-DOS command SET. Windows also offers a Control Panel interface.
It seems there is a great deal of misinformation about this on the web. I've checked multiple profiles on multiple machines and none of them have a USERDOCS variable. Whereas, searching online for that variable ONLY brings up threads about icon installation errors. I strongly suspect the installer is using an obsolete or invalid variable name by default. I still don't see any reason why the allusersprofile variable would cause any errors though.
Also, the Stackoverflow page mentioned in the source code is not describing environment variables at all. They are talking about some kind of abstraction of CSIDL values.
Rats, I had written a full answer but it collided with yours and I hadn't noticed that in time so now I have to rewrite it. Oh well, an opportunity to summarize it instead. Some testing shows userdocs or better {userdocs} is an internal constant of the Inno Setup compiler, the tool we use to generate our Windows installer. See this page: http://www.jrsoftware.org/ishelp/index.php?topic=consts So outside of the setup compiler script it has no meaning. On the other hand ALLUSERSPROFILE is a system environment variable, not an internal constant (or at least not any more). According to that same page environment variables can be used as constants, but only if prefixed with a % sign. So that part of the script does indeed need fixing indeed. I have pushed a fix minutes ago. So tomorrow's nightly build should have it fixed. I would be very interested in your feedback so can you try to install from that nightly starting tomorrow on your failing machine and report back whether you still get that error message ? But note that the real issue is not solved yet though: userdocs fails to properly expand or does not qualify as an existing directory according to the internal test. Have you done something in particular with your user's Documents directory on that failing system ?
Depending on the actual meaning of {userdocs} which I haven't figured out yet, for example if it points directly to my "Documents" path where I keep my Word and Excel files etc, this path is defined but may or may not be accessible while running the installer. For example, if Documents has been redirected to a UNC path or a mapped drive letter, but the machine's Ethernet or Wi-Fi is not enabled during GnuCash installation, then the path is defined but not writeable. This would not be unusual at all on my own machines or anyone else's because each user can configure this behavior simply by right-clicking the Documents icon. Windows offers a textbox labeled, "You can change where files in this folder are stored to another place on this hard drive, another drive, or another computer on your network."
p.s. Check here for similar bugs https://github.com/Gnucash/gnucash-on-windows/blob/master/inno_setup/gnucash.iss I wasn't sure which file was what.
(In reply to Robert Chapin from comment #10) > p.s. Check here for similar bugs > > https://github.com/Gnucash/gnucash-on-windows/blob/master/inno_setup/gnucash. > iss > > I wasn't sure which file was what. That's the inno setup file for the old Mingw-classic build system. It's probably time to clear all of that stuff out, but no need to worry about it. Has the machine that raised the warning had previous installations of GnuCash? Did the installation that raised the errors install correctly anyway, meaning that previous installations might have raised them but you didn't notice?
The install worked but may be incomplete. I did notice the uninstalled desktop icons were never replaced. The Runtime Error is impossible to miss as it halts the installer. I've not seen this before, probably because it is affected by network state and path configuration. Let me know where to find the nightly and I will run it a few different ways to see what happens.
Nightlies live at https://code.gnucash.org/builds/win32/maint/
I should also point out that the value returned by %ALLUSERSPROFILE% is very unlikely to be appropriate for a function named GetDocPath. Is this logic supposed to find a nice place to save GnuCash user data?
It's used to set the working/start-in directory for the desktop and start menu shortcuts and to run GnuCash from the last screen in the setup wizard. According to M$ it's an alias to the "All Users" subdirectory of whatever is stored in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList, which IIRC was a Windows NT-3.5 to Windows XP thing that resolved to C:\Documents and Settings\All Users. I think that just sets where the FileChooser goes to first. I'd think on Windows that should be %CSIDL_MYDOCUMENTS% and that it should be *that string* in the shortcut rather than the value of it when the installer is run so that it goes to the right user's My Documents folder.
So the {userdocs} thing sounds like it points to the documents of the user who originally installs the program. Assuming that this value is actually used after GnuCash is installed, that path would not be accessible to any other user and so probably not the best choice to be saved with a public desktop icon. I would have to test this to find out if it's actually doing anything at all. The %ALLUSERSPROFILE% fallback does not even point to any documents. It's more like the root path of the public profile. The closest documents analog to {userdocs} is probably %PUBLIC%\Documents or the {commondocs} constant. I'm guessing this is a better fallback. I'm also thinking that unless the file picker is reading the working directory from the public desktop icon, it might be better to leave the working directory blank and let it default to the bin path. I can try testing this too.
Even in a single-user situation, the {userdocs} constant value is being copied into a static icon, whereas it is possible for the documents path to change at any time.
What directory does the FileChooser open if you put "%CSIDL_MYDOCUMENTS%" into the working-dir/starts-from field of the shortcut, start GnuCash with the shortcut, and select File>Save As...?
The named CSIDLs are some kind of API thing. They are not environment variables and wouldn't be valid in a path literal.
Rats. I hadn't noticed that the MSDN page I was using was for some odd XML context. What about if you just delete the contents of working-dir in the shortcut?
AFAICT, the Save As chooser always defaults to the directory of the most recently opened file, even if I select New File before Save As.
Try moving ~/AppData/Roaming/GnuCash out of the way so that it can't find the MRU list.
GnuCash does save the last used path for opening or saving a file in gsettings (which maps to the Registry on Windows). The key is /org/gnucash/dialogs/open-save/last-path The MRU list is in gsettings as well, under /org/gnucash/dialogs/history So to test the initial behaviour, this last-path key and all keys under history should be reset.
(In reply to Robert Chapin from comment #16) > So the {userdocs} thing sounds like it points to the documents of the user > who originally installs the program.rdc Assuming that this value is actually > used after GnuCash is installed, that path would not be accessible to any > other user and so probably not the best choice to be saved with a public > desktop icon. I would have to test this to find out if it's actually doing > anything at all. I don't know if that's what actually happens. It would be worth testing this on a multi-user windows system (I don't have one available for the moment). What happens if you install gnucash system-wide as an administrator and look at the shortcut details from an ordinary user point of view (a user different from the administrator) ? What is set as the directory to start gnucash in in that case ? > > The %ALLUSERSPROFILE% fallback does not even point to any documents. It's > more like the root path of the public profile. The closest documents analog > to {userdocs} is probably %PUBLIC%\Documents or the {commondocs} constant. > I'm guessing this is a better fallback. Yes, that thought had crossed my mind as well. It may not have existed in the version of the Inno setup compiler that was current back when this code was written. > > I'm also thinking that unless the file picker is reading the working > directory from the public desktop icon, it might be better to leave the > working directory blank and let it default to the bin path. I can try > testing this too. No, defaulting to the bin path is a recipe for a very poor user experience. And in the past we have encountered users trying to save their gnucash data in that directory more than once with all kinds of issues as a consequence. We simply can't assume all users are tech savvy enough to understand the difference between program and data. And this trend gets worse as mobile devices like tablets and cell-phones prefer to hide this distinction as an implementation detail.
The start menu shortcut created in my Win10 VM has the folder pointed to by the installing users "MyDocuments" for all users. After clearing out the HKCU\Software\GSettings registry keys and %APPDATA%\GnuCash for a user, I tried a variety of entries by hand-editing the Start In field of the shortcut. The only one I found that opens the File Chooser in the current user's Documents directory is %userprofile%\Documents. Tested on Win7 and 10. This depends on the user actually having that directory. If he doesn't, File>Open opens in C:\Windows\system32. If the user has set a different docs directory in HKCU\Software\Microsoft\Windows\Current Version\Explorer\User Shell Folders it won't follow it. I think that's even worse than opening in the GnuCash bin directory. I think we need to do this programmatically in GnuCash instead and just remove the Start In/Working Dir code from the Windows installer. That way we can get the user's documents directory from the registry, fall back on %USERPROFILE% if it exists and c:\ if it doesn't.
Thanks for verifying this. I agree this means {userdoc} is a poor choice for the shortcut's working directory. On the other hand this got me curious to what the working directory is typically set to by native Windows applications. Google Chrome sets it to the expansion of %LOCALAPPDATA%\Application Adobe Reader XI doesn't set it at all So it's looks like it's not mandatory, which kind of makes sense. The "Working directory" is a convenience only. You can predefine one so the application has as sensible starting point to resolve relative paths to. That's not only about the first default path for the file dialog but all files accessed by the application. If we're careful to never use relative paths, it doesn't matter what it's set to or that it's not set at all. So I agree we should just drop that code from the installer. As for the initial default in the file open dialog: GnuCash already has code to deal with this - see gnc_get_default_directory() in libgnucash/app-utils/gnc-ui-util.c:184 It will first try to read a last used path from the registry (each dialog can have it's own last used path). If one was never used, it will default to the user's Documents folder on Windows or the user's home directory on other platforms. For completeness I believe not all file dialogs make use of this already. The most common ones do, but ISTR a few outstanding bugs for less used dialogs.
