Many Thank's to Stefan for his work!!! He's doing a great job and is offering a better 
service than most comercial programs! Thank you very much Stefan!!! 
 
The new elogd.exe is now runniung 24h on my Windows 2003 Server without any problems. I made 
a little "stress" test too and there wasn't any problems at all. Also threaded view is 
working stable now. 
 
Is seems, that the new eleogd.exe uses a litle bit less of system rescources especially in 
theraded view mode. 
 
System specification for test: Pentium 4 2,4GHz, ASUS Motherboard, 480 MB RAM, SWAP File 1,1 
GB, Windows Server 2003 Enterprise Edition 5.2 including all paches until 15.3.04, IIS 6.0, 
Mercure Mail Server 4, McAffee Virus Scan & Firewall, ELOG 2.5.1 with new eleogd.exe runnig 
as service (system righs) with FireDaemon Lite 1.6GE. 
 
Please note that this problem has been occured under windows (reported for XP, 2000, 2003 
Server) only. Windows NT 4.0 is working well without the new eleodg.exe as well. 
 
 
> This problem has been fixed now, it was a programming bug. New version under 
>  
> http://midas.psi.ch/elog/download/windows/elogd.exe 
 
 

> > Yes, that is what I want.
> 
> I implemented a switch "protect selection page" in revision 1.318, which can be
> obtained at http://midas.psi.ch/cgi-bin/cvsweb/elog/src/elogd.c?rev=1.318. If this
> switch is not set to "1", the selection page can be seen without having to log in.

Stefan,
thank you for the fast implementation of this feature. I compiled the new revision and
it worked as expected.

Kind regards,
Bertram

Thank you Stefan!

1. Will help in the real hard cases!

2. Great! Specially editing adresses or some stutus overviews will be easier with a compleate
overview!

> > 1. Is there a possiblity to fix the position of the attribut fields if they are in
> > the same line? As. ex. if one attribute is empty or contain a very short value it may
> > be possible that the position of the following atrributes in the line are moving to
> > the left, if the value is very long, they move to the right side. This make it
> > sometime not easy to read the informations, specially if the user browses trough some
> > entries, the picture the eyes are scanning is changing.
> 
> Yes there is a possibility. In the format option, you can specify two CSS names, one for the
> attribute and one for it's value. The default ones are "attribname" and "attribvalue". Just
> make new ones by copying these two, renaming it to something like xxxname and xxxvalue where
> "xxxx" is the name of the attribute. You find that in the file themes/default/default.css.
> They contain a field called "width:" which can be changed:
> 
> .typename {
>   width:150px;             <-- must be changed
>   background-color:#CCCCFF;
>   border:1px solid #0000FF;
>   border-top:1px solid white;
>   border-left:1px solid white;
>   padding:3px;
> }
> 
> By having separate classes for all attributed, you can change their width separately,
> accomplishing hopefully what you need.
> 
> > 2. Did I understand you right, that tis will not work while editing? I would like to
> > put this to the wish list for a uppcoming version (not very importand, but VERY nice
> > to have), that it may be possible to use Format in the new and edit mode too, because
> > it is somtimes more comfortable to have some attributes grouped locically in one line
> > or to have a overview over all attributes on one screen without scrolling while editing.
> 
> I will put this on the wishlist.
> 
> Stefan

> > Ok, I think I see now.  I was assuming it applied to the entry form as well.
> 
> Well, good idea. I implemented that. Have a look at this forum (just hit reply to this
> entry) and you'll see it. I'm not completely happy with it (at least on small 1024x768
> screens), but it's configurable anyhow. New version under CVS.

Now that creates an interesting display - especially with the icons and radio buttons. 
But it works!

Thanks.

> > A temporary fix for this is to set summary lines = 0
> 
> Right, that's the only way. I would call this "permanent fix" (;-)

I would too - and it actually produces the output that I wanted to see anyway.

Thanks!

Hi Stefan 
YOu have been a great help on the Elog problem solving .
I have another sort of bug , when i have a attribute type as date.
And i have fixed the attribute on reply , i actually get a string of 
number when i reply , and the date becomes not the orginal date in the 
first message.

So the way i work ard is that i did not place the date field in the fixed  
attribute reply which i will run the risk of pple modifying that entry .
Can this be fix?

Thanks 

Thank you very much Stefan!!!

Also the horizontal alignement with "Format = 1" looks much better   as before
with standard css files! Really great work!

> > Using "List Display = <attributes>" produces an ususal output with the text
> > field content in the first row and a row title of the first 3 letters.
> 
> I fixed that problem. Please get the snapshot from July 28th 14:16.

> > Just compiled 1.410 and have run into an issue that *may* have been
> > introduced in 1.393.
> > 
> > Config file directives such as "Welcome title" could be very long strings. 
> > After compiling 1.410, our "Welcome title" is truncated and, while I haven't
> > counted the actual chars, I suspect that the truncation happens at 1024
> > characters.  The procedure 'getcfg' has a declared passed paramater "int
> > vsize". 
> 
> Actually before 1.393 you got a buffer overflow if any string in the
> configuration file was longer than 500 chars, so it's a miracle that your elogd
> did not crash on the long Welcome Title. I added the "vsize" parameter to avoid
> such crashes. To satisfy your need for a long Welcome title, I increased the
> string size for that particular case to 10000 chars. Hope this is enough.

Hmmm, it is a wonder.  Our welcome text was not significantly longer (about 20
chars longer) so perhaps . . . ?

Thanks, will recompile and report back.