Hey,

I am testing out automated entries using elog on the command line. The file I pass has html code for a table; the resulting entry shows the html code for the table instead of generating the table. Is there a way to make elog parse the code to show a formatted table?

Thanks  in advance.

Stefan, 
We are interested in using your ELOG (which we consider to be a wonderful 
application) even more. We would like to make a few adaptations in your 
source code, above all to add some functionality that we are missing.

I was wondering if there is a way we could coordinate the development 
together. For instance, would it be of your interest to receive the code 
adaptations we do and implement it in your future releases? 

To be more specific, for the moment we are really interested in 
implementing the SHELL script execution on the server (I noticed it is in 
your wishlist).

Best regards,

Tomas Rudolf
Micro Belgium Application

Hi, we are using ELOG for keeping track of a server maintainance.  I've
translated some of ELOG's strings.  The file is attached.  There will be
more translations, when I get inspired again ;-)

Sometimes we change the attributes in a config file for a given tab as time goes on, which naturally can get out of sync with the older data in that tab.

I can imagine some other Elog users have encounterd this too at some point so I'm wondering if there's a utilty or some way anyone knows of that I can use to parse a log file DIRECTLY to view the older data, without using the Elog GUI?

Hello,

I've had much success and use with ELOG.  However there is one thing that I wish I could figure out in order to 
make ELOG work exactly as I need it.

When I either create a new ELOG entry, or, have one created via an automated scrip run by CRON, the paragraph 
width is preset. 

I've read the notes and experimented with setting the text size, but it seems that if I either adjust it via the 
config file, or, change the size by dragging the message box itself, then I end up with an ELOG entry that has an 
irregular message size to it than all the others.  Consistency and uniformity is very important to me for how I 
use ELOG.

It would be idea, if the log entries did not contain <CR>'s or justified lines.  In other words, I would like to 
be able to have my ELOG entry fill the width of the screen, be it a wide screen or standard portrait scree, and 
at whatever resolution and text size I have my browser set to.

By not filling the entire width (and also by not having it auto adjust depending on screen size, resolution, 
etc.) there are large portions of the screen real estate that is lost and you end up with very long, scrolling 
log entries versus entries that file the entire width and therefor take less vertical screen space.

With all that said -- Does anyone else have this issue?  And, is there anything I can do to correct this?  This 
would make me a very happy user if it could be done.

Thank you in advance!

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.

Good day all ,

does Elog has a paid version that is not open soureced 

regards

William Vasio 

Good day all ,

does Elog has a paid version that is not open soureced 

regards

William Vasio