This was given to me by Andreas L, 

In my elog.cfg file, I have the following:

Preset text = $shell(date '+[%d %b %y]')\n

and this puts at the top of every new thread I make today the following line

[09 Apr 24]

And for the same result for every reply as well, I have in elog.cfg

Prepend on reply = $shell(date '+[%d %b %y]')\n\n----------\n

with the ten dash characters to show the end of the thread, so the reply entry goes above the dashes.

Obviously time, name of day etc can be included by using the strftime 


> > This is a nice idea, but currently no text substations in templates are implemented. It only works in attributes right now.
> 
> but can it be done by javascript injection? load a custom .js or .html file, in this file run javascript code to root down the DOM tree until you 
> find the right place, replace .innerHTML with current date?
> 
> K.O.

This was given to me by Andreas Luedeke of this parish. 

In my elog.cfg file, I have the following:

Preset text = $shell(date '+[%d %b %y]')\n

and this puts at the top of every new thread I make today the following line

[09 Apr 24]

And for the same result for every reply as well, I have in elog.cfg

Prepend on reply = $shell(date '+[%d %b %y]')\n\n----------\n

with the ten dash characters to show the end of the thread, so the reply entry goes above the dashes.

Obviously time, name of day etc can be included by using the strftime codes.


> > This is a nice idea, but currently no text substations in templates are implemented. It only works in attributes right now.
> 
> but can it be done by javascript injection? load a custom .js or .html file, in this file run javascript code to root down the DOM tree until you 
> find the right place, replace .innerHTML with current date?
> 
> K.O.

I have replied to this entry, because, for some reason I don't understand, if I reply to your latest entry, I am
automatically logged out.  I tried this multiple times, and also on many other entries and had no issues other than
entry 69787 - any reason for this, Stefan?

Anyway, what about MOptions? That appears to do what your example, and needs two lines in elog.cfg file:

Moptions WaferID = 1001, 1002, 1003, 1004, 1005
Extendable Options = WaferID

I've done a couple of quick tests on a test logbook I keep for such experimentation, and it appears to do all 
you have asked of it.  I added a new option 1006.  However, I found that one has to add that new one on its own, 
let the entry become proper, and then edit the entry to add the other, existing, values.   If you tick entries and 
also add a new one, then your new entry is all those listed on their own, that is you would get and new entry
in the config file such as "1002 | 1004 | 1006", rather than just 1006

This is probably an result of an unexpected use of Moptions and extendable options, rather than a bug per se.

> Hey, 
> 
> thanks for your answer. I completely get your point. However, I think my question as not precise enough.
> 
> I would like to have a numeric input, but many at the same time. When I make a new post, I would like to have an attribute 'wafer_IDs' that specifies the list of wafers this process has been performed with. So for a single post I would like to have a list like this:
> 
> wafer_IDs = numeric value, numeric value, numeric value, extendable
> 
> Note: I am not referring here to the option. The numeric values are freely chooses numbers, the only this that varies from post to post is the number of numeric values put.
> 
> Let me make an example (If the attribute were a string this would be the equivalent):
> 
> 1st post: A process that was run with 3 wafers (ID: 1000, ID: 1001 and ID: 1002):
> wafer IDs = 1000, 1001, 1002
> 
> 2nd post: A process that is run with 2 wafers (ID: 1000 and ID: 1002):
> wafer IDs = 1000, 1002
> 
> The string solves the issue, but is not as nice as having directly a list of integers.
> 
> Thanks for your help!
> 
> Best,
> 
> Nick

Just to add some points for others who may find this of use in future.

The hard coded number of entries options or Moptions can have is 100.  You can edit the code and recompile, but that would
not gain you many more before other problems concerning memory come in.

Options allow you to only select one from the list; Moptions allow multiple selections from the list.

As mentioned by Sebastian (previous poster) and  in my suggestion. I imagined that by Wafer 1060 (say), no new work would be 
being done on wafers 1001, ... 1010, so you could edit the config file and remove those (M)options.  It does not remove these 
wafer IDs from past records, simply that they can no longer be selected for new work to be recorded.    In that way the 
Moptions list remains short but allows for hundreds or thousands of WaferIDs,  ON THE ASSUMPTION that say only 50 (and certainly 
less than 100) are being worked on at any one time.

The numbers I chose here were random, it's more to highlight the principle rather than a prescription.

David.

