On 2011.12.21 15:39, Allan wrote:
On 21/12/11 19:49, Jack wrote:
On 2011.12.21 13:37, Allan Anderson wrote:
.......
That's the theory, anyway, but unfortunately, it's not always as
straight forward as that. In general, though, banking files should
be straight forward, but the 'last line' setting could cause a
problem if there are trailer lines that need to be dropped.
Should/could the "last line" setting be the number of lines to
ignore at the end, rather than the actual number of the last line to
include? (The display could show either or both, but I'm asking
about what is actually saved.)
I implemented it that First Line is the first line to include, and
Last Line is the last to include.
The Last Line setting is set by the plugin as the last line in the
file, but that could possibly be an unwanted trailer line that the
user would elect to drop. I do not therefore save the last line
number. If it was saved, but the new file had a greater number of
lines, those additional lines could get dropped if a previous setting
was used. I could scan the Date column and stop at the last line
with a valid date, but would probably need to warn the user about
lines being dropped.
So what actually happens now is that, in profile mode, the detected
last line is taken to be the actual last line. If it is in fact a
trailer line, then the date validity check is likely to find a
problem and warn the user. Now, this raises an error and the wizard
restarts at the page after the intro page, allowing the user to move
to the lines setting to make a correction.
In my experience, from a single source, you generally get the same
number of trailer lines that have to be dropped, so if you were to save
that, it would be likely to apply correctly the next time. I agree
saving the actual last line to import is not useful. I suppose you
could label it as "number of trailer lines to ignore" and then
calculate and display but not save the actual last line to import.
When a profile is used, on completion of the import process, the
final wizard page has 'lost' its Back button (that is, it's
disabled). This, I'm pretty sure, is because, with several pages
being skipped, there is no 'history' available to the wizard.
Could the "back" button go to the first page of the wizard, or does
the whole wizard mechanism not allow that?
In profile mode, after the file is read in, the wizard is set to
start at the completion page. I actually spent quite some time
trying to re-enable the Back button, but failed. As a test, I set it
to start at the page prior, and then used Next to get to the
completion page. Doing this allowed the Back button to appear. So,
at this point, it is my belief that the wizard knows of no prior page
so disables the Back button. There is a slight hint of this in the
docs., but it refers to having used the Commit page setting, but that
helped confirm my suspicion. So the user has to exit after using
profile mode, but that's probably as quick as backing up through
several pages.
Incidentally, the csv file you sent me a while back has a trailer
line which nicely triggers the error detection, allowing the user to
intervene. I've left its settings in the new resource file.
Another re-write of the docs. looms, I'm afraid.
Quite expected. Probably best to let the interface stabilize first,
though.
Jack
_______________________________________________
KMyMoney-devel mailing list
KMyMoney-devel@kde.org
https://mail.kde.org/mailman/listinfo/kmymoney-devel
