You can't directly change individual columns, but you can reduce the "Text" column. This is done in themes/default/elog.css. Search for "listtitle2" and change or remove the line "width:100%". This makes the text column narrower, leaving more space for the subject column.

Hi Stefan,

Thanks for your prompt follow up.  I did try commenting of the width statement for listtitle2 and also reducing it to 40% but it did not work.  I restarted elogd daemon and I don't see the columns changing.  I also tried putting a percentage number (40%) for listtitle1 just to try and no change either.  Appreciate your help.

Thanks.

Illam

Hi Stefan,

Thanks for your prompt follow up.  I did try commenting of the width statement for listtitle2 and also reducing it to 40% but it did not work.  I restarted elogd daemon and I don't see the columns changing.  I also tried putting a percentage number (40%) for listtitle1 just to try and no change either.  Appreciate your help.

Thanks.

Illam

I can think of two reasons why you don't see a change:

1) You modified the wrong file. The elog.css file is under elog/themes/default/elog.css. If you "install" elog, it might go into your installation directory. So check if you have more than one file with this name.

2) After the change, you did not reload the page in your browser.

Try to request the file directly in your browser with <url to elog>/logbook/elog.css then you will see the actual file your browser is using. Make sure your modification is present there.

Stefan

Hi,

Is there a search feature in ELOG.  Basically, we have the topics broken up by categories but within the categories we would like to search by a key word based on the subject to get to a specific topic.

Thanks.
Illam

Hi Frank,

Good bit of detective work.  To me it suggests that something as yet undetermined occurs, that, when the 57th reply happens, causes the issue.  If that "something" hasn't happened, all is well.  Apart from Heinz varieties (not true, in fact), 57 isn't an obvious number; nor did it leap out at me at a quick look at the parameters in the coding.  My example of deleting more than 40 entries causing elog to crash was at least consistent, it happened every time.

I'm trying to think what this something might be.  With my (admittedly largeish) database of elog entries, starting elog from a cold start will take minutes of indexing before it will display home page or whatever.   Presumably it must count the number of entries in each thread (as otherwise why always 57?), yet if you stop and restart, it doesn't necessarily need to do the full indexing again - time between restarts I guess, the authors not considering the evil deeds I perform on yymmdda.log entries.

Bare me out on this, I once had software that ran a system, and every Thursday, without fail, it always did a full recalibration on every start up.  Since updates were issued on Fridays, I commented that it was just adding to our pressure, "as if it knew the day of the week"; it really was (and turned out to be) a day-of-the-week bug.  So, I've been right on more than one occasion.  Anything in common with the threads with cross indexing, such as day of the week, day of the month, time, especially if crossing midnight before the 57th reply? 

Another line would be to view the yymmdda.log files while you are making a normal reply.  In my v2.9.2 version, nothing is written until the Submit button is pressed, then either one or two files are modified or one modified and one new one created.  Is that still true with your version?  I ask because clearly one or two entry numbers have somehow already been "reserved" as if opened, but where?  That Autosave =0 looks to be a useful test to do.

Sorry I cannot be more help.  I'm not one of the development team, though I do have experience of (ab)using elog, and I'm a pretty rubbish coder as well.  but I do have some experience in bug finding!

David.