That sounds really strange. The only thing I can think of is that the demo entry conflicted with your other entries and two of them have the same entry ID. The entry ID is a unique key which identifies each entry. If you look into the raw logbook file 011108a.log with a text editor, you will see them as

$@Mid@$: 1
Date: Thu Nov 08 18:37:57 2001
Author: Stefan Ritt
Type: Routine
Category: General
Subject: Welcome
Attachment:
Encoding: ELCode
========================================
[B]Congratulations for installing ELOG sucessfully!
[/B]

This is a demo entry to ensure the elogd server is working correctly.
Click [I]"New"[/I] to add new pages and [I]"Delete"[/I] to delete this page.

so in this case the ID is 1. When you rsync'ed your entries into the demo logbook directory, you probably got two entries with the ID 1, which screws up elogd. Try to delete the file 011108a.log before you do the rsync. If you start elogd interactively with the "-v" flag, you will see some debugging output which can you help identify some problems:

[ritt@pc5082 ~/elog]$ ./elogd -v
elogd 2.7.0 built Dec 13 2007, 08:05:12 revision 1977
Config file  : /afs/psi.ch/user/r/ritt/elog/elogd.cfg
Resource dir : /afs/psi.ch/user/r/ritt/elog
Logbook dir  : /afs/psi.ch/user/r/ritt/elog/logbooks/
Indexing logbook "demo" in "logbooks/demo/" ...

Config [demo],                           MD5=F2E39262960C779517FEE576C17B1ED0

Entries:
  ID   1, 011108a.log, ofs     0, thead, MD5=81D89C3C94C6626BB7FF191026040E83
After sort:
  ID   1, 011108a.log, ofs     0
ok
Server listening on port 8080 ...

Stefan, I'm still stumped. I'm sorry for the hassle. 

I've removed all the demo entries from both my logbook and the demo. I restarted elog in verbose mode and everything seems normal. I've even run the binary from my old elog installation on the config and logbooks in the new place and it works like a champ.

So I think I've concluded that my new compilation is mucky'd up. The logbooks and config file are fine.

So for the record, the new installation is on MacOS 10.5 (Leopard). The compiler is gcc4.0. There is one warning when I compile:

I haven't yet been able to figure out what this last number is and if it should indeed be part of the date. Any ideas here?

Thanks,

-Val

First of all, you should also describe what has been improved. While for you it is important what is not working, for me it is also important what is working, to get more information if such a problem should occur again. So is your demo entry still there? Is the numbering still starting from 1 after you removed the demo entry?

The suspicious dates Sun, 09 Apr 2006 12:38:31 +52175311 ring actually a bell: Under MacOS, there was always the problem with the timezone. The last number in the date string is the time zone in minutes (where the hour has actually 100 minutes). So an GMT offset of one hour would be +0100, two hours +0200 and so on. Somehow it seems like your number are screwed up completely. So +52175311 is equivalent to ~59 years, which explains why your dates are around 1946. The question is now how did these number go into your entries? Have you copied the *.log files over from the old location or generated newly? Did the old files already have this problem (load the *.log files into an ASCII editor!). The time zone is handled inside ELOG in the following function:

/* workaround for wong timezone under MAX OSX */
long my_timezone()
{
#if defined(OS_MACOSX) || defined(__FreeBSD__)
   time_t tp;
   time(&tp);
   return -localtime(&tp)->tm_gmtoff;
#else
   return timezone;
#endif
}

As you can see, MAXOSX needs a different treatment. I got this code from someone else since I don't have a Mac available. One suspicion I have is that the variable OS_MACOSX is not defined correctly. There is some code which checks for __APPLE__ and then defines OS_MACOSX. Maybe put a print statement next to time(&tp); to see if that code is really executed.

We have used ELog for some time now (within the IT industry) for several things (on-call tracking, after-hours work, knowledge base and a few other uses in development).  Now that we have a good base of data, we would like to do some trending analysis.  We have used Excel in the past for this, but it is rather time consuming.  Does anyone have recommendations for tools (hopefully open source) they have used?  I know nearly anything will since ELog uses flat files, but I'm looking for recommendations that you all know works well.

