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. |
elog perl script and the command prompt and eof, posted by Arno Teunisse on Thu Sep 7 22:06:00 2006
|
hello
Just wrote a quick and dirty perl script ( See Attachment ) that let's you enter a record into the database. Put it into the directory where the config file is located. It look's at the "attributes = " and the "required attributes = "
within a section in the elog configuration file. The script is using elog.exe to accomplish this.
One problem with the script is that you must press Control_Z ( ^Z ) to store the data into the database.
Does anybody know how to prevent this ? It works also when redirecting the data into the script with a file input.txt. ( add2elog.pl confgi.cfg logbook < input.txt )
I Know this is NOT an elog question but maybe someone is happy with the script and has the answer for me. |
|