ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
65768
|
Thu Mar 6 14:03:17 2008 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Linux | All | 2.6.5 | Re: #include statements and attachment visibility |
Yoshio Imai wrote: | Recently, one collaborator here noted that it would be helpful if the preview of attached files could be disabled on a file-by-file basis (via a checkbutton next to the "Upload" button maybe?). This applies e.g. to cases where someone performs a measurement outside of routine operations and attaches the ASCII data file (preview not wanted, in particular if it contains many lines) and the graph representing the evaluation (preview wanted). The disabling should apply to both single-entry view and list view with "Show attachments" option. |
I made you something even better: I added a new option called Attachment lines. This number restricts the number of lines shown for any ASCII attachment. The default is 300, but you can set this to 10 maybe. This still shows you the first 10 lines of the attachment which might be handy. If you set this value to zero, no line at all is shown. The new feature is in SVN revision 2069.
Yoshio Imai wrote: | Another "fancy" idea of ours would be to allow #include-like statements in the ELOG config file. E.g. if the number of logbooks gets large, people might choose to put old logbooks to an archive disk which is then stored on some shelf. If a user then wants to access these, the disk could be mounted again (say, under /elog-archive). But since we don't know which archive disk has been mounted, and in order to keep the main config file small, the best would be to have the configurations for the logbooks of each disk on the disk itself (say, in a file called additional.config). We could then have a line like#include /elog-archive/additional.config in the main config file. When the elogd is (re)started, it would try to include that file. If it finds none (because no archive disk is mounted) it would silently ignore this. But if it finds such a file, it would include the logbook definitions found therein.
|
I will put this feature on the wishlist. |
66506
|
Tue Aug 11 00:20:11 2009 |
| Alan Grant | netman311@mts.net | Question | Windows | 2.6.5 | Logbook Parser | We are exploring whether it's possible/feasible to import ELog logbooks into a another database for special purposes (plotting/statisical, etc). Target database is TBD (perhaps Access).
Does anyone have or know of a logbook parser program? From cut/pasting into, for example, Excel, it does appear that the data fields are already line-feed delimited so offhand it would seem possible to parse if one really wanted to pursue it.
Regards,
- Alan |
66507
|
Tue Aug 11 08:10:21 2009 |
| Alan Grant | netman311@mts.net | Request | Windows | 2.6.5 | List Option | Hello Stefan.
Currently this is defined as a maximum of 100 literals in the cfg file. I would like to see the option to reference an external text file as input for this.
As a side question, I would also like to increase the max to a greater value, for example, even 5000. I assume I can change the source (I recall var was something like "List_Option_Max") and see if that would still work, but would you know offhand if that would cause a problem anywhere else?
Regards,
Alan
(PS: Just getting started with ELog. Please excuse if these questions sound newbie. I also searched the Forum first but haven't found any answers to them yet.) |
66508
|
Tue Aug 11 08:29:23 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.6.5 | Re: Logbook Parser |
Alan Grant wrote: |
We are exploring whether it's possible/feasible to import ELog logbooks into a another database for special purposes (plotting/statisical, etc). Target database is TBD (perhaps Access).
Does anyone have or know of a logbook parser program? From cut/pasting into, for example, Excel, it does appear that the data fields are already line-feed delimited so offhand it would seem possible to parse if one really wanted to pursue it.
Regards,
- Alan
|
You can export to CSV (comma-separated-values) if you go to "Find" and then click on "Export: CSV". These fiels you ran read right into Excel or other spreadsheet programs for further analysis. |
66509
|
Tue Aug 11 08:33:32 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | Windows | 2.6.5 | Re: List Option |
Alan Grant wrote: |
Currently this is defined as a maximum of 100 literals in the cfg file. I would like to see the option to reference an external text file as input for this.
|
I will put this on the wish list.
Alan Grant wrote: |
As a side question, I would also like to increase the max to a greater value, for example, even 5000. I assume I can change the source (I recall var was something like "List_Option_Max") and see if that would still work, but would you know offhand if that would cause a problem anywhere else?
|
I limited this to 100 entries because it will be hard to handle it. Imagine a drop-down list box with 5000 entries. It would fill your complete screen and you still won't see all 5000 entries. In that case it might be better to use a free text field and enter the attribute value as free text.
You can increase MAX_N_LIST in elogd.c, but at some point you will get a stack overflow and elogd will just crash.
- Stefan
|
66512
|
Tue Aug 11 13:02:22 2009 |
| Steve Williamson | StephenWilliamson@Barnsley.gov.uk | Question | Windows | 2.6.5 | Re: Logbook Parser |
Stefan Ritt wrote: |
Alan Grant wrote: |
We are exploring whether it's possible/feasible to import ELog logbooks into a another database for special purposes (plotting/statisical, etc). Target database is TBD (perhaps Access).
Does anyone have or know of a logbook parser program? From cut/pasting into, for example, Excel, it does appear that the data fields are already line-feed delimited so offhand it would seem possible to parse if one really wanted to pursue it.
Regards,
- Alan
|
You can export to CSV (comma-separated-values) if you go to "Find" and then click on "Export: CSV". These fiels you ran read right into Excel or other spreadsheet programs for further analysis.
|
excuse my butting in ... I've found the exports useful in the past - however, is is possible to run the export from a script in order to produce reports? Utilities like wget won't work as the export process doesn't return the data as html.
regards
Steve
|
66513
|
Tue Aug 11 13:25:48 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Windows | 2.6.5 | Re: Logbook Parser |
Steve Williamson wrote: |
excuse my butting in ... I've found the exports useful in the past - however, is is possible to run the export from a script in order to produce reports? Utilities like wget won't work as the export process doesn't return the data as html.
|
That's not true. wget does work. Try that one:
wget --no-check-certificate -O export.csv https://midas.psi.ch/elogs/linux+demo/?mode=CSV1
actaully wget doesn't care if the return is HTML or a GIF image or anything else, it just saves it into the output file. |
66514
|
Tue Aug 11 16:25:28 2009 |
| Alan Grant | netman311@mts.net | Question | Windows | 2.6.5 | Re: Logbook Parser |
Steve Williamson wrote: |
Stefan Ritt wrote: |
Alan Grant wrote: |
We are exploring whether it's possible/feasible to import ELog logbooks into a another database for special purposes (plotting/statisical, etc). Target database is TBD (perhaps Access).
Does anyone have or know of a logbook parser program? From cut/pasting into, for example, Excel, it does appear that the data fields are already line-feed delimited so offhand it would seem possible to parse if one really wanted to pursue it.
Regards,
- Alan
|
You can export to CSV (comma-separated-values) if you go to "Find" and then click on "Export: CSV". These fiels you ran read right into Excel or other spreadsheet programs for further analysis.
|
excuse my butting in ... I've found the exports useful in the past - however, is is possible to run the export from a script in order to produce reports? Utilities like wget won't work as the export process doesn't return the data as html.
regards
Steve
|
Steve, just a word of thanks for "butting in" ... my next thought was how could I schedule an export to feed the other database so it wouldn't have to be done manually each day. Your question took care of that for me! :)
Good community. Thanks. |
|