I am not Stefan, but maybe I can add to this issue.

Personally I think it is not a good way to dump all the information into the text field and try to let the server parse it.
This could be archived more simply by using e.g. the python elog scripts or using the elog command tool to directly submit well structured elog entires.

As you have mentioned you could use the "execute new|edit|delete" commands to do the things you want to do.
Let the called script fetch the elog entry and alter it in the way you like and resubmit the entry.
(You have to make sure to don't generate a endless loop and you have to proably have to use a forwarding script as the elog "execute" command waits for finished execution).
This way you don't touch the 1500 characters limit of passing $text to the execute command.

Also the point "filling an attribute X with free text" needs some kind of (extended) parsing, which isn't possible with the subst command.
In our elog we such an attribute X, which is in some conditions filled with a set of other attributes and on other conditions just a normal input field, so the user could type custom text in.

"fill an attribute automatically with the character length of the text" could be done with the above mentioned execute command or it could be done on the clientside (e.g. browser using javascript or if automatically generated by a script, then directly by the script)

I hope it helps to build our application.
Best wishes,
Sebastian

Sure, attributes can be shown multi-line, but they cannot be stored in the elog internal database. The database is a very old design and only allows for single line attributes. Just look at a YYMMDDa.log file and you will see that. I would have to change the database format to somethign more advanced like XML, but that would take me a couple of weeks or months.

Soooorrryy! ;-)

Hi Stefan,
no problem: if I just strip all newlines from the $text field (in HTML you use <br> anyway, the newline has no function apart from whitespace), and my multiline attribute is fine to go.
I do not intend to make the attribute editable: it is just used for display. Because that allows me to create the attribute either from free text or from combining other fields - depending on conditional attributes.

As a special feature you could strip all newlines beforehand, when providing the $text for subst statements.

Cheers, Andreas

Would it be possible to create a new command "List format <attribute> = <css_class_name>,<css_class_value>,<width>,<size>", or is there another way to achieve this?

Okay, found some solution for my problem:

And file themes/default/pikett.css contains:

That works like a charm - until I log in to the logbook. Then the include of the CSS in the header is garbled with some "prefix" of random chars:

And a quick check in the source code shows some bad code:

L7615: function "show_html_header"

Here css_base is a not initialized local variable of the function. In fact the above line is the only reference of that variable char css_base[1000].

The bug is still present in elog-3.1.4-611489b

I should tell that I found a simpler way to achieve the same:
I suppress the "text" field and use a single line text input field instead.
The single line input in "free text" modes just contains "<br>" : I would have had to use those in the text field anyway.

Hi Andreas,

the bug you have found was already reported in an earlier issue, together with the same solution you have found.
https://elog.psi.ch/elogs/Forum/69368

Best wishes,
Sebastian

Hi,

I have been using elog for a few years and it is a wonderfull software and has been one that I can't go without. So thank you very much for making it. 

After about a year, I upgraded to the latest version. I noticed that it causes the system to crash. It doesn't seem to happen that often. 

I have installed this on 2 machines, one Windows 10 and one on Windows 7. Over the last week I got one BSOD on each OS. 

The elogs have different configs and logbooks. One is a simple elog that doesn't have any attachments or anything funky. Just straight text.

Please see attached a screenshot of the Memory.DMP which has happned seconds after an schedule restarted the elog service on my PC. 

I will keep monitoring and see if will happen again. But I thought I log it here anyway.

Thanks.

Cheers.

Ales.