It is occasionally convenient to be able to put the Edit button at the beginning of the line in list view, e.g. when pages are wider than the screen it saves having to scroll across to find it.  Would it be possible to do something similar with the Attachments button?

regards

Steve

I don't understand what you mean. There is only a "Submit" button and a "Choose File" button:

both are pretty close to the beginning of the line (left side).

Hi Stefan and Steve,

Do you mean putting the paperclip icon to the left of the 'Thread display' (such as next to the emoticons and
other stuff we can put in this forum)?

I'd be happy with that if it overwrote the "+" in the threaded, collapsed mode; or
that there was a reserved position for the icon in threaded (any variant), and if no 
attachment, just a blank.  

Or make it something to configure, thus ruining Stefan's weekend and confusing the rest of us ;-)

Regards,

David.



<p>
<table width="98%" align="center" cellspacing="1" style="border:1px solid #486090;">
<tbody>
<tr>
<td cellpadding="3px" style="background-color:#486090; font-weidht:bold; color:white;">Stefan Ritt wrote:</td></tr>
<tr>
<td cellpadding="10px" style="background-color:#FFFFB0;"><p>
<table width="98%" align="center" cellspacing="1" style="border:1px solid #486090;">
    <tbody>
        <tr>
            <td cellpadding="3px" style="background-color:#486090; font-weidht:bold; color:white;">Steve
Williamson wrote:</td>
        </tr>
        <tr>
            <td cellpadding="10px" style="background-color:#FFFFB0;">
            <p>It is occasionally convenient to be able to put the Edit button at the beginning of the line in
list view, e.g. when pages are wider than the screen it saves having to scroll across to find it.&nbsp; Would it
be possible to do something similar with the Attachments button?</p>
            <p>regards</p>
            <p>Steve</p>
            </td>
        </tr>
    </tbody>
</table>
</p>
<p>I don't understand what you mean. There is only a &quot;Submit&quot; button and a &quot;Choose File&quot;
button:</p>
<p><a href="091113_143107/Capture.png?lb=Forum"><img border="0" alt="Capture.png" name="att0" id="att0"
src="091113_143107/Capture.png?lb=Forum&amp;thumb=1" /></a>&nbsp;</p>
<p>both are pretty close to the beginning of the line (left side).</p></td>
</tr>
</tbody>
</table>
</p><p> </p>

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?

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

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

I fixed that in revision 2269. So now elog scans a complete branch and searches for the last entry in the branch. 
You can check again the branch above on the forum, should work now.

Internet Explorer fails to display correctly some aspects of pages generated by elog when the zoom functionality is used (Ctrl + and Ctrl -).  This is really a bug in the IE renderer rather than elog, but since IE can be persuaded to do better relatively easily it might be worth making some minor changes to make elog more robust when used with the buggy Microsoft browser.

The problem I encountered was initially with the multiple checkboxes for an Moptions attribute, but I noticed later it also affects the logbook tabs at the top of the screen.  If you start creating a submission to this forum in IE (7 or earlier, at least) you can see the problem; when zooming, the text labels and  the checkboxes do not scale together so start overlapping, and the same happens with the logbook tabs and the text links on them.  The problem is apparently to do with a proprietary IE concept called "layout" - see http://www.satzansatz.de/cssd/onhavinglayout.html for details - and IE struggles when some elements do not have the hasLayout property set to "true".

The fix is to coerce elements to have the hasLayout element set to "true" by giving them some benign CSS property.  The best I can find is to set "display: inline-block" for some of the key elements, and this can be done by modifying default.css rather than the elogd.c code.

Adding

span {
  display: inline-block;
}

to default.css (e.g. just after the default style definition for the "td" element) and adding

  display: inline-block;

to the style sets for the .sltab and .ltab classes (generic, not those specific to the "a" element) seems to prevent IE doing bad things with the display when zooming without messing up the display in Firefox.  I have not tested this comprehensively or in any other browsers, but I thought it might be worth passing on.

Cheers,

Richard Stamper

