Since I upgraded to GnuCash 2.2.8, it won't load. The splash screen appears with the "Loading ..." bar, and then it disappears.
Anyone else have this problem, or any ideas on resolution?
Thanks a million.
New: Kanri (Oct 09, 2024), Platform 29.5.3 (Jun 27, 2024)
1,100+ portable packages, 1.1 billion downloads
No Ads November!, Please donate today
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
As billiebub wrote here (https://portableapps.com/news/2008-12-19_-_gnucash_portable_2.2.8) this can be solved by installing GnuCash 2.2.8 into a new directory and copy your old data-folder into there.
@ billiebub: I think not that it has anything to do with registry entries, since I didn't change them.
Cheers
Thanks for the fix. I am working again.
I upgraged to 2.2.8. After the usual lengthy delay the splash and the Tip of the Day windows displayed for a brief moment then closed. Using Task Manager, the loader and the app terminated sometime later.
I then forced a new install by renaming GnuCashPortable folder. This started up and ran ok. I then copied just one data file containing my accounts from X:\PortableApps\GnuCashPortableRenamed\Data\Profile and it opened up correctly.
What didn't make sense to me was that the next day after having hybernated my WinXP SP2 laptop overnight I was able to run GnuCash from the upgraded folder...I've no idea what 'fixed' the problem!
I tested both new installs and upgrades using my own personal data and had no issues before I packaged it up.. not sure what's going on there.
formerly rayven01
I'll try to repeat the problem by starting from scratch with the previous version but I seem to have only 2.2.4.paf.exe in my download folder...was that the last one you PAF'ed before 2.2.8?
(If not I must have deleted it... where can I find it to re-download it?)
it is the PortableApps\GnuCashPortable\App\GnuCash\share\guile\1.6\slibcat file - cache of where the libs are all stored.
OK, from the top... installed an update, wouldn't load.
moved everything aside, installed clean, put in my data, wouldn't load
moved my data out completely. Loaded fine.
Moved my data back in. Loaded fine.
Diffed this against the original update tree (I keep everything) slibcat file was the only one different in the app area.
Deleting my data dir removed the settings file, which includes the "last drive" variable, which forces the slibcat to be rebuilt.
Quick fix for anyone who has this problem, delete the file. It'll load fine.
I seem to remember a similar problem that I had way back when this was still in beta.
Aweseome app, still, Sean, thanks for all the work you do on it.
Jim
For anyone having the issue, you just need to delete the file: PortableApps\GnuCashPortable\Data\Settings\GnuCashPortableSettings.ini
I didn't see the problem because I ran it from a different computer than I had run it on last before the upgrade. It was never an issue before because the GnuCash folks haven't updated slibcat versions in awhile.
John, if you want to re-package the installer, this line added to PortableApps.comInstallerConfig.nsh in the appropriate place will fix the issue:
!define REMOVEFILE1 "Data\Settings\GnuCashPortableSettings.ini"
There is nothing in the settings file that won't be automatically regenerated correctly.
formerly rayven01
Don't forget that users who set their language manually ARE using that file and switching it back to auto-detect without asking is kinda mean.
Sometimes, the impossible can become possible, if you're awesome!
You're right, I forgot about that setting. To fix it without deleting that file I would have to do one of two things: do the fixes* every time instead of only once per computer/drive letter (adds some time to every launch) or change the launcher to somehow check for the version of GnuCash and redo the fixes if the version changes. Right now it checks the version of the launcher, but the launcher did not change this time around.
* The fixes involved are some path replacements, both in files in the GnuCash app folders and in a few configuration files in the data directory.
formerly rayven01
What about custom code in the installer. That's the way it is supposed to be handled. Isn't that how a local install of GnuCash would do it?
Also, shouldn't all the GnuCash app files be replaced on each upgrade? So why would path replacements be needed.
Sometimes, the impossible can become possible, if you're awesome!
A local install of GnuCash does not have to deal with changing paths. There are text files in GnuCash that have absolute paths that are set at installation. Those paths only seem to work if they ARE absolute, relative paths break it. The problem is these paths, being absolute, need to be updated when the drive letter changes. There also were at one time changes that needed to be made specifically for different versions of windows, so an OS version check is made as well, although those were pulled once they fixed the bug. I added a version check on the launcher to handle in-place updates overwriting the files with changed paths but that only works if the launcher changes, which in this case it didn't.
So in a nutshell, no the installer cannot handle the changes because they can only be determined at run time, so the launcher takes care of them.
formerly rayven01
What the installer can do is update the files within App\GnuCash to be for the current path on install. And then the launcher can start as usual and will only wind up updating the Data files which have not changed between installs.
UPDATE: What I meant is that the installer, when upgrading, will setup the appropriate files in the App directory so that they match the paths in the Data directory so the launcher will update them appropriately on next launch. Or, even better, if the launcher can update the App files regardless of their previous state. That way data backup restores would work.
Sometimes, the impossible can become possible, if you're awesome!
That would fix it IF the user immediately starts it on the same computer after setup. If they installed it, then moved to another computer without launching first, it would still be screwed up. I often update apps without opening them immediately myself, so it's not that far-fetched of a scenario. That's why I don't have the installer do any of it, because you can't count on the installer knowing what must be in place at runtime. Not to mention having the launcher handle it all ensures that people can do an in-place dropin of the GnuCash files if they want to compile their own versions or whatever and everything still works.
formerly rayven01
The way you are describing it if a user drops in a backup of files it won't work since the app and data directories would be out of sync. The files in the app directory being updated properly should not depend on the data directory file state.
Standard installs, upgrade installs and restores of data from backup must work without fail every time regardless of state under PortableApps.com Format guidelines. Manually copying in local settings we can ask them to adjust a file on.
Sometimes, the impossible can become possible, if you're awesome!
I know that. Basically our discussion has come full circle.
The launcher is supposed to be smart enough to determine if the files need to be updated, and do so. Currently it does not handle base app version upgrades correctly when the launcher version isn't changed. Our options are as I stated above.. pull the smart handling and make it update the files every time (adding to launch times, but potentially avoiding other unforeseen problems where updates don't happen when they should), or add a version check of the base application to the launcher which would force it to update the files if the base version changes. Either way will also ensure if they drop in a backup of their data and the versions don't match the files will be updated correctly.
I think we got off track when we started discussing the installer, which really doesn't have anything to do with the problem (assuming we can't blow away the settings file due to people using it for language settings).
formerly rayven01
The launcher could easily check for an app update by reading the appinfo.ini and storing it in the data INI and comparing the two on launch. But that still begs the question of if someone restores the data directory will the launcher know to update the app files. Would treating slibcat as a data file make more sense? Move it to the Data directory on exit and into program on launch? That way it is kept with the data which stores when the path changes.
Sometimes, the impossible can become possible, if you're awesome!
If someone restores the data directory and either the version line is missing in the settings file, or the version is different, it would force an update.
The slibcat file is already treated as a data file.. A version of it with "replaceme" strings resides in DefaultData\Settings. This gets copied into Data\Settings and then the launcher uses that to update and replace the version in the app.
Anyway, it sounds like the preferred method is to check the base app version. I'll work on that, although realistically my time is going to be limited over the holidays.
formerly rayven01
The problem with your current setup is if I, say, backup GnuCash data... switch PCs and then use it and mess it up... then restore my backup ... all without a GnuCash upgrade or version change... then it wouldn't update it. Right?
Sometimes, the impossible can become possible, if you're awesome!
The launcher checks four things: 1. Does the settings ini exist (if so read it in and get the last run settings)? 2. Does the profile path (Data\Profile) match last run? 3. Does the current OS match the last run? 4. Does the current launcher version match the last run?
If any of those fails it forces an update. I will add a 5th check: Does the base app version match the last run?
For your scenario, if #2 doesn't fail (same drive letter & path) 3# doesn't fail (same OS) and assuming no version changes it would work fine despite being on a different PC. If #2 failed (different drive letter) it would force an update and still work fine.
formerly rayven01
Ok, cool. You can get code to check app version number from the miranda installer, I believe. The sooner we fix it the better since we don't want bad upgrades going on. We may have the same issue with some OO.o installs... we're checking into it
Sometimes, the impossible can become possible, if you're awesome!
Revision 2 Pre-Release 1 here fixes the issue.
formerly rayven01