While it is possible to print a logbook using the standard web browser print command in the Full or Summary view, a dedicated print function allowing the user to print out a hardcopy of a particular logbook would be very helpful.

Cheers

Adam

P.S. Thankyou for the response in elog:65671

This is possible since the beginning: Click on Find, then check Display full entries and Printable output and hit Search. You get then a single page containing all entries from the logbook which you can easily print to get a hardcopy.

Hello,

one idea for improvement. When using the option 'Icon comment' this comment is shown when creating a new entry and moving with he mouse over the icon but it is not displayed in full or summary view. In full or summary view the filename is shown. Not really important, but perhaps an improvement.

Thanks!

Uwe

I implemented this request in SVN revision #1974.

Thank you!

Uwe

Hi

I want to display an image on the title page and have put the following code into the elogd.cfg:

Welcome Title = <img src="pictures/ln2.jpg"><p><font size = 5 color=white>Welcome to My Project Log</font>

I have put the picture "ln2.jpg" in a pictures folder I have created in the root ELOG directory however the image does not show up. Any assistance would be great :)

Thanks in advance

Adam

Hi Adam,

You might double check your file names vs. HTML tags. It appears in your example above that your HTML tag is requesting a file named: "1n2.jpg" and your image file name is "In2.jpg". Please note that in the first case the file name starts with (1) a numeral one and in the second case the file name start with a capital (I) a capital I.

Greg

You cannot put the images into a subdirectory. The above link "pictures/ln2.jpg" will translate into a URL

http://<your server/pictures/ln2.jpg

and there the path pictures will be taken as a logbook name, and the server will complain that this logbook does not exist. Unfortunately you cannot see this error message since it happens during the loading of the picture, and the browser just displays a broken picture link. So put your image into the root of the elogd server and it will be fine.

Greetings,

Last night we updated to 2.6.5 and now the <ENTER>-key on the "quick filter" searches won't work anymore in 
internet exporer (@windows). I have to use the <TAB>-key now to get the results.

The ENTER-key still works under firefox (Windows & linux) and opera (at least under linux, because 
opera@windows refuses to log me on .. whatever) and I would like to see it come back to internet explorer as 
well.

Regards,
Willem Koster

> Greetings,
> 
> Last night we updated to 2.6.5 and now the <ENTER>-key on the "quick filter" searches won't work anymore in 
> internet exporer (@windows). I have to use the <TAB>-key now to get the results.
> 
> The ENTER-key still works under firefox (Windows & linux) and opera (at least under linux, because 
> opera@windows refuses to log me on .. whatever) and I would like to see it come back to internet explorer as 
> well.
> 
> Regards,
> Willem Koster

ehm... funny enough the quick-filter entry used in this elog does work with IE.  

(we're using ELOG V2.6.5-1844 btw)

update: when we try just one quick-filter it works ok, when we add our second quick-filter it stops working.

Both quick-filters are tekst-searches (just like this forum only has one tekst-search quick-filter).

We suspect that this is an explorer issue and probably not something that can be solved with elog, but ... 
maybe .. who knows...



update2:

In the source we see:

    <noscript><input type="Submit" value="Search"></noscript> 

If we remove the <noscript> </noscript> tags we get a submit-button, but our problem seems to be solved. 
(obviously hacking the source-code is not our primary choice :-)

> > Greetings,
> > 
> > Last night we updated to 2.6.5 and now the <ENTER>-key on the "quick filter" searches won't work anymore in 
> > internet exporer (@windows). I have to use the <TAB>-key now to get the results.
> > 
> > The ENTER-key still works under firefox (Windows & linux) and opera (at least under linux, because 
> > opera@windows refuses to log me on .. whatever) and I would like to see it come back to internet explorer as 
> > well.
> > 
> > Regards,
> > Willem Koster
> 
> ehm... funny enough the quick-filter entry used in this elog does work with IE.  
> 
> (we're using ELOG V2.6.5-1844 btw)
> 
> update: when we try just one quick-filter it works ok, when we add our second quick-filter it stops working.
> 
> Both quick-filters are tekst-searches (just like this forum only has one tekst-search quick-filter).
> 
> We suspect that this is an explorer issue and probably not something that can be solved with elog, but ... 
> maybe .. who knows...
> 
> 
> 
> update2:
> 
> In the source we see:
> 
>     <noscript><input type="Submit" value="Search"></noscript> 
> 
> If we remove the <noscript> </noscript> tags we get a submit-button, but our problem seems to be solved. 
> (obviously hacking the source-code is not our primary choice :-)

The code above is for cases where JavaScript is not enabled. The quick filter text box contains code like:

  onChange="document.form1.submit()"

which is some javacode which causes the browser to submit the form after the contents of the text box has changed.
Now if javascript is turned off, this does not work obviously. So I added the <noscript> section which shows the
Submit button, so people can click on it. But you are telling me that IE accepts the hit on return (not the click
on the Submit button) even when JavaScript is off, right? Can you temporarily remove the onChange section and see
what happens?

> > > Greetings,
> > > 
> > > Last night we updated to 2.6.5 and now the <ENTER>-key on the "quick filter" searches won't work anymore in 
> > > internet exporer (@windows). I have to use the <TAB>-key now to get the results.
> > > 
> > > The ENTER-key still works under firefox (Windows & linux) and opera (at least under linux, because 
> > > opera@windows refuses to log me on .. whatever) and I would like to see it come back to internet explorer as 
> > > well.
> > > 
> > > Regards,
> > > Willem Koster
> > 
> > ehm... funny enough the quick-filter entry used in this elog does work with IE.  
> > 
> > (we're using ELOG V2.6.5-1844 btw)
> > 
> > update: when we try just one quick-filter it works ok, when we add our second quick-filter it stops working.
> > 
> > Both quick-filters are tekst-searches (just like this forum only has one tekst-search quick-filter).
> > 
> > We suspect that this is an explorer issue and probably not something that can be solved with elog, but ... 
> > maybe .. who knows...
> > 
> > 
> > 
> > update2:
> > 
> > In the source we see:
> > 
> >     <noscript><input type="Submit" value="Search"></noscript> 
> > 
> > If we remove the <noscript> </noscript> tags we get a submit-button, but our problem seems to be solved. 
> > (obviously hacking the source-code is not our primary choice :-)
> 
> The code above is for cases where JavaScript is not enabled. The quick filter text box contains code like:
> 
>   onChange="document.form1.submit()"
> 
> which is some javacode which causes the browser to submit the form after the contents of the text box has changed.
> Now if javascript is turned off, this does not work obviously. So I added the <noscript> section which shows the
> Submit button, so people can click on it. But you are telling me that IE accepts the hit on return (not the click
> on the Submit button) even when JavaScript is off, right? Can you temporarily remove the onChange section and see
> what happens?


Hello,

I installed the latest version (2.7) of ELOG and having the problem that the quick filter only works when hitting the 
enter-key when there is only one free text field (subtext). Whene having two or more free text field you have to use 
the tab-key or click onto the elog icon. We are using Internet Explorer, not tested on Mozilla right now.

Thanks!

Uwe

> I installed the latest version (2.7) of ELOG and having the problem that the quick filter only works when hitting the 
> enter-key when there is only one free text field (subtext). Whene having two or more free text field you have to use 
> the tab-key or click onto the elog icon. We are using Internet Explorer, not tested on Mozilla right now.

I found that this is indeed an Internet Explorer bug, since it works with all other browsers I tested. There is however a
workaround: I added some code to the current version of elog which shows a "Search" button whenever the page is accessed
through the Internet Explorer. Then the behavior of hitting <return> works again. The change is in revision #1970 and will
be contained in the next release.

> > I installed the latest version (2.7) of ELOG and having the problem that the quick filter only works when hitting the 
> > enter-key when there is only one free text field (subtext). Whene having two or more free text field you have to use 
> > the tab-key or click onto the elog icon. We are using Internet Explorer, not tested on Mozilla right now.
> 
> I found that this is indeed an Internet Explorer bug, since it works with all other browsers I tested. There is however a
> workaround: I added some code to the current version of elog which shows a "Search" button whenever the page is accessed
> through the Internet Explorer. Then the behavior of hitting <return> works again. The change is in revision #1970 and will
> be contained in the next release.

Thanks again for your help!