Hi Stefan,

I attached a 12 page (22kB) pdf file - no images - to an entry, but elog only converted the first 8 pages to
images (.png).  This is reproducable, i.e. a different small multipage pdf file produced the same number of images.

The size of the pdf file does not seem to be a problem, a single page pdf file with a lot of images in it
attached as expected.

Is this correct, or a defined limitation?

> Hi Stefan,
> 
> I attached a 12 page (22kB) pdf file - no images - to an entry, but elog only converted the first 8 pages to
> images (.png).  This is reproducable, i.e. a different small multipage pdf file produced the same number of images.
> 
> The size of the pdf file does not seem to be a problem, a single page pdf file with a lot of images in it
> attached as expected.
> 
> Is this correct, or a defined limitation?

This is a defined limitation. Sometimes people attach whole books in PDF form to an entry, and you don't want to end up 
with hundreds of images cluttering your browser. If you want to see the full document, just load it into your PDF viewer.

> > Hi Stefan,
> > 
> > I attached a 12 page (22kB) pdf file - no images - to an entry, but elog only converted the first 8 pages to
> > images (.png).  This is reproducable, i.e. a different small multipage pdf file produced the same number of images.
> > 
> > The size of the pdf file does not seem to be a problem, a single page pdf file with a lot of images in it
> > attached as expected.
> > 
> > Is this correct, or a defined limitation?
> 
> This is a defined limitation. Sometimes people attach whole books in PDF form to an entry, and you don't want to end up 
> with hundreds of images cluttering your browser. If you want to see the full document, just load it into your PDF viewer.

Thanks, Stefan (why is this answer down under my name!?)

I couldn't find reference to this in the documentation.  In the case I referred to, I'll have to play with the pdf so that
the six pages I actually want displayed are.

Hi

Would it be possible to use the "Export to:" function with IE7 on the Forum logbook, and save the logbook.

I can do the export but saving the file with IE7 does not work. Saving the file with Firefox, Chrome, Safari works.

This makes me think that E-log is good and IE7 is bad ?

Soren

Right   

It seems to be a well known probmel with IE: http://classicasp.aspfaq.com/files/directories-fso/how-do-i-send-the-correct-filename-with-binarywrite.html 

So I tried all variations there, but none of them worked. The interesting thing is that it works if you use it locally, but not with the forum (which has an additional "/elogs" in the URL).

 Problem resolved.

We use eLOG with IE. Once we turned on SSL, it is no longer possible to "Export to CSV" and save the output.

The error that we get is:

Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later.

This is documented on Microsoft's site: http://support.microsoft.com/kb/316431

It is considered a feature with no fix. Basically the browser is honoring a request from the server which is "Pragma: no-cache". Problem can be reproduced in IE versions 6 through 8.
 

I see the same problem with IE. The knowledge base says that one should remove the "no-cache" statement from the header, but that has strange side effects: Assume you export a logbook to a CSV file, and a few days later you export it again, since many things changed. But you browser will in that case not retrieve the new logbook, but read the old CSV file from the cache. But the browser does not tell you this, so you see an old version of the logbok without knowing this, which can be dangerous. So I better leave the "no-cache" in the header. The workaroung is not to click on "Save" on the file download dialog, but on "Open". You see then the CSV data inside the browser and can copy/paste it into a notepad document, then save it. 

 Ah, now this is humorous, when the client first came to me, that was almost exactly the work around I gave him, open it, CTRL-A to highlight it all, CTRL-C to copy it, Move to the excel spreadsheet, CTRL-V to paste it into Excel. Select Data, Text to Columns, and you have an Excel Spreadsheet.   They wanted me to post the change in function anyway, though I told Vamsi, "just watch, someone will post the same workaround that I already gave to the clients".  So you see why I find it amusing.  I would say Great Minds Think Alike, but that would be giving myself a bit too much credit (grin).  First, thank you for proving me right on my prediction and if you should happen to make a change that would get around this SSL change in behavior, it would make a group of manufacturing types that are not quite as comfortable with computers as we are, very happy.   Please let us know.

I can easily remove the "no-cache" from the header, but as I wrote you, people can then shoot themselves into the foot by getting an old document, and I guess they become even less happy then. So you tell me which way you prefer. 

 Trust me, I don't want them getting old data either.. that would be a nightmare..

of course, the little voice at the back of my head (note, not IN the back of my head) has offered up this tidbit for you to consider.

Stefan, would it be possible to make the following change so that the document is not cached and at the same time it is possible to save it.

The change would entail replacing the "Pragma: no-cache" directive with an "Expires: " <HTTP-date> where <HTTP-date> is the same as Date header value. Please see section 14.21 of http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

Hopefully there are no other side effects to this change.

 You can also try to use a different browser.

Soren

ok, so I removed the "Pragma: no-cache". With IE it looks fine now, and if I repeat it two times it always gets is from elog and not from the cache due to the "Expires:" statement. The "no-cache" came from old days when some browsers did not yet support the "Expires" tag. I hope that this is better now, so let's see when we get the first complaints. The modification is in SVN revision 2265.

 This seems to work fine.

Hello Stefan,

how can I activate the part like: Subscribe to logbooks: Linux Demo, Database, etc.. regarding enable automatic email notifications

like below

Discussion forum about ELOG  Logged in as "Heinzmann"

Login name: Full name: Email: Subscribe to logbooks: (enable automatic email notifications) Linux Demo Database Forum Config Examples Contributions Vulnerabilities

Thank you very much,

Just check the check boxes:

Isn't that obvious?

Sorry wrong question, I meant how can I configure this part?

There is nothing to activate. As soon as you have some logbooks defined and you are using user level access ("password file = ..."), this page will show up. 

 Sorry,

was my mistake, may I,m a little bit stressed.

cheers,

Michael

There is one "feature" which causes this not to work. If an option is present several times (in your case "Show Attributes Edit"), the first one is taken which fulfills the current condition(s). So what happens is you select List=Personal, which triggers condition "1". Then you select "Dummy1", which triggers condition "11". Now elog goes top down, finds that List=Personal, so sets condition "1", then continues, finds {1} Show Attributes Edit = ... and takes this one. What I propose is to do the following:

Options List = Personal{1}, Work{2}
...
{3} Show Attributes Edit = List, Project, SubProject, Title, Priority, Context, Status, Due Date, Start Date, Alarm, Repeat
{3} Options SubProject = DummyChild1
{1} Show Attributes Edit = List, Project, Title, Priority, Context, Status, Due Date, Start Date, Alarm, Repeat
{1} Options Project = Dummy1{3}

Note that {3} Show Attributed Edit come before {1} Show Attributes Edit, so as soon as you select "Dummy1", the first "Show Attributes Edit" gets 
activated which contains "SubProject".

Options List = Personal{1}, Work{2}
...
{3} Show Attributes Edit = List, Project, SubProject, Title, Priority, Context, Status, Due Date, Start Date, Alarm, Repeat
{3} Options SubProject = DummyChild1
{1} Show Attributes Edit = List, Project, Title, Priority, Context, Status, Due Date, Start Date, Alarm, Repeat
{1} Options Project = Dummy1{3}

Note that {3} Show Attributed Edit come before {1} Show Attributes Edit, so as soon as you select "Dummy1", the first "Show Attributes Edit" gets 
activated which contains "SubProject".

 Thank you ... good to know about these elog features. Works fine now!!!

It is occasionally convenient to be able to put the Edit button at the beginning of the line in list view, e.g. when pages are wider than the screen it saves having to scroll across to find it.  Would it be possible to do something similar with the Attachments button?

regards

Steve

I don't understand what you mean. There is only a "Submit" button and a "Choose File" button:

both are pretty close to the beginning of the line (left side).

Hi Stefan and Steve,

Do you mean putting the paperclip icon to the left of the 'Thread display' (such as next to the emoticons and
other stuff we can put in this forum)?

I'd be happy with that if it overwrote the "+" in the threaded, collapsed mode; or
that there was a reserved position for the icon in threaded (any variant), and if no 
attachment, just a blank.  

Or make it something to configure, thus ruining Stefan's weekend and confusing the rest of us ;-)

Regards,

David.



<p>
<table width="98%" align="center" cellspacing="1" style="border:1px solid #486090;">
<tbody>
<tr>
<td cellpadding="3px" style="background-color:#486090; font-weidht:bold; color:white;">Stefan Ritt wrote:</td></tr>
<tr>
<td cellpadding="10px" style="background-color:#FFFFB0;"><p>
<table width="98%" align="center" cellspacing="1" style="border:1px solid #486090;">
    <tbody>
        <tr>
            <td cellpadding="3px" style="background-color:#486090; font-weidht:bold; color:white;">Steve
Williamson wrote:</td>
        </tr>
        <tr>
            <td cellpadding="10px" style="background-color:#FFFFB0;">
            <p>It is occasionally convenient to be able to put the Edit button at the beginning of the line in
list view, e.g. when pages are wider than the screen it saves having to scroll across to find it.&nbsp; Would it
be possible to do something similar with the Attachments button?</p>
            <p>regards</p>
            <p>Steve</p>
            </td>
        </tr>
    </tbody>
</table>
</p>
<p>I don't understand what you mean. There is only a &quot;Submit&quot; button and a &quot;Choose File&quot;
button:</p>
<p><a href="091113_143107/Capture.png?lb=Forum"><img border="0" alt="Capture.png" name="att0" id="att0"
src="091113_143107/Capture.png?lb=Forum&amp;thumb=1" /></a>&nbsp;</p>
<p>both are pretty close to the beginning of the line (left side).</p></td>
</tr>
</tbody>
</table>
</p><p> </p>

Hello.

Please look at the entry 66525 of this forum (just 5 thread before this one):

 ->  chain.crt, posted by Gerhard Schneider on Thu Sep 3 21:55:52 2009         (66525)
  |->    Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009       (66526)
  |->    Re: chain.crt, posted by Gerhard Schneider on Wed Oct 7 07:56:52 2009 (66556)

When you collapse the thread, it is collapsed to the 66526 instead of the 66556 (more recent)

  +      Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009  

I guess it is because both 66526 and 66556 replies to the first entry. 
I have the same problem with Elog v2.7.7-2246 and Windows. 

In general, it seems to work well only if you always reply to the last entry of a thread.

  Thank you.


b.t.w. : is there any tip to always force reply to the last entry of a thread?

> Hello.
> 
> Please look at the entry 66525 of this forum (just 5 thread before this one):
> 
>  ->  chain.crt, posted by Gerhard Schneider on Thu Sep 3 21:55:52 2009         (66525)
>   |->    Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009       (66526)
>   |->    Re: chain.crt, posted by Gerhard Schneider on Wed Oct 7 07:56:52 2009 (66556)
> 
> When you collapse the thread, it is collapsed to the 66526 instead of the 66556 (more recent)
> 
>   +      Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009  
> 
> I guess it is because both 66526 and 66556 replies to the first entry. 
> I have the same problem with Elog v2.7.7-2246 and Windows. 
> 
> In general, it seems to work well only if you always reply to the last entry of a thread.
> 
>   Thank you.
> 
> 
> b.t.w. : is there any tip to always force reply to the last entry of a thread?

As the person who suggested this concept, I have to admit I've yet to think of a good way around this issue. 
Preventing "branching" is all very well, but sometimes it is relivent to have a branch (although I usually try to
avoid them).  Unless elog scans every possible branch to find where the latest entry, I cannot think of a
foolproof, practical scheme.

> Hello.
> 
> Please look at the entry 66525 of this forum (just 5 thread before this one):
> 
>  ->  chain.crt, posted by Gerhard Schneider on Thu Sep 3 21:55:52 2009         (66525)
>   |->    Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009       (66526)
>   |->    Re: chain.crt, posted by Gerhard Schneider on Wed Oct 7 07:56:52 2009 (66556)
> 
> When you collapse the thread, it is collapsed to the 66526 instead of the 66556 (more recent)
> 
>   +      Re: chain.crt, posted by Stefan Ritt on Fri Sep 4 08:33:16 2009  
> 
> I guess it is because both 66526 and 66556 replies to the first entry. 
> I have the same problem with Elog v2.7.7-2246 and Windows. 
> 
> In general, it seems to work well only if you always reply to the last entry of a thread.
> 
>   Thank you.
> 
> 
> b.t.w. : is there any tip to always force reply to the last entry of a thread?

I fixed that in revision 2269. So now elog scans a complete branch and searches for the last entry in the branch. 
You can check again the branch above on the forum, should work now.

Internet Explorer fails to display correctly some aspects of pages generated by elog when the zoom functionality is used (Ctrl + and Ctrl -).  This is really a bug in the IE renderer rather than elog, but since IE can be persuaded to do better relatively easily it might be worth making some minor changes to make elog more robust when used with the buggy Microsoft browser.

The problem I encountered was initially with the multiple checkboxes for an Moptions attribute, but I noticed later it also affects the logbook tabs at the top of the screen.  If you start creating a submission to this forum in IE (7 or earlier, at least) you can see the problem; when zooming, the text labels and  the checkboxes do not scale together so start overlapping, and the same happens with the logbook tabs and the text links on them.  The problem is apparently to do with a proprietary IE concept called "layout" - see http://www.satzansatz.de/cssd/onhavinglayout.html for details - and IE struggles when some elements do not have the hasLayout property set to "true".

The fix is to coerce elements to have the hasLayout element set to "true" by giving them some benign CSS property.  The best I can find is to set "display: inline-block" for some of the key elements, and this can be done by modifying default.css rather than the elogd.c code.

Adding

span {
  display: inline-block;
}

to default.css (e.g. just after the default style definition for the "td" element) and adding

  display: inline-block;

to the style sets for the .sltab and .ltab classes (generic, not those specific to the "a" element) seems to prevent IE doing bad things with the display when zooming without messing up the display in Firefox.  I have not tested this comprehensively or in any other browsers, but I thought it might be worth passing on.

Cheers,

Richard Stamper

I just tried with IE8 (don't have IE7 installed any more), and it looked to me like this has been fixed there. So this will get less a problem in the future. If people are stuck to IE7, they can made your modification themselves in the CSS file, so I guess I won't change the distribution for the moment.