Hi Stefan,

In the past I have requested the "mark whole thread" feature, not yet implimented.  At present, I 
edit (in my case) the icon on the first entry to indicate current status of the thread.  I have 
had an idea connected to this.

If you view a page, in threaded form, and collapsed, the header of the first entry of each thread is 
shown.  The order, however, is that of the timed order of the latest entry in that thread.


As an option, under the same circumstances (threaded, collapsed), if the header of the most recent 
entry was shown, then that could also be an indicator of closed thread, or of "marking whole thread" 
option (maybe would be enough for those who desire those features).  It also gives an indication of 
the current status of the thread without having to edit the original entry of the thread to edit 
(for example) the icon. 

Just a thought on how to improve a wonderful program ;-)

> In the past I have requested the "mark whole thread" feature, not yet implimented.

That's not correct, it is implemented. Just add an attribute for that. Assume you have problem reports, so you 
add

Attributes = ..., Fixed
Options Fixed = boolean
Quick filter = Fixed

If you add a new entry, "Fixed" is false by default. All replies to that entry will contain then the same flag. 
Now if you want to mark the whole thread as fixed, do the following:

- go into list display
- display all entries in threaded mode
- click on "Select"
- select the thread you want to mark as fixed and click "Edit"
- now keep all attributes, but check the "Fixed" check box

and voila, the whole thread will contain "Fixed = 1". Using the quick filter, you can now show all fixed threads 
with one click.

Hi Stefan,

Must have missed it when the fixed/not fixed thread marking got implimented.

Anyhow, my main point would still apply for where the thread is not yet fixed, but is in one of a number of possible
states  (waiting, panic, work-in-progress....).  Clearly you can label the latest entry in a thread with the latest
status, and icon, but when in collapsed mode, you only see the initial entry.  If the latest entry were shown
(optionally), then one can tell at a glance in the collapsed listings which entry may need direct attention.



> > In the past I have requested the "mark whole thread" feature, not yet implimented.
> 
> That's not correct, it is implemented. Just add an attribute for that. Assume you have problem reports, so you 
> add
> 
> Attributes = ..., Fixed
> Options Fixed = boolean
> Quick filter = Fixed
> 
> If you add a new entry, "Fixed" is false by default. All replies to that entry will contain then the same flag. 
> Now if you want to mark the whole thread as fixed, do the following:
> 
> - go into list display
> - display all entries in threaded mode
> - click on "Select"
> - select the thread you want to mark as fixed and click "Edit"
> - now keep all attributes, but check the "Fixed" check box
> 
> and voila, the whole thread will contain "Fixed = 1". Using the quick filter, you can now show all fixed threads 
> with one click.

> Hi Stefan,
> 
> Must have missed it when the fixed/not fixed thread marking got implimented.
> 
> Anyhow, my main point would still apply for where the thread is not yet fixed, but is in one of a number of possible
> states  (waiting, panic, work-in-progress....).  Clearly you can label the latest entry in a thread with the latest
> status, and icon, but when in collapsed mode, you only see the initial entry.  If the latest entry were shown
> (optionally), then one can tell at a glance in the collapsed listings which entry may need direct attention.

If you always mark the whole thread with states (waiting, panic, work-in-progress,...) as described in my last posting, 
then you will see this from the thread initial entry as well. If you use icons, then even more. The only disadvantage 
is that you have to discipline yourself always modifying the whole thread and not only one entry in that thread.

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

Hi,

I was wondering if anybody else seen this problem and maybe has a solution. I use Elog version 2.7.5 rev. 2172 that I compiled from the tar.gz package on a Ubuntu PC. It is very strange that everything works fine except I can not view / download PDF attachments specifically. I can view / download images and I can download all sorts of file formats: xls, doc, ppt, etc. Viewing in the same window / tab or in a different one does not work. Saving the attachment produces a file empty file with the correct name! This is so strange, for example following a link from an image or any other attachment type works but if that link is a PDF file I get an empty page! When uploading a PDF file there a thumbnails that are generated, I do view the thumbnail but not the PDF itself! I didn't even managed to start a download on PDF attachment.

Any help would be appreciated!

This sounds to me like you have a problem on your browser. I know that Acrobat Reader sometimes causes problems. The current version always crashes my broswer, so I cannot display PDFs inline, I rather have to same them, and the open them for display. Maybe you have a simlar problem. Since you see the PDF thumbnails, I believe that the PDF operations indise ELOG are ok. Can you view PDFs from other websites? Have you tried another browser? Maybe on another computer?

- Stefan 

Hi,

Thanks for the reply. I just checked the access from two other computers and indeed it works. I tried to see what is the problem with my browser, I use Firefox 3.0.6 and tried to get a PDF from the web. So I do have the same problem with other sites for viewing a PDF, I mean when I click on a PDF link I get a white page and the browser does not invoke any plug-in or Acrobat Reader. But the major difference with Elog is that with other sites I can always right click on the link and do "Save as" and it starts the download and I get a valid file. With elog it does start the download but I get an empty file. Actually I checked inside and it is not really empty, it is a text file, here I attached an example (the content of the file when I tried to download a PDF from the Elog server):

gornea@hadriana ~
$ cat Ba_source_GG_Feb09.pdf
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<title>ELOG Login</title>
<link rel="stylesheet" type="text/css" href="default.css">
<link rel="shortcut icon" href="favicon.ico" />
<link rel="icon" href="favicon.png" type="image/png" />
</head>
<body OnLoad="document.form1.uname.focus();">
<form name=form1 method="POST" action="./" enctype="multipart/form-data">

