Re: quick filter, posted by Uwe on Thu Nov 29 18:59:59 2007
|
> > I installed the latest version (2.7) of ELOG and having the problem that the quick filter only works when hitting the
> > enter-key when there is only one free text field (subtext). Whene having two or more free text field you have to use
> > the tab-key or click onto the elog icon. We are using Internet Explorer, not tested on Mozilla right now.
>
> I found that this is indeed an Internet Explorer bug, since it works with all other browsers I tested. There is however a
> workaround: I added some code to the current version of elog which shows a "Search" button whenever the page is accessed
> through the Internet Explorer. Then the behavior of hitting <return> works again. The change is in revision #1970 and will
> be contained in the next release.
Thanks again for your help! |
#include statements and attachment visibility, posted by Yoshio Imai on Thu Feb 28 19:07:19 2008
|
Hi!
First of all, thank you again for the great software and all the support.
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.
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.
Do you think it is possible (and preferable) to implement this?
Cheers
Y |
Re: #include statements and attachment visibility, posted by Stefan Ritt on Thu Mar 6 14:03:17 2008
|
| 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. |
Logbook Parser, posted by Alan Grant on Tue Aug 11 00:20:11 2009
|
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 |
|
List Option, posted by Alan Grant on Tue Aug 11 08:10:21 2009
|
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.) |
|
Re: Logbook Parser, posted by Stefan Ritt on Tue Aug 11 08:29:23 2009
|
| 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. |
|
Re: List Option, posted by Stefan Ritt on Tue Aug 11 08:33:32 2009
|
| 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
|
|
Re: Logbook Parser, posted by Steve Williamson on Tue Aug 11 13:02:22 2009
|
| 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
|
|