> 
> Display subject = <b>$subject</b>
> 
> is printed to the browser encoded, so that it is diplayed as is..

I fixed that in revision 1.587. Note however that you should do the formatting
of attributes better using the CSS functionality, since it gives you more
possibilities. See for example the subject of this forum, which has it's own
CSS class "subjname", which has a larger font size. You select your own class like

Format Subject = 0, subjname, subjvalue

in the configuration file. Then add the classes into the CSS file.

Now elog shows each attribute which contains a "<b>" encoded (as HTML). But if you
want to write a subject line like "For bold use <b> in HTML", then the "<b>"
triggers the HTML display, so it is not written as is, which is not what you want in
that case. Since there is no switch "Submit as HTML text" for the attributes, it is
hard for elog to "guess" if you want HTML encoded or not.

I fixed this problem in revision 1.586. It will be contained in the next release.

I am currently trying to get some attributes into one line in my logbook, with some others on a line of their own (this is on the single message page) - pretty much like in this forum.
I searched through the forum and the config examples and found elog:571 as well as elog:Config+Examples/4, but I cannot get it to work.

In the forum, the "Subject:" line is on its own line and fills the whole line, which is what I want. In my logbook, the equivalent attribute does stand on its own line, but the 'value' only fills the space of the second column (i.e., if it was in this forum, the 'value' of "Subject" would be the same width as the icon above it and the rest of the line just blank).
As far as I can see, I'm using the "Format <attribute>=1" statements in the same way as in the example - and when I compare the resulting HTML, it also looks the same. I did notice, however, that you use different CSS classes for "Subject" and its value. Hence my question: To get "Subject" and its value to stretch over the full line, is there some fancy CSS footwork involved? I was not able to find the CSS file for this forum among the configuration examples - maybe you could add it?

Thanks in advance!

> Is it possible to get around this problem by having more then one main text field 
> per record?

No, not at the moment. You can increase the 1500 characters by recompiling elogd, but
at some point you will hit the stack limit and elogd will crash. I plan a major
redesign with completely dynamic memory allocation, thus permitting any number of
characters on any attribute. But this will take a couple of months or so.

> > If I want to go to the latest CVS release, what files do I have to compile
> > along with the elogd.c file?  Also, do I need to use any special gcc flags
> > for the compilation?  Thanks.
> 
> You need elogd.c, mxml.c and regex.c, the Makefile you can get from CVS as well 
> 
> http://midas.psi.ch/cgi-bin/cvsweb/elog/Makefile

Worked like a charm.  Thanks again.

> If I want to go to the latest CVS release, what files do I have to compile
> along with the elogd.c file?  Also, do I need to use any special gcc flags
> for the compilation?  Thanks.

You need elogd.c, mxml.c and regex.c, the Makefile you can get from CVS as well 

http://midas.psi.ch/cgi-bin/cvsweb/elog/Makefile

If I want to go to the latest CVS release, what files do I have to compile
along with the elogd.c file?  Also, do I need to use any special gcc flags
for the compilation?  Thanks.

The reason for the earlier question is that we are trying to use Elog to store 
data in a form we'd need to store more 1500 characters in more than one field.

Is it possible to get around this problem by having more then one main text field 
per record?

thanks

Paul

> > > When creating/updating entries in elog, excluding the main text field are 
> > > there any limits on the size of the other fields?
> > 
> > Yes, this is controlled by the variable NAME_LENGTH in elogd.c, which is
> > currently set to 1500 characters. You can try to increase this and recompile,
> > but at some point you will produce a stack overflow and elogd will crash. So
> > the current length is a compromise.
> > 
> > - Stefan
> 
> Thanks. Thats useful to know.
> 
> Paul