I just tried with IE8 (don't have IE7 installed any more), and it looked to me like this has been fixed there. So this will get less a problem in the future. If people are stuck to IE7, they can made your modification themselves in the CSS file, so I guess I won't change the distribution for the moment.

Hello Stephan,

the fckeditor is not running.

I have installed elog 2.7.7 rev. 2246 on windows xp.

I have not changed the default config after the installation:

Theme = default
Comment = General linux tips & tricks
Attributes = Author, Type, Category, Subject
Options Type = Routine, Software Installation, Problem Fixed, Configuration, Other
Options Category = General, Hardware, Software, Network, Other
Extendable Options = Category
Required Attributes = Author, Type
Page Title = ELOG - $subject
Reverse sort = 1
Quick filter = Date, Type

I have started the elog server manually to see if the editor will start, below you will find the output:

elogd 2.7.7 built Jul 31 2009, 13:01:20 revision 2246
Indexing logbooks ... done
Server listening on port 8080 ...

How can I activate the editor?

Thanks,

Michael

 

I have found the problem:

the fckeditor folder contains not all necessary files after installation of Elog version 2.7.7.

I have downloaded the fckeditior manually from:

http://www.fckeditor.net/.

and replaced the faulty one with the new one.

Now the editor is running fine and I see the menu bar when I choose Encoding HTML:

elogd 2.7.7 built Jul 31 2009, 13:01:20 revision 2246
FCKedit detected
Indexing logbooks ... done
Server listening on port 8080 ...

Stefan could you please ckeck if some files are missing in the fckeditor folder within the elog version 2.7.7 rev. 2246.

Thanks

Yepp, the editor source code is completely missing in rev. 2.7.7. Thanks for pointing that out. I will include it in 2.7.8 which I will release pretty soon. 

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.

I may have made this sound as if the issue occurs if the first entry in a thread has an attachment; in fact it
happens whether or not there is an attachment to the first entry.

Hope this makes matters a bit clearer.


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

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

Yes, that's indeed a bug. I fixed it in SVN revision 2266.

Thanks Stefan!

(But I'll wait and see if you do anything about Steve's point...so I'll download "after work"!).

> > 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).
> 
> Yes, that's indeed a bug. I fixed it in SVN revision 2266.

Hi

I'm doing something wrong but can't work out what! 

I've created a new logbook with some date attributes that need to keep in step, e.g. one date ("receipt date") is set to the date the new record is created and another ("response required") to 7 days later.  The logbook doesn't use threaded messages, just a single page for each log entry with Submin/Preview/Back.  The dates are set with:

Preset Receipt Date = $date

Preset Response Required = $shell(gawk 'BEGIN{ print $Receipt Date + 86400 * 7}')

"receipt date" and "response required"  are set correctly when the log is written but if I change "receipt date" then "response required" is not altered - presumably because Preset only works on "New".  Tho I haven't found a way to make this dynamic with Subst.

When the log is updated later a third date may be entered ("proposal submitted") and this should calculate a fourth date ("proposal expires").  Again, I thought I could do this with some sort of "Subst" but can't work out how.  If I use Subst then the value of "proposal expires" isn't changed at all and if I use Subst On Edit then the value isn't changed until I go in to edit the log when the correct "proposal expires" date gets calculated and displayed, e.g.:

Subst On Edit Proposal Expires = $shell(gawk 'BEGIN{ if ($Proposal Sumbitted > 0) {print $Proposal Submitted + 86400 * 30}}')

Am I trying to do the impossible, and is there a document that will help me to understand when different updates (Preset, Subst, Subst On..., Change etc) happen and comparing their use?

A great piece of software - though I sometimes find it hard to get my head round all that it can be bent to do!

regards

Steve

Just try with the current version, where I reworked the "Subst" commands. See elog:66592. "Subst" work now only on "New", and "Subst on Edit" only works when editing an entry.

 Thanks for that - it works perfectly.  Another success for elog!

Hi,

I am using the # character to generate automatically incrementing numbers for new messages.

My issue is that # is evaluated when you hit "New" but E-log is only aware of the new value being used when you hit "Submit".

So, two E-logs can have the same value substituted for # if two E-logs are being edited in parallel.

Maybe someone has a solution to this ?

Soren Poulsen

The solution is to use "Subst" instead of "Preset".

 This is not really resolved, since "Subst" creates a new number on both "New" and "Reply". I would like "Subst" to create a new number only on "New" and preserve this number through replies throughout the thread. I would like to be able to say "Subst thread = #" to make a new number for the thread and combine it with "Subst on reply thread = $thread" to preserve the number on replies, but this does not work. Maybe someone has already done this ?

Soren

 This can be solved with something like "Subst <attr> = $shell(cmd...) where cmd calculates a new value of attr, as a function of #, when attr does not already have a value. This thread is closed.
 

Soren

I just reworked the "Subst" command to make it more consistently. Now "Subst on Edit" and "Subst on Reply" are executed after the entry submission,  and they are mutually exclusive. So all you need right now is

Subst Tag = #

and it will not increment when editing or replying to an existing entry. The fix is in SVN revision 2264.

 Thanks a lot for doing this change.

After I moved an item from one logbook to another one I cannot reply on this item anymore.

When the submit button is clicked it returns: Submit not allowed

This eLog server running Linux is sync'd with an server running Windows XP.

On the windows server the funcionality is working perfect(so no Submit is not allowed on a reply)

Check your configuration file for the destination logbook, probably you have only restricted rights there ("Guest menu", "Login user" ???)