May I slip my vote in for this, especially if it would allow more than 100 attributes (the default, and I do know how to increase it).

I even considered cutting that into two groups,. the first being words like "New", "Re-" and the second being actions.  Clunkey and binned.

Hi Lesley,

Perhaps I can restate Stefan's comment.  The data structure of an elog entry, or indeed the structure of daily file(s) for any particular logbook has not changed between v2 and v3.  What has changed is the directory structure.  A set of sub-directories (named by calendar years) are added to each logbook, and all entries/files for any said calendar year moved into the directory for that year.  It gave me a shock the first time I tried using v3 elog, I wondered what it was doing  - it was the auto-conversion to v3 file structure.  I had to convert it all back to v2 file structure, so as to continue to use v2.9.2, so I'm pretty sure there is no change to the data structure within any file, else I think the older elog would kick up a fuss.  As an elog (ab)user, I've plenty of practice with the struture of the data files.

(There was a data structure change between v1 and v2 elog).

Hi,

I've had problems in the past due to a dodgy pointer creating branches despite a "No branches" in the configuration file.  It would be very interesting to see what the 200428a.log file looks like with these entries: in the screenshot they appear to be shown in time order, but do the "Reply to" and "In reply to" liknes in each entry (in the .log file) show a linear progression through the entires, a branch or indeed this same order as the screenshot.  If the duplicated entry sequential to 5657 (i.e 5658) then I would suspect something akin to my pointer's double click when I only made a single click, so fast that then second entry were created before the "No branches" checking part of the program had been reached.  Not so sure about such an event here unless entry 5658 were already open but not closed?

Regards,

David.

Hi Frank,

There are two interesting points about the log file. 

1.  Entry 5658 is timestamped later than 5659, but is earlier in the entry list.  It also is "In Reply to" 5659. despite 5659 having not been written (or at least timestamped) at the time that 5658 is.  Might this be a feature of the draft function?  I've not upgraded my elog for a long time now so my version doesn't have the feature - so I cannot test the idea of more than one entry being worked upon at the same time.

2.  Entry 5657 says it is "In Reply to" 5656, but entry 5656 does not reference 5657 in the "Reply to" line, as it should   Again, this might be a feature of the draft function

Could someone be confusing a draft entry with a real one?  Or two attempts to make an entry?

On the idea of large number of entries, elog doesn't handle deleting of a thread of more than 40 replies well - it crashes after deleting the 40th.  This leaves an orphan thread that causes other issues.  Do you have enough information to decided that this event always happens after x replies?

Hi Frank,

Good bit of detective work.  To me it suggests that something as yet undetermined occurs, that, when the 57th reply happens, causes the issue.  If that "something" hasn't happened, all is well.  Apart from Heinz varieties (not true, in fact), 57 isn't an obvious number; nor did it leap out at me at a quick look at the parameters in the coding.  My example of deleting more than 40 entries causing elog to crash was at least consistent, it happened every time.

I'm trying to think what this something might be.  With my (admittedly largeish) database of elog entries, starting elog from a cold start will take minutes of indexing before it will display home page or whatever.   Presumably it must count the number of entries in each thread (as otherwise why always 57?), yet if you stop and restart, it doesn't necessarily need to do the full indexing again - time between restarts I guess, the authors not considering the evil deeds I perform on yymmdda.log entries.

Bare me out on this, I once had software that ran a system, and every Thursday, without fail, it always did a full recalibration on every start up.  Since updates were issued on Fridays, I commented that it was just adding to our pressure, "as if it knew the day of the week"; it really was (and turned out to be) a day-of-the-week bug.  So, I've been right on more than one occasion.  Anything in common with the threads with cross indexing, such as day of the week, day of the month, time, especially if crossing midnight before the 57th reply? 

Another line would be to view the yymmdda.log files while you are making a normal reply.  In my v2.9.2 version, nothing is written until the Submit button is pressed, then either one or two files are modified or one modified and one new one created.  Is that still true with your version?  I ask because clearly one or two entry numbers have somehow already been "reserved" as if opened, but where?  That Autosave =0 looks to be a useful test to do.

Sorry I cannot be more help.  I'm not one of the development team, though I do have experience of (ab)using elog, and I'm a pretty rubbish coder as well.  but I do have some experience in bug finding!

David.

Anyone who knows me knows I (ab)use elog a lot.   And this one is another of a long list of cheats and work arounds rather than modifying the code properly.

In summary mode, the top row are titles, and if they are long, they will dominate the width of that column.  Similarly if they are short, if entries under that title are either non-existant or even shorter.  Sometimes entries below the title will dominate, e.g. entries under "Date" title.

I assume your entries under the title in question are things like more than one word, such that they get split into two rows within that cell.  Sometimes that can look very untidy.  However, if you want the column wider than the title is given, you can pad out the title with " " (without the "").  Either on both sides for a centred title, or on the right for left justified.  Or between words if the title has more than one.  (Sorry for this edit, I hit submit button rather than preview).

I'm not sure if this is what you want.

If you want to prevent "accidental" replies being identical to the original message, you can force a situation where the user will be alerted that they have to do something if they really want to make a reply. 

An example.  I have an attribute "Action".  In order to make a reply.  I have set up that I must select an Action attribute every time.  If I forget, I get an error message screen, and can click to go back to the entry and have another attempt (nothing is deleted if you have added to the reply).

In the elog.cfg file, I have the lines

Required Attributes =  Action

Preset on reply Action = 

This hopefully would remind them that they are making a reply to an entry, and either make a reply, or abort the attempt.

Hi Harry,

I'm just an elog (ab)user, not one of the developers.  My original 2017 reply was to report an issue that was due to hardware, but somehow overcame a configuration flag (no multiple replies to a single entry), which might have been the same problem as the original poster, Alan Grant, was observing, where one real reply mysteriously became two identical ones.  That appears to be different to the issue you have.

There is an "Abort" button; in version 2.9.2 it is "Back" (without a warning), somewhere along the development it because "Delete" (with a warning), but that only covers circumstances where a reply is started by accident/unintentionally and then it is realised.  My previous suggestion certainly would alert the replier that they have to do something - even if only selectiing an "Action" - before the new entry would be accepted,  This suggests that you have a circumstance where the reply being a duplicate of the entry is a real issue, and that neither of the suggestions above would help.  Don't forget, some people may *want* this.

It would be for Stefan and Andreas to put this on the elog wish-list.  I am a little puzzled as to how your problem arises - lazy user? - so perhaps more comment as to how this is occurring will help Stefan and Andreas understand the why.  There is somewhere on this site a page where you can add suggestions for the wish-list, but due to security certificate issues, I can only access the Forum at present and cannot point you to it.