Re: r16398 - gnucash/trunk/src/app-utils - In gncFindFile, use g_path_is_absolute instead of file[0]=='/'.

2007-08-06 Thread Chris Shoemaker
On Mon, Aug 06, 2007 at 08:56:40PM -0400, Andreas Köhler wrote:
 Author: andi5
 Date: 2007-08-06 20:56:40 -0400 (Mon, 06 Aug 2007)
 New Revision: 16398
 Trac: http://svn.gnucash.org/trac/changeset/16398
 
 Modified:
gnucash/trunk/src/app-utils/file-utils.c
 Log:
 In gncFindFile, use g_path_is_absolute instead of file[0]=='/'.
 
 
 Modified: gnucash/trunk/src/app-utils/file-utils.c
 ===
 --- gnucash/trunk/src/app-utils/file-utils.c  2007-08-06 22:43:40 UTC (rev 
 16397)
 +++ gnucash/trunk/src/app-utils/file-utils.c  2007-08-07 00:56:40 UTC (rev 
 16398)
 @@ -86,7 +86,7 @@
if (!file || file[0] == '\0') return 0;
  
/* take absolute paths without searching */
 -  if (file[0] != '/')
 +  if (!g_path_is_absolute (file))
  filename = gncFindFile (file);
else
  filename = g_strdup (file);
 

Andi, 

  Do you happen to know if a non-absolute filename is even possible
here?  I looked into it a bit and couldn't see how it could occur.

-chris


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Intro + a bug

2007-08-06 Thread Mike or Penny Novack
It was suggested that I join this list in addition to the users list. I 
am a retired senior systems analyst with a few decades experience in 
software for a financial. Well call that semi-retired as they 
sometimes tempt me back into the cypher mines for a little juicy 
consulting. At the moment I am doing an evaluation of GnuCash to see if 
ready (close enough to ready) for our purposes and am paralleling 
using the books of a 501(c)3 of which I am treasurer. I don't expect 
that all the special report formats as normally used by non-profits will 
be in place, but hey, they aren't in QuickBooks (supposedly) Non-Profit 
version either --- and presumably if GnuCash passes initial testing I 
can write mods, this being open source.

I would like to do a little more than simply report any problems I find 
from the point of view of an end user because with a little help, I 
could. In other words, when I report a problem, if a developer could 
point me to the right subsystem I'll look at the code to try to 
include with the bug report not only what is experienced as wrong by the 
end user but why.

Here's the first one. I am of necessity testing GnuCash under Windows 
(sorry, but we can't make it an organizational requirement for Treasurer 
must be able to run under a 'nix OS). The only interesting problem 
encountered so far is a total inability to save changes to 
preferences/setting. At first I thought this was something I had done 
wrong in set up but no, after much testing, have determined it's a bug.

The initialization routine (I don't know its name) which executes the 
first time a user runs GnuCash, in particular, which creates the .gconf 
directory and it's contents, does not work for all legal Windows XP user 
account names. In other words

If the XP account is named Testonly the initialization will work, the 
directory .gconf and its contents will be created as expected, and 
preference changes can be saved (normal behavior)

If the XP account is named Test  Retest (this is a legal XP account 
name) the directory .gconf doesn't get created, and though this user 
will be able to create a set of books and process them normally, save 
them normally, etc. preference changes like turning off tip of the day 
or altering the frequency of autosave will not take.

Whether the account does or does not have administrator privilege does 
not matter. Sticking in a .gconf directory from another account doesn't 
fix it. More an annoyance than anything else (can always set up another 
XP account with a different name in which to run GnuCash). I suspect 
that very few Windows users have an account name with space and 
ampersand in them  so no surprise something like this would have 
passed through alpha and beta testing without detection. If somebody 
would point me to the right routines I'll have a look. Probably a string 
processing error and most likely the space being mistaken for end of 
string.  Most of my career worked in COBOL and BAL (IBM mainframe 
assembler)  but am reasonably fluent in C (will need to learn Scheme 
when tinkering with reports, but hey, when you have learned a dozen 
languages, what's one more).

Meanwhile, I understand that close the books isn't working. If whoever 
is the developer on that portion wants a hand, please get in touch. 
Unlike the problem I just reported (nuisance, not serious, unlikely to 
affect many people) the lack of a working close the books routine 
would be a serious minus in my evaluation because while can be done by 
hand, onerous if there is a large number of income and expense accounts. 
I am not in a position to offer to take over since I can't make a long 
term commitment not to return to paid work should a tempting offer 
arrive* but at the moment have time available.

Michael D Novack, FLMI(the FLMI is an insurance designation)


* I'm not actively SEEKING paid consulting work, not on any head hunter 
lists  -- but I don't turn down help requests from my ex-employer . 
Totally unpredictable.

-- 
There is no possibility of social justice on a dead planet except the equality 
of the grave.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Intro + a bug

2007-08-06 Thread Josh Sled
Mike or Penny Novack [EMAIL PROTECTED] writes:
 Meanwhile, I understand that close the books isn't working. If whoever 
 is the developer on that portion wants a hand, please get in touch. 

The developer who started that work hasn't had a lot of time for GnuCash in
the last few years.  I really hope he does respond, but I don't feel out of
order responding on his behalf.


There are two approaches to book closing:

One approach has a structure either above or within the current top-level
data structure of a book.  This structure is probably an archive section
that contains transaction/history information outside of the current
financial period.  All of the rest of the application (file load/save; the
UI, generally; reports; c.) would need to be extended to support this
indirection.

Another approach would be more procedural, simply creating a new, standalone
datafile for the new period.  While we already have the functionality to
export the existing account hierarchy (only and alone), a welcome
extension/variant of that export would probably also...

1/ allow the user to ignore obsolete accounts that the user doesn't want to
   carry forward...

2/ create appropriate opening-balance Equity transactions for the rest of the
   {Asset, Liability} accounts.

3/ carry relevant commodities and price-db entries forward.

4/ carry relevant (user-selectable) business items (customers,
   vendors; unpaid invoices, c.) forward.


 I am not in a position to offer to take over since I can't make a long 
 term commitment not to return to paid work should a tempting offer 
 arrive* but at the moment have time available.

Well-formed patches that improve the system are welcome regardless of
long-term commitments.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpAVgjszlW2N.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel