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.

Here is an excerpt from my config file:

Type Last Edit = datetime
Preset Last Edit =$entry time
Locked Attributes = Last Edit
Subst on edit Last Edit = $date
Preset on Duplicate Last Edit = $date

I have another attribute called Part that I've made extendable.

When I duplicate an entry, Last Edit is updated with the current date correctly. However, as soon as I click the Add Part button next to my extendable Part attribute, and the page reloads to show the entry box for the Part field, the Last Entry field is replaced with a "-".

I have to submit and then re-edit the entry to get Last Edit to have a valid value again.

 *EDIT*:

I noticed that any time the page reloads while in the entry screen this happens, e.g. by selecting plain instead of html format.

 Thanks for reporting that problem. It has been fixed in SVN revision 2156.

 Excellent! Thank you.

Apologies if these are known bugs, I'm very busy at the moment but I wanted to post this before I forget:

I'm using Safari on a Mac to make Elog entries.

1) The preview of some pdf attachments in edit mode displays huge areas of white space around each page. I can send examples if you'd like - please email me directly, for some reason I never get email notifications from this forum (and they aren't being tagged as spam, so I don't know where they go).

2) When that happens, the text entry area for ELcode format expands horizontally to match the huge pdf file width. Text without line feeds then doesn't wrap until the huge window width is filled, so I have to scroll horizontally all the time while editing to see what I've written.

3) So I turned off attachment previewing as a workaround (Preview attachments = 0 ). That worked fine by not expanding the entry area, but I noticed some odd behavior. The list of attachments below the text entry area is badly formatted. Here's a screen shot:

I tried to reproduce this with a new entry but the text was formatted properly for that entry.

P.S. While editing this entry, I see that the text area width is again being set by the width of the picture I've attached - try it yourself; if you try to resize your browser window smaller while editing, the text will only wrap until the width of the attachment is reached - the text no longer wraps at smaller widths than the attachment. 

Your problem 1) is probably caused by ImageMagick. I use that package to convert PDFs to images. If this package estimates the paper size from the PDF incorrectly, you're screwed. You can go and actually locate the thumbnail pictures in the ELOG directory (should be named  xxxxxx_yyyyyy_<name>-0.png). If you check these pictures, they are probably already huge.

Problem 3) indeed is a small bug in elogd, which I fixed in revision #2178. If you can download the SVN version and recompile elogd, you should be fine:

 Thanks for the bug fix, we'll get our installation updated ASAP. And I will look into why some of my pdf file image sizes are interpreted incorrectly by ImageMagick, it might having something to do with how I've generated them.

Is it possible to set the default image size to always scale to fit the browser window? For example, this entry has a png attachment, but it still suffers from the fact that the text window size is set by the width of the png image.

If I'm forgetting something, sorry, I'm writing in a hurry!

Dennis