<input type=hidden name=redir value="090219_111057/Ba_source_GG_Feb09.pdf">
<table class="dlgframe" cellspacing=0 align=center><tr><td colspan=2 class="dlgtitle">Please login</td></tr>
<tr><td align=right class="dlgform">Username:</td>
<td align=left class="dlgform"><input type=text name=uname value=""></td></tr>
<tr><td align=right class="dlgform">Password:</td>
<td align=left class="dlgform"><input type=password name=upassword></td></tr>
<tr><td align=center colspan=2 class="dlgform"><input type=checkbox checked name=remember value=1>
Keep me logged in on this computer<br>
for the next 31 days or until I log out</td></tr>
<tr><td align=center colspan=2 class="dlgform">
<a href="?cmd=Forgot">Forgot password?</a></td></tr>
<tr><td align=center colspan=2 class="dlgform"><input type=submit value="Submit"></td></tr></table>
<center><a class="bottomlink" title="Goto ELOG home page" href="https://midas.psi.ch/elog/">ELOG V2.7.5-2172</a></center></form></body></html>
 

The file you downloaded is actually the login screen of elog! So probably your login token expired between the display of the web page showing the attachemnt link and the attachment download, or you turned cookies off. So when you try to download the attachment, your user credentials are not passed as cookies together with that request and elog barks at you requiring a new login.  

 Hi,

OK but the box at login is checked to keep the login / password for 31 days and the cookies are enabled for sure. Now another user pointed out that it can not see pictures including the little icons when using Safari. I never used Safari but I got it just to see what is going on. So it took me some time but I think I have an idea now after comparing the source of a post that I read with Firefox to the one I get with Safari. Essentially the Firefox has the Javascript functions and class definitions before the HTML page starts. Very weird! Took me some time because when you view the source they both showed almost the same content (there are a few differences in <head>) ! But when I tried to save as HTML it showed this difference. Also I must mention that the problem for viewing the pdf attachments only happens with Firefox on Windows, I tried from a Linux PC and it works fine, now on Linux PC I have an older version of Firefox so maybe this has to do with Firefox version not OS. For this problem with the pictures and icons, if is not the Javascript related problem I am really totally last, how can one browser get the picture but not the other browser with the same content in the <body>!?!

 Hi Stefan,

I added a new logbook for test and posted a message with three attachments: picture file, PDF file and excel file. Could you log in and look if I did something obviously stupid? The link is:

http://exo-elog.stanford.edu/Test+logbook/

User name: testUser
Password: go

I have this specific problem with the PDF attachments and I can not see any picture or the icons with Safari. Thanks a lot!

Stefan,

I finally got it installed on a server at work (only took a year to work through all the red tape). I have seven logbooks up and running and only one is giving me trouble. It is an On-Line Help book where I wanted to store documents that could be referenced by our staff. It is the simplest of my logbooks (see config file below) but when I hit the "Submit" button it crashes the program. I can not see the error myself but the server guys are telling me that that we are getting an "Internal error, no valid header!" error. The only other thing that I can think to mention is that the entry that is crashing the program is a 60k Microsoft word table that I had cut and pasted into elog.

Thank you, Mike

[OnlineHelps]
Write Password = SWNlQ3ViZQ==
;DISPLAY
Theme = default
Display mode = threaded
Mode Commands = 0

Thread display = --------------  $Title  --------------
Comment = On-Line Helps

Attributes = Title

Required Attributes = Title
Page Title = ELOG - $subject
Reverse sort = 0
 

Ah, that rings a bell. We recently had problems with large tables. Can you try the current version if you get the same problem? 

Is there any way I can limit the ammount of characters in the Subject line?

Thank you,

 Use the

Format Subject = ...

option as described in the manual. The last parameter is the "maximum number of characters allowed".

Is there a way, option, feature to setup the text section only to be scrollable when viewing a log entry, such that the header (meta info) section stays fixed?

Unfortunately no.

Well, I tinkered a bit with a journal entry display page and found that without having to suggest the flavor-of-the-month web design mantra of "replace table layout with CSS only",  just a few CSS tweaks can enable exactly what I am desiring.

For your consideration, here are the tweaks I made to get a fixed header and footer section with a scrollable journal entry section in the middle:

1. moved the journal entry content and footer line (elog version info) out of the layout table structure, into their own div sections;
2. in the style sheet, added attribute "position:fixed" to the "frame table" section;
3. in the style sheet, added attribute sections for journal entry content and footer div sections:
   1. #content: overflow:auto;position:fixed;top:230px;bottom:30px;width:100%;
   2. #footer:  text-align:center;bottom:0;position:fixed;width:100%;

Now as I'm not a web designer by trade and not intimately familiar with CSS nuances, I used the time honored method of documentation lookup with trial and error.

In any case, it worked and displays exactly the way I wanted; please do consider this for a future elog release.

Bill

Apparently you downloaded an ELOG page and modified it manually. Can you send me the modified page, it then would be easier for me to implement it (I can shorten "my" trial and error phase..)

Yes, you are correct, I did simply take a sample page from logs and tinker with the html and css file, with the changes enumerated previously.  I have attached the tweaked sample html elog log page and css file, along with a few of the standard elog png files to complete the page with some semblance of the normal display.

 Yes it's on my personal to-do list, but don't know when I will find some time.

I am using the following commands to display the text of all of the entries at once (so that you can read them without having to click on each entry).

Display mode = threaded
Expand Default = 3

Problem is that the information on the page is packed so tightly together (no white space) that it can be hard to read. Especially with single line entries.

Is it possible to automatically append a new line to a routine entry?

THANK YOU for your assistances.

Please tell me how to share my elog with people.

 Connect your PC to the internet and tell everybody the URL. Make sure the Windows Firewall allows remote access.