> 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.

> > 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.

Hi Stefan,

I've been slowly moving threads, and twice now so far (and reproducably) had elog crash.

In each case, it is trying to move a thread with more than 24 entries; it copies the first 24 entries, then
crashes with "Segmentation Fault".  It does not erase the lock file /var/run/elog.pid

I have got around this by manually copying the entries beyond no 24, then deleting the thread entry by entry.

I am aware that I have an old and limited machine (586, 256MB RAM, running Slack 10), and at first I was
"content" to write it off as that; but when it crashed for the second time at exactly the same entry (the
twenty-forth) even though the size of the entries would have been significantly different, I wondered if there
was some factor within  elog that could affect this.

I've not tried it with Copy to:, but imagine it will also be affected as the only difference with this and Move
to: is the deletion of the thread after all the entries had been copied.

> Hi Stefan,
> 
> I've been slowly moving threads, and twice now so far (and reproducably) had elog crash.
> 
> In each case, it is trying to move a thread with more than 24 entries; it copies the first 24 entries, then
> crashes with "Segmentation Fault".  It does not erase the lock file /var/run/elog.pid
> 
> I have got around this by manually copying the entries beyond no 24, then deleting the thread entry by entry.
> 
> I am aware that I have an old and limited machine (586, 256MB RAM, running Slack 10), and at first I was
> "content" to write it off as that; but when it crashed for the second time at exactly the same entry (the
> twenty-forth) even though the size of the entries would have been significantly different, I wondered if there
> was some factor within  elog that could affect this.
> 
> I've not tried it with Copy to:, but imagine it will also be affected as the only difference with this and Move
> to: is the deletion of the thread after all the entries had been copied.

This rings a bell: it's probably related to some internal stack overflow, since the entries are copied 
recursively. I have an idea on how to fix that, but I need time for that.

> > Hi Stefan,
> > 
> > I've been slowly moving threads, and twice now so far (and reproducably) had elog crash.
> > 
> > In each case, it is trying to move a thread with more than 24 entries; it copies the first 24 entries, then
> > crashes with "Segmentation Fault".  It does not erase the lock file /var/run/elog.pid
> > 
> > I have got around this by manually copying the entries beyond no 24, then deleting the thread entry by entry.
> > 
> > I am aware that I have an old and limited machine (586, 256MB RAM, running Slack 10), and at first I was
> > "content" to write it off as that; but when it crashed for the second time at exactly the same entry (the
> > twenty-forth) even though the size of the entries would have been significantly different, I wondered if there
> > was some factor within  elog that could affect this.
> > 
> > I've not tried it with Copy to:, but imagine it will also be affected as the only difference with this and Move
> > to: is the deletion of the thread after all the entries had been copied.
> 
> This rings a bell: it's probably related to some internal stack overflow, since the entries are copied 
> recursively. I have an idea on how to fix that, but I need time for that.
Thanks Stefan,  I'll be keeping an eye out on any annoucement about this one!

> Hi Stefan,
> 
> I've been slowly moving threads, and twice now so far (and reproducably) had elog crash.
> 
> In each case, it is trying to move a thread with more than 24 entries; it copies the first 24 entries, then
> crashes with "Segmentation Fault".  It does not erase the lock file /var/run/elog.pid
> 
> I have got around this by manually copying the entries beyond no 24, then deleting the thread entry by entry.
> 
> I am aware that I have an old and limited machine (586, 256MB RAM, running Slack 10), and at first I was
> "content" to write it off as that; but when it crashed for the second time at exactly the same entry (the
> twenty-forth) even though the size of the entries would have been significantly different, I wondered if there
> was some factor within  elog that could affect this.
> 
> I've not tried it with Copy to:, but imagine it will also be affected as the only difference with this and Move
> to: is the deletion of the thread after all the entries had been copied.

I reworked the internal memory allocation, since there was a stack overflow going over 24 entries. It should be now 
much better. Give a try to revision 2226.

 Stefan,

Works perfectly, thanks for the fix you rock!

Mike

Have a few issues here. The big one is that I have some users of our elog books
that are in India, while the server is in USA. When they click on thumbnail images
then press their browser back-button they get a page expired message and are
unable to see what they were looking at before unless they go back to the main
page. Is this an elog problem or something with Apache?

Also when these users in India write messages sometimes we end up with
duplicate messages seconds apart. I'm not sure if they are pressing the submit
button repeatedly or pressing their browser back button. I've suggested they
try not to do that.

Last issue, is there a way to make thumbnail images open in a new window
by default rather then the same window? This would help fix the first issue at
least. Is there some setting to fix the page expiration/time-out issues?

Regards,
Mike