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. |
|
reply option in elog client not working, posted by Gerald Ebberink on Tue Aug 22 11:31:11 2006
|
When I try to make a reply with the following command
elog -v -h hostname -p 80 -l 'logbook wannabe' -u 'guess' 'what' -a 'Phase=During Measuring' -a Author='Gerald Ebberink' -a 'Subject=Octave measurements' -n 1 -f '22-Aug-2006 boxplot hole sizes of panel2SqTop.jpg' -f '22-Aug-2006 boxplot hole area of panel2SqTop.jpg' -f '22-Aug-2006 boxplot POA of panel2SqTop.jpg' -f '22-Aug-2006 boxplot hole sizes of panel2RTop.jpg' -f '22-Aug-2006 boxplot hole area of panel2RTop.jpg' -f '22-Aug-2006 boxplot POA of panel2RTop.jpg' -f '22-Aug-2006 boxplot hole sizes of panel6SqTop.jpg' -f '22-Aug-2006 boxplot hole area of panel6SqTop.jpg' -f '22-Aug-2006 boxplot POA of panel6SqTop.jpg' -f '22-Aug-2006 boxplot comparison of POA.jpg' -r 65 'Automated addition of measurment results (png)'
In verbose mode I found that the main difference is that
with the -r option it wants to go to the following url
Location: http://host/logbook/
and without it goes to
Location http://host/logbook+wannabe/66
my best guess would be that it should also point to logbook+wannabe |
|
Re: reply option in elog client not working, posted by Gerald Ebberink on Wed Sep 6 12:02:52 2006
|
| Today I found, I have the same problem with editing the log (with the -e option) |
|
Re: reply option in elog client not working, posted by Gerald Ebberink on Thu Sep 7 08:01:37 2006
|
I have made patch witch solves the problem partialy.
If there are not no attachments this patch works.... (But since I have attachments I'll have to dig in deeper in the code.
Attached you will find the diff. |
|
Re: reply option in elog client not working, posted by Gerald Ebberink on Thu Sep 7 17:17:17 2006
|
| Gerald Ebberink wrote: | I have made patch witch solves the problem partialy.
If there are not no attachments this patch works.... (But since I have attachments I'll have to dig in deeper in the code.
Attached you will find the diff. |
Now I am digging deeper, and I have a question:
In the function retrive_elog near line 427 a start is made with putting the attributes in an array.
As far as I can see there is no exception for the Attachment attribute. Where this attribute can be very large (e.g. many files attached) and overrun to the boundary variable (in the function submit_elog function). At least that is where I find end of my attachment string.
Could Mr. Ritt please shine some light on this, becouse I |
Corrupt page link, posted by Ulrich Trüssel on Wed Jun 21 14:21:01 2006
|
If a loggbook contains more than one page of entries, above and under the list are links for changing the page by number (or privous / last and all) conatining links looking like "http://localhost:8080/logbook/page2?mode=mode". This is the correct link and will work until Version 2.6.1-5!
In Version 2.6.1-6 the link is corrupted and look always like "http://localhost:8080/logbook/pag" |
|
Re: Corrupt page link, posted by Stefan Ritt on Wed Jun 21 17:03:23 2006
|
| Ulrich Trüssel wrote: | If a loggbook contains more than one page of entries, above and under the list are links for changing the page by number (or privous / last and all) conatining links looking like "http://localhost:8080/logbook/page2?mode=mode". This is the correct link and will work until Version 2.6.1-5!
In Version 2.6.1-6 the link is corrupted and look always like "http://localhost:8080/logbook/pag" |
Well, in this forum the link is fine, so it must have to do with your special configuration. Can you try with the demo logbook and find out which configuration option causes this problem? |
|
Re: Corrupt page link, posted by Arno Teunisse on Wed Jul 5 00:18:29 2006
|
| Ulrich Trüssel wrote: | If a loggbook contains more than one page of entries, above and under the list are links for changing the page by number (or privous / last and all) conatining links looking like "http://localhost:8080/logbook/page2?mode=mode". This is the correct link and will work until Version 2.6.1-5!
In Version 2.6.1-6 the link is corrupted and look always like "http://localhost:8080/logbook/pag" |
In this version, the above is true. It also has corrupted entries when clicking : Full | Summary | Threaded.
On MSExplorer and Firefox only a part of the link is shown in the left-down corner of the browser :
http://localhost:8080/?mo
No matter what button you click.
It should be : http://localhost:8080/?mode=full
http://localhost:8080/?mode=Summary
http://localhost:8080/?mode=Attachments
I'v tested is with the default elogd.cfg file which comes with the installation.
Something is going wrong here.
When importing a csv text file the above is introduced also.
Just installed the previous version :
====================================
[C:\Program Files\ELOG]elogd -c elogd.cfg
elogd 2.6.1 built May 24 2006, 08:59:09 revision 1688
Indexing logbooks ... done
Server listening on port 8080 ...
And the problem is gone. !!!!
problem is in version :
==========================
[C:\Program Files\ELOG1]elogd -c elogd.cfg
elogd 2.6.1 built Jun 13 2006, 08:43:21 revision 1691
Indexing logbooks ... done
Server listening on port 8080 ...
I love elog , for it's simplicity,
but will not upgrade to the lastest release untill this is solved. |
|
Re: Corrupt page link, posted by Stefan Ritt on Wed Jul 5 12:51:25 2006
|
| Arno Teunisse wrote: | Just installed the previous version :
====================================
[C:\Program Files\ELOG]elogd -c elogd.cfg
elogd 2.6.1 built May 24 2006, 08:59:09 revision 1688
Indexing logbooks ... done
Server listening on port 8080 ...
And the problem is gone. !!!!
problem is in version :
==========================
[C:\Program Files\ELOG1]elogd -c elogd.cfg
elogd 2.6.1 built Jun 13 2006, 08:43:21 revision 1691
Indexing logbooks ... done
Server listening on port 8080 ...
|
Thanks for your detailed information. The hint with the two different revisions heally helped. I fixed that in revision 1695, and made an intermediate release 2.6.1-7. This will fix the problem. Can you please check that this is working? |
|
Re: Corrupt page link, posted by Arno Teunisse on Sun Sep 3 23:16:31 2006
|
| Stefan Ritt wrote: |
| Arno Teunisse wrote: | Just installed the previous version :
====================================
[C:\Program Files\ELOG]elogd -c elogd.cfg
elogd 2.6.1 built May 24 2006, 08:59:09 revision 1688
Indexing logbooks ... done
Server listening on port 8080 ...
And the problem is gone. !!!!
problem is in version :
==========================
[C:\Program Files\ELOG1]elogd -c elogd.cfg
elogd 2.6.1 built Jun 13 2006, 08:43:21 revision 1691
Indexing logbooks ... done
Server listening on port 8080 ...
|
Thanks for your detailed information. The hint with the two different revisions heally helped. I fixed that in revision 1695, and made an intermediate release 2.6.1-7. This will fix the problem. Can you please check that this is working? |
Sorry for my ( very ) late answer , But yes the problem is GONE after installing the new release? Thanks. |