> > Hi Stefan,
> > 
> > I don't know if anyone else would be interested or need this...
> > 
> > If you have an Roption, and it is not required (maybe...) or have a preset attribute, it is possible to make an
> > entry and have replies without any of the attributes in that Roption being selected.
> > 
> > However, once an attribute in that Roption has been selected, it is not possible to go back (editing) to the
> > condition before one was selected on that entry (so far as I can tell).  
> > 
> > Is a way of cancelling all the possible attributes in an Roption practical?  Would others want it?  It is
> > possible with options, as there is a "please select" which can be used to cancel whichever attribute in the
> > option that has been selected.
> > 
> > Regards,  David
> 
> The easiest to achieve this is to define another option. Assume you have the three options
> 
> One, Two, Three
> 
> and you want to "unselect" them. So just add a fourth option like
> 
> Unspecified, One, Two, Three
> 
> so if you do not want any of the "One, Two, Three", just click on "Unspecified" and you get what you want.

This is sort of what I do now, I just wondered if there was a way of clearing that would leave the field completely
blank in the YYMMDDa.log file.

Thanks.

(For some reason I could not add this in Dennis's thread.)

I like this new feature, BUT

I happen to have two Options:   Options System, and Options Status.

System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
this is made up)

Options System: 3.1, NT, 2000, XP, Vista

where the natural order here is chronological.

Perhaps the configuration file option could be more specific, for example

Sort attribute Options Status = 1

which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
the original syntax which defaults to sort *all* Options.

I've just noticed that it has also sorted another Option, which are selected as radio buttons.  Again, this is a
list which has a natural - again, in this case, chronological - order.

Because of this, I'm going to have to turn off this feature as it is on my system.  I hope something can be sorted
on this.


> (For some reason I could not add this in Dennis's thread.)
> 
> I like this new feature, BUT
> 
> I happen to have two Options:   Options System, and Options Status.
> 
> System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
> Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> this is made up)
> 
> Options System: 3.1, NT, 2000, XP, Vista
> 
> where the natural order here is chronological.
> 
> Perhaps the configuration file option could be more specific, for example
> 
> Sort attribute Options Status = 1
> 
> which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
> the original syntax which defaults to sort *all* Options.

Thanks Stefan!  Works great.

> Ok, that makes sense, so I changed it to
> 
> Sort Attribute Options Status = 1
> 
> as you suggested.
> 
> > (For some reason I could not add this in Dennis's thread.)
> > 
> > I like this new feature, BUT
> > 
> > I happen to have two Options:   Options System, and Options Status.
> > 
> > System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
> > Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> > sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> > this is made up)
> > 
> > Options System: 3.1, NT, 2000, XP, Vista
> > 
> > where the natural order here is chronological.
> > 
> > Perhaps the configuration file option could be more specific, for example
> > 
> > Sort attribute Options Status = 1
> > 
> > which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
> > the original syntax which defaults to sort *all* Options.

Hi Stefan,

I have a thread of 70 entries.  I added another entry, which was saved, but elog crashed.
It would restart, but crash every time I then tried to access that 71 entry thread.

By editing the yymmdda.log files to remove the latest entry, all was well again.
Add a test new entry (much smaller) also crashed elog as before.

If it is any help, this is the error message I caught on a console:

src/elogd.c:703: xrealloc: Assertion `*((unsigned int *) (temp + old_size)) == 0xdeadc0de' failed.
./log: line 1:  3123 Aborted    

Now I have got around this, by ending that thread with reference to a new one to continue, but is this to be
expected?  

If this is something (like memory allocation) that would have been in hiding from the start, I cannot imagine
that it is likely to be hit often enough to actually "bug fix" - it might, in any case, cause problems elsewhere.

> Hello.
> 
> Please look at the entry 66525 of this forum (just 5 thread before this one):
> 
>  ->  chain.crt, posted by Gerhard Schneider on Thu Sep 3 21:55:52 2009         (66525)
>   |->    Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009       (66526)
>   |->    Re: chain.crt, posted by Gerhard Schneider on Wed Oct 7 07:56:52 2009 (66556)
> 
> When you collapse the thread, it is collapsed to the 66526 instead of the 66556 (more recent)
> 
>   +      Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009  
> 
> I guess it is because both 66526 and 66556 replies to the first entry. 
> I have the same problem with Elog v2.7.7-2246 and Windows. 
> 
> In general, it seems to work well only if you always reply to the last entry of a thread.
> 
>   Thank you.
> 
> 
> b.t.w. : is there any tip to always force reply to the last entry of a thread?

As the person who suggested this concept, I have to admit I've yet to think of a good way around this issue. 
Preventing "branching" is all very well, but sometimes it is relivent to have a branch (although I usually try to
avoid them).  Unless elog scans every possible branch to find where the latest entry, I cannot think of a
foolproof, practical scheme.

Hi Stefan,

After 21.Oct, all the emails sent out by this discussion form now are addressed to

ELOG@ananke.jtan.com
the name of the server my mails are sent to.

Before that the emails were addressed to 

ELOG@emix.psi.ch

Obviouisly my real email address is there, in the headers (as it would appear for a BCC)

The only consequence for me was these emails turned up in the wrong mailbox, but perhaps it has wider implications?

Hi Stefan,

I must have seen this before, but only just "noticed" it.

If you attach a picture or pdf to the first entry in a tread, there is then a paperclip after the thread display
line.  This shows up in threaded view or collapsed threaded view.

If you then attach a picture or pdf to a subsequent entry, the paperclip icon does not show up in threaded
display, (it is still there on the initial entry) but if the attachment is to the latest entry it shows up in
treaded collapsed display (collapse on last=1, of course).  If collapse on last=0, then initial entry shows on
threaded, collapsed, and that has the icon as expected.

When the icon does show, you can click on it and get the correct attachment to show/launch reader or whatever.

It would appear to be a bug that the attachment icon does not appear in the threaded display (for any entry
other than the initial one).

(sorry about the first posting, hit the wrong key sequence in error)

Regards,

David Pilgram.