> Just my 2 cents:
> 
> There is a hardcoded limit how many entries the Option list can have. Without looking into the source, I assume the limit also exists for MOptions.
> If you want more, you have to recompile elog with the changed limit.
> 
> We have used the normal Options attribute and a "Execute new"-script to alter the elog config for the Options list: to sort the list (5 last used entries on top, the rest alphabetical) and remove very old entries, which are not needed any more.
> Remark: if you change the elog.cfg, you have to tell elog to reload the cfg. e.g. using "killall -HUP elogd".
> 
> Alternatively, you can add javascript code via a html file and the attributes "Top text" or "Bottom text" to manipulate the input fields on the client side.
> 
> Both ways are a little bit hacky, but they work.
> Best wishes,
> Sebastian
> 
> > Thanks for you help. This is almost it. 
> > 
> > The problem is that the items are options and not freely closable numbers. In the end, with your solution, it will show you all of the previously put IDs which will be 1000s of entries for us. I think I will just put a convention that we have to write the numbers spread with a comma in a string 
> > field.
> > 
> > Thanks.
> > 
> > Best,
> > 
> > Nick 
> > 
> > 
> > > I have replied to this entry, because, for some reason I don't understand, if I reply to your latest entry, I am
> > > automatically logged out.  I tried this multiple times, and also on many other entries and had no issues other than
> > > entry 69787 - any reason for this, Stefan?
> > > 
> > > Anyway, what about MOptions? That appears to do what your example, and needs two lines in elog.cfg file:
> > > 
> > > Moptions WaferID = 1001, 1002, 1003, 1004, 1005
> > > Extendable Options = WaferID
> > > 
> > > I've done a couple of quick tests on a test logbook I keep for such experimentation, and it appears to do all 
> > > you have asked of it.  I added a new option 1006.  However, I found that one has to add that new one on its own, 
> > > let the entry become proper, and then edit the entry to add the other, existing, values.   If you tick entries and 
> > > also add a new one, then your new entry is all those listed on their own, that is you would get and new entry
> > > in the config file such as "1002 | 1004 | 1006", rather than just 1006
> > > 
> > > This is probably an result of an unexpected use of Moptions and extendable options, rather than a bug per se.
> > > 
> > > > Hey, 
> > > > 
> > > > thanks for your answer. I completely get your point. However, I think my question as not precise enough.
> > > > 
> > > > I would like to have a numeric input, but many at the same time. When I make a new post, I would like to have an attribute 'wafer_IDs' that specifies the list of wafers this process has been performed with. So for a single post I would like to have a list like this:
> > > > 
> > > > wafer_IDs = numeric value, numeric value, numeric value, extendable
> > > > 
> > > > Note: I am not referring here to the option. The numeric values are freely chooses numbers, the only this that varies from post to post is the number of numeric values put.
> > > > 
> > > > Let me make an example (If the attribute were a string this would be the equivalent):
> > > > 
> > > > 1st post: A process that was run with 3 wafers (ID: 1000, ID: 1001 and ID: 1002):
> > > > wafer IDs = 1000, 1001, 1002
> > > > 
> > > > 2nd post: A process that is run with 2 wafers (ID: 1000 and ID: 1002):
> > > > wafer IDs = 1000, 1002
> > > > 
> > > > The string solves the issue, but is not as nice as having directly a list of integers.
> > > > 
> > > > Thanks for your help!
> > > > 
> > > > Best,
> > > > 
> > > > Nick

I use linux elog, and if you upgrade to v3.x.x, it's difficult to go back to v2.9.x.  This is because the log files get grouped in year sub directories at  v3.x.x.

In 2.9.x, the logfiles are store as (made up example)    /home/logfiles/yymmdda.log

In 3.x.x they are stored as /home/logfiles/2024/24mmdda.log   /home/logfiles/2023/23mmdda.log  etc.  I think I got the labelling of the subdirectories correct, Stefan will no doubt correct if I am wrong.

I assume the same is true for the Windows version as it would be weird for a split in the program by OS for something important but trivial to impliment for all OS. 

It's a bore to sort that out if you have to revert to 2.9.x - I know, I've done it -  but I don't recall any change in format in the individual yymmdda.log files with an early v3.x.x version I tried.  There may be additions to the log files made in much more recent v3.1.x or so versions, but I guess you are ok with whatever they may be as you've checked the change log.  

We have been hosting logbook far (geographically and in internet hops) from our experimental site. Recently we have (finally!) gotten reliable on-site internet, and would like to host the log book on-site.

I have a suspicion that some combination of the -C, -m, and -M flags will allow me to migrate the logbook automagically and with a minimum risk of trouble from concurrent operation on the logbook, and to maintain the existing version as a mirror of the new official on-site version. But documentation is not being very helpful. Can someone say a few more words about what these options do?

I've been experimenting as I compose this and have a suggestion for language that might be useful somewhere in the documentation:

In this context "to clone" means to copy the configuration file and all data files associated with a log book so that I can host an identical logbook on a new host (that is this is the command to migrate a logbook).  After cloning the two installation are identical, but no effort is made to keep them so: if you continue to run both copies post made to one will not be reflected in the other.

Is this correct?

I'm still not clear on what the -m and -M options do.

Hi,

right now I'm testing Elog to use it as a task/todo-log for our small 
workgroup. What I saw so far looks very nice and I like it very much. 
Thanks for the good work.

Playing with all the configuration possibilities I have one issue:
I like to use the "Extendable options" but I can't combine them with 
the "Conditional attributes".

-- snip

Options Area = Area_1{1}, Area_2{2}, Area_51{3}
{1} Options Ressort = Res01, Res whatever, end so on
{2} Options Ressort = somthing else, fill in
{3} Options Ressort = Alien observation, Budget planning
Extendable options = Ressort

-- snip

The "Conditinal Attributes" do have the "Add Ressort" button and the elog-
entry is written with this new attribute. But the new attribute is not 
inserted into the config file.

Long time ago I last read C syntax but mabye the function 
add_attribute_option should take care of the prefix {n} in extendable 
options?

Or do I miss something in the configuration syntax? 

  Regards,

  David

> > Playing with all the configuration possibilities I have one issue:
> > I like to use the "Extendable options" but I can't combine them with 
> > the "Conditional attributes".
> 
> That was never ment to work. But I found some time to implement it. If you
> download elog255-4.exe from today it whould work. Let me know if you have
> problems.

Thanks a lot for fixing this issue, especially as it was never planed. I will
test it on Monday afternoon and will give you a reply.