Attribute and checkbox, posted by Arno Teunisse on Sun Sep 3 21:57:00 2006 
|
In the screen shots I see checkboxes before the attributes. How can I do that ??
In the doc I saw Options <attribute> = boolean. But that creates a checkbox in the fill in form after the attribute. See second attached picture. The first attached picture shows what I want but I can only get the result in the second picture. Can anybody help me in this one. ( Is there an option checked for the attributes ? |
Re: Attribute and checkbox, posted by Arno Teunisse on Mon Sep 4 22:36:03 2006
|
In the screen shots I see checkboxes before the attributes. How can I do that ??
In the doc I saw Options = boolean. But that creates a checkbox in the fill in form after the attribute. See second attached picture. The first attached picture shows what I want but I can only get the result in the second picture. Can anybody help me in this one. ( Is there an option checked for the attributes ?
Just answer it myself : I thought of the checkboxes in front of the attributes as boolean. However, it has to to with the browse feature filtered browsing =1= In this way you can, when checking one of the checkboxes, browse to the same item clicking the next and previous button. Sorry , my question was about RTFM ( Read The Fucking Manual ) So this question is solved.
However , it would be nice to have a checkbox in front of one attribute. Suppose you have a lot a entries in a record ,that are readonly( predefined). The user of the form must only confirm that a job is done by checking the checkbox without going to the edit mode. So, the checkbox is writable in readonly mode. I can inmagine something like : attribute record check = attribute in the configuration file. In this way the user of the form says : job done.
There can be only one checkbox for the record.
[ job done] [ customer ] [ activity ] [ What should be done ]
[X] BLA Check job1 Backup mail check
[] BLA1 Check job2 check error report
[X] Bla2 Check job3 check MQ jobs
Is this possible ?? It's just an idea
Thanks for your reading this |
|
Re: Attribute and checkbox, posted by Stefan Ritt on Fri Sep 22 08:55:22 2006
|
Well, what we use for such kind of check lists is the following:
Use Preset test = file.txt where file.txt contains exactly the ASCII code you mentioned, like
[ job done] [ customer ] [ activity ] [ What should be done ]
[] BLA Check job1 Backup mail check
[] BLA1 Check job2 check error report
[] Bla2 Check job3 check MQ jobs
So one can put the "X" in the "[]" manually. I know, the individual lines are no real elog attributes, but it works nicely for some check lists. Drawback might be that a use can edit the whole text, but sometimes I find that's even a plus, since the user might add some comments. |
Email substitution quit working, posted by David Spindler on Tue Aug 29 15:28:51 2006
|
I have recently upgraded from the 2.6.0-beta (I believe) to 2.6.2-1699. I just found out that on the day I upgraded, email substitution has stopped working. I have checked the discussion area and all the documentation and do not see any clues. The debug_log.txt file shows that the emails are being processed, but the fields are not being substituted correctly.
Thanks, in advance for any help,
David
*********************************************
;***** EMAIL SECTION:
Email All = 494475@emc.work.com, 494476@emc.work.com, $user_email, $Emp#@emc.work.com
Use Email Subject = Facility Maintenance Vehicle Elog Entry
Use Email From = facmx_vehicle_elog@work.com
Use Email Heading = "A new entry has been made on the AOC Vehicle Elogbook. Do NOT reply to this email."
;Set default encoding to 1 for plain text. Elcode and html not usable for EMC2 email. 0 = elcode, 2 = html
Default encoding = 1
MOptions Email To = Aoc Managers, AOC, CTC, WHQ, WTC, Offsite, Facility Management, All
Email "Email To" All = aoc-techs@emc.work.com, ctc-mech@emc.work.com, whq-techs@emc.work.com, wtc-tech@emc.work.com, rttechs@emc.work.com, rtffmteam@emc.work.com
Email "Email To" Aoc Managers= aoc-managers@emc.work.com
Email "Email To" "AOC" = aoc-techs@emc.work.com
Email "Email To" "CTC" = ctc-mech@emc.work.com
;***** EMAIL SECTION:
Email All = 494475@emc.work.com, 494476@emc.work.com, $user_email, $Emp#@emc.work.com
Use Email Subject = Facility Maintenance Vehicle Elog Entry
Use Email From = facmx_vehicle_elog@work.com
Use Email Heading = "A new entry has been made on the AOC Vehicle Elogbook. Do NOT reply to this email."
;Set default encoding to 1 for plain text. Elcode and html not usable for EMC2 email. 0 = elcode, 2 = html
Default encoding = 1
MOptions Email To = Aoc Managers, AOC, CTC, WHQ, WTC, Offsite, Facility Management, All
Email "Email To" All = aoc-techs@emc.work.com, ctc-mech@emc.work.com, whq-techs@emc.work.com, wtc-tech@emc.work.com, rttechs@emc.work.com, rtffmteam@emc.work.com
Email "Email To" Aoc Managers= aoc-managers@emc.workcom
Email "Email To" "AOC" = aoc-techs@emc.work.com
Email "Email To" "CTC" = ctc-mech@emc.work.com |
|
Re: Email substitution quit working, posted by David Spindler on Tue Sep 5 15:59:47 2006
|
| David Spindler wrote: | I have recently upgraded from the 2.6.0-beta (I believe) to 2.6.2-1699. I just found out that on the day I upgraded, email substitution has stopped working. I have checked the discussion area and all the documentation and do not see any clues. The debug_log.txt file shows that the emails are being processed, but the fields are not being substituted correctly.
Thanks, in advance for any help,
David
|
I have not been able to find anything wrong in my config file, so I replaced 2.6.2 with 2.6.1 (apparently that was what I was running last, not the 2.6.0-beta) and my troubles have disappeared.
Anybody have any idea what has happened? |
|
Re: Email substitution quit working, posted by Stefan Ritt on Fri Sep 22 08:50:08 2006
|
| David Spindler wrote: |
| David Spindler wrote: | I have recently upgraded from the 2.6.0-beta (I believe) to 2.6.2-1699. I just found out that on the day I upgraded, email substitution has stopped working. I have checked the discussion area and all the documentation and do not see any clues. The debug_log.txt file shows that the emails are being processed, but the fields are not being substituted correctly.
Thanks, in advance for any help,
David
|
I have not been able to find anything wrong in my config file, so I replaced 2.6.2 with 2.6.1 (apparently that was what I was running last, not the 2.6.0-beta) and my troubles have disappeared.
Anybody have any idea what has happened? |
This problem has been fixed in revision 1712. So I made an 2.6.2-2 for the Windows community just now. Please upgrade. |
Top Text and Bottom Text only show "text" --- no files, posted by Steve Jones on Thu Aug 31 21:46:15 2006
|
| Just compiled 2.6.2-1714 and "Top text" and "Bottom text" interpret everything as "text" --- nothing is interpreted as a file to be included, unless there is a new syntax. |
|
Re: Top Text and Bottom Text only show "text" --- no files, posted by Steve Jones on Tue Sep 5 19:46:05 2006
|
| Steve Jones wrote: | | Just compiled 2.6.2-1714 and "Top text" and "Bottom text" interpret everything as "text" --- nothing is interpreted as a file to be included, unless there is a new syntax. |
I dropped back to SVN1699 and same problem, then moved the file to the elog root directory and it works fine. Seems that the current version isn't finding the file, regardless of where I put it (root or in 'resources' directory). Perhaps another directory? |
|
Re: Top Text and Bottom Text only show "text" --- no files, posted by Steve Jones on Tue Sep 5 20:23:40 2006
|
| Steve Jones wrote: |
| Steve Jones wrote: | | Just compiled 2.6.2-1714 and "Top text" and "Bottom text" interpret everything as "text" --- nothing is interpreted as a file to be included, unless there is a new syntax. |
I dropped back to SVN1699 and same problem, then moved the file to the elog root directory and it works fine. Seems that the current version isn't finding the file, regardless of where I put it (root or in 'resources' directory). Perhaps another directory? |
Stefan, I found the source of the problem. When you moved some files to "logbook_dir" you also told the code to look in "logbook_dir" for top and bottom text files:
void show_bottom_text(LOGBOOK * lbs)
{
char str[NAME_LENGTH], slist[20][NAME_LENGTH], svalue[20][NAME_LENGTH];
int i, size;
if (getcfg(lbs->name, "bottom text", str, sizeof(str))) {
FILE *f;
char file_name[256], *buf;
if (str[0]) {
/* check if file starts with an absolute directory */
if (str[0] == DIR_SEPARATOR || str[1] == ':')
strcpy(file_name, str);
else {
strlcpy(file_name, logbook_dir, sizeof(file_name));
strlcat(file_name, str, sizeof(file_name));
}
The documentation indicates that the location dir should be "resource_dir". |
|
Re: Top Text and Bottom Text only show "text" --- no files, posted by Stefan Ritt on Fri Sep 22 08:21:39 2006
|
| Steve Jones wrote: | | Stefan, I found the source of the problem. When you moved some files to "logbook_dir" you also told the code to look in "logbook_dir" for top and bottom text files. The documentation indicates that the location dir should be "resource_dir". |
Yepp. I changed the documentation. Note that you can also specify an absolute path, like
/usr/local/elog/top.html
If the file name starts with a "/" (under Unix), the full path is taken instead of looking in the logbook directory. |
|
new entry form - "minimalist" approach , posted by frederic poncin on Mon Sep 18 16:53:09 2006
|
I'm playing with the configuration files in order to produce a "minimal" form.
At this time, I did not succeed in removing the following components:
- the "Fields marked with * are required" field
- the "Entry time:" field
- the "encoding ELCode / plain / HTML" field
- the "preview" button
- the duplication of the Submit/Preview/Back buttons on the top and the bottom of the page.
Is any of this possible?
--
Frédéric Poncin |
|
Re: new entry form - "minimalist" approach , posted by Stefan Ritt on Fri Sep 22 07:54:58 2006
|
| frederic poncin wrote: | I'm playing with the configuration files in order to produce a "minimal" form.
At this time, I did not succeed in removing the following components:
- the "Fields marked with * are required" field |
This is handled by
Required attributes = ...
so just remove this line completely if you don't need them.
| frederic poncin wrote: |
- the "Entry time:" field
- the "encoding ELCode / plain / HTML" field
- the "preview" button
- the duplication of the Submit/Preview/Back buttons on the top and the bottom of the page.
|
These fields are always present and cannot be turned off. If you are concerned about screen space (PDA\?), you can change the CSS file for smaller fonts etc. |
|
Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Mon Sep 18 15:21:56 2006
|
| Steve Jones wrote: | The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
|
I don't understand your problem. If I use following config file:
[demo]
Theme = default
Attributes = Author, CRState, ApprovedDate, CompletedDate
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
and make an entry, then edit it, selecting approved, then submit, then edit again, then select completed, then I get following:
which looks ok to me (the previous ApprovedDate does not get blanked out). Can you reproduce that behaviour? |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Mon Sep 18 18:19:44 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: | The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
|
I don't understand your problem. If I use following config file:
[demo]
Theme = default
Attributes = Author, CRState, ApprovedDate, CompletedDate
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
and make an entry, then edit it, selecting approved, then submit, then edit again, then select completed, then I get following:
which looks ok to me (the previous ApprovedDate does not get blanked out). Can you reproduce that behaviour? |
| Quote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
|
|
Re: Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Tue Sep 19 17:32:28 2006
|
| Steve Jones wrote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
No, even with that it does not get blanked out. Attached is the complete elogd.cfg with which it works fine in my case (R1714). Can you try that? |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Tue Sep 19 19:22:31 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
No, even with that it does not get blanked out. Attached is the complete elogd.cfg with which it works fine in my case (R1714). Can you try that? |
| Quote: |
Stefan, when I try that config in a demo logbook in my installation *but with all other items in [global] I get the same field-blanking behavior. I am going to try going back to a completely pristine .cfg, but I suspect this will work fine. I will need to add back in configuration items until I run into the culprit.
Ok, I found it. Try this config:
[global]
port = 8080
[demo]
Comment = Test
Attributes = Author, CRState, ApprovedDate, CompletedDate
Locked Attributes = ApprovedDate, CompletedDate
Type CompletedDate = date
Type ApprovedDate = date
Format CompletedDate = 1
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
Setting the "Type" to "date" causes the blanking to occur.
|
|
|
Re: Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Tue Sep 19 20:28:15 2006
|
| Steve Jones wrote: |
Setting the "Type" to "date" causes the blanking to occur.
|
Ok, then don't set the "Type" to "date"  |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Tue Sep 19 20:38:49 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: |
Setting the "Type" to "date" causes the blanking to occur.
|
Ok, then don't set the "Type" to "date" |
| Quote: |
Yuk! Thanks!
|
|
|
Why are Preset fields blanked out?, posted by Steve Jones on Thu Sep 14 22:59:39 2006
|
The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
|
|
Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Mon Sep 18 15:21:56 2006
|
| Steve Jones wrote: | The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
|
I don't understand your problem. If I use following config file:
[demo]
Theme = default
Attributes = Author, CRState, ApprovedDate, CompletedDate
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
and make an entry, then edit it, selecting approved, then submit, then edit again, then select completed, then I get following:
which looks ok to me (the previous ApprovedDate does not get blanked out). Can you reproduce that behaviour? |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Mon Sep 18 18:19:44 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: | The snippet of code below sets an attribute to a date depending on the selection. Problem is, if attribute ApprovedDate was previously set, selecting any other value for CRStatus will blank out ApprovedDate (the same occurs for CompletedDate). Why would this be occurring when the conditionals are mutually exclusive?
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
|
I don't understand your problem. If I use following config file:
[demo]
Theme = default
Attributes = Author, CRState, ApprovedDate, CompletedDate
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
and make an entry, then edit it, selecting approved, then submit, then edit again, then select completed, then I get following:
which looks ok to me (the previous ApprovedDate does not get blanked out). Can you reproduce that behaviour? |
| Quote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
|
|
Re: Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Tue Sep 19 17:32:28 2006
|
| Steve Jones wrote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
No, even with that it does not get blanked out. Attached is the complete elogd.cfg with which it works fine in my case (R1714). Can you try that? |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Tue Sep 19 19:22:31 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: |
I think I found it. Try this:
Locked Attributes = ApprovedDate, CompletedDate
##################################################
# Define CRState
#
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
In my config when I remove the two attributes from "LOCKED ATTRIBUTES" the fields do not get blanked out.
|
No, even with that it does not get blanked out. Attached is the complete elogd.cfg with which it works fine in my case (R1714). Can you try that? |
| Quote: |
Stefan, when I try that config in a demo logbook in my installation *but with all other items in [global] I get the same field-blanking behavior. I am going to try going back to a completely pristine .cfg, but I suspect this will work fine. I will need to add back in configuration items until I run into the culprit.
Ok, I found it. Try this config:
[global]
port = 8080
[demo]
Comment = Test
Attributes = Author, CRState, ApprovedDate, CompletedDate
Locked Attributes = ApprovedDate, CompletedDate
Type CompletedDate = date
Type ApprovedDate = date
Format CompletedDate = 1
Options CRState = PENDING{a}, APPROVED{b}, HOLD{a}, REJECTED{a}, COMPLETED{c}
{a}
{b} Preset ApprovedDate = $date
{c} Preset CompletedDate = $date
Setting the "Type" to "date" causes the blanking to occur.
|
|
|
Re: Re: Why are Preset fields blanked out?, posted by Stefan Ritt on Tue Sep 19 20:28:15 2006
|
| Steve Jones wrote: |
Setting the "Type" to "date" causes the blanking to occur.
|
Ok, then don't set the "Type" to "date" |
|
Re: Re: Why are Preset fields blanked out?, posted by Steve Jones on Tue Sep 19 20:38:49 2006
|
| Stefan Ritt wrote: |
| Steve Jones wrote: |
Setting the "Type" to "date" causes the blanking to occur.
|
Ok, then don't set the "Type" to "date" |
| Quote: |
Yuk! Thanks!
|
|
|
Unsubscribe from logbooks, posted by Chris Warner on Fri Sep 8 18:42:05 2006
|
| Is there a way for user to unsubscribe from a logbook? Can a user delete their own account? |
|
Re: Unsubscribe from logbooks, posted by Stefan Ritt on Mon Sep 11 17:25:54 2006
|
| Chris Warner wrote: | | Is there a way for user to unsubscribe from a logbook? Can a user delete their own account? |
Yes. Yes.
Just click on "Config", and you will see a page where you can unsubscribe from each logbook and a button to remove your account. |
Auto-refresh ELog display, posted by Alan Stone on Thu Aug 24 15:52:54 2006
|
We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
|
Re: Auto-refresh ELog display, posted by Steve Jones on Thu Aug 24 19:02:47 2006
|
Couldn't a small bit of javascript be added that would accomplish this? Me saying this and I have no idea what I am talking about!!
| Alan Stone wrote: | We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
|
|
Re: Auto-refresh ELog display, posted by Steve Jones on Thu Aug 24 19:28:35 2006
|
<html>
<head>
<title>Refresh JavaScript Example</title>
<noscript>
<!--
We have the "refresh" meta-tag in case the user's browser does
not correctly support JavaScript or has JavaScript disabled.
Notice that this is nested within a "noscript" block.
-->
<meta http-equiv="refresh" content="2">
</noscript>
<script language="JavaScript">
<!--
var sURL = unescape(window.location.pathname);
function doLoad()
{
// the timeout value should be the same as in the "refresh" meta-tag
setTimeout( "refresh()", 2*1000 );
}
function refresh()
{
// This version of the refresh function will cause a new
// entry in the visitor's history. It is provided for
// those browsers that only support JavaScript 1.0.
//
window.location.href = sURL;
}
//-->
</script>
<script language="JavaScript1.1">
<!--
function refresh()
{
// This version does NOT cause an entry in the browser's
// page view history. Most browsers will always retrieve
// the document from the web-server whether it is already
// in the browsers page-cache or not.
//
window.location.replace( sURL );
}
//-->
</script>
<script language="JavaScript1.2">
<!--
function refresh()
{
// This version of the refresh function will be invoked
// for browsers that support JavaScript version 1.2
//
// The argument to the location.reload function determines
// if the browser should retrieve the document from the
// web-server. In our example all we need to do is cause
// the JavaScript block in the document body to be
// re-evaluated. If we needed to pull the document from
// the web-server again (such as where the document contents
// change dynamically) we would pass the argument as 'true'.
//
window.location.reload( false );
}
//-->
</script>
</head>
<!--
Use the "onload" event to start the refresh process.
-->
<body onload="doLoad()">
<script language="JavaScript">
<!--
// we put this here so we can see something change
document.write('<b>' + (new Date).toLocaleString() + '</b>');
//-->
</script>
</body>
</html>
| Steve Jones wrote: | Couldn't a small bit of javascript be added that would accomplish this? Me saying this and I have no idea what I am talking about!!
| Alan Stone wrote: | We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
|
|
|
Re: Auto-refresh ELog display, posted by Alan Stone on Thu Aug 24 20:16:23 2006
|
I appreciate your posting of the JavaScript. However, I have no idea what
to do with it. The page appears to be generated by some elog daemon. I do
not know how to hook into that.
Alan
| Steve Jones wrote: | Couldn't a small bit of javascript be added that would accomplish this? Me saying this and I have no idea what I am talking about!!
| Alan Stone wrote: | We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
|
|
|
Re: Auto-refresh ELog display, posted by Steve Jones on Fri Aug 25 05:27:13 2006
|
eLog allows one to add custom headers or footers as well as include Cascading Style Sheets. I believe there is a post somewhere in here from Stefan indicating that javascript can be added through one of these methods . . . hold on, a simple search, yes Stefan mentions it at http://midas.psi.ch/elogs/Forum/1837
| Alan Stone wrote: | I appreciate your posting of the JavaScript. However, I have no idea what
to do with it. The page appears to be generated by some elog daemon. I do
not know how to hook into that.
Alan
| Steve Jones wrote: | Couldn't a small bit of javascript be added that would accomplish this? Me saying this and I have no idea what I am talking about!!
| Alan Stone wrote: | We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
|
|
|
|
Re: Auto-refresh ELog display, posted by Stefan Ritt on Mon Sep 11 16:32:52 2006
|
| Alan Stone wrote: | We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
The JavaScript is one possibility as Steve mentioned correctly. Another possibility is to use the RSS feed capability of ELOG. Use any RSS reader, and it will notify you immediately if there is a new entry in ELOG. Have a look at http://midas.psi.ch/elog/config.html and search for RSS on how to configure this. |
|