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've managed to get it working and the problem wasn't what I thought it was.  It turns out that ImageMagick v7 doesn't have a "convert.exe" program in the windows version due to some conflict with a disk conversion utility.  The "convert.exe" has been replaced with a "magick.exe" and so I made a CONVERT.BAT script within the elog folder with content "magick %*".  This workaround appears to have solved the problem.

Version: ImageMagick 7.1.1-35 Q16-HDRI x64 d775d2a:20240714 https://imagemagick.org
Copyright: (C) 1999 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Channel-masks(64-bit) Cipher DPC HDRI Modules OpenCL OpenMP(2.0)
Delegates (built-in): bzlib cairo flif freetype gslib heic jng jp2 jpeg jxl lcms lqr lzma openexr pangocairo png ps raqm raw rsvg tiff webp xml zip zlib
Compiler: Visual Studio 2022 (194033811)

Having the URL link to a different logbook is right now not possible. But 
what about setting up a single logbook with a write password. Everybody can 
access it for reading, but only these people who know the write password 
can enter messages.

> With elog it is possible to submit messages to a password protected
> logbook without specifying the -u option.  I.e. NO PASSWORD is
> necessary to submit a message.  I assume it is related to the problem
> of expiring password-cookies while entering the message using a web
> browser.

Indeed this problem is related to the expiring password cookies. As a 
reminder: For the submission of a new entry, the password is checked when one 
presses the "New" button, but NOT for the "submit". This is because a 
password can expire between the "New" and the "Submit", so a entered message 
could not be sent. The question is now what to do with the standalone "elog".

Right now, elog does a normal submission where the password is not checked, 
which is maybe not what one wants. But what to do? If elog sends a special 
flag "please do check password on submit", someone could analyze the source 
code, remove the flag from elog and then still submit messages without a 
password. If I put an additional flag to the web browser submission "please 
do not check the password since the cookie might have been expired", someone 
can add this flag into elog and still bypass the password checking.

Anothe thing which bothers me is if you specify the password explicitly on 
the command line of elog, it's visible in some scripts etc, which yould be a 
security issue as well.

Any ideas?

> > With elog it is possible to submit messages to a password protected
> > logbook without specifying the -u option.  I.e. NO PASSWORD is
> > necessary to submit a message.  I assume it is related to the problem
> > of expiring password-cookies while entering the message using a web
> > browser.
> 
> Indeed this problem is related to the expiring password cookies. As a 
> reminder: For the submission of a new entry, the password is checked when
one 
> presses the "New" button, but NOT for the "submit". This is because a 
> password can expire between the "New" and the "Submit", so a entered message 
> could not be sent. The question is now what to do with the standalone
"elog".
> 
> Right now, elog does a normal submission where the password is not checked, 
> which is maybe not what one wants. But what to do? If elog sends a special 
> flag "please do check password on submit", someone could analyze the source 
> code, remove the flag from elog and then still submit messages without a 
> password. If I put an additional flag to the web browser submission "please 
> do not check the password since the cookie might have been expired", someone 
> can add this flag into elog and still bypass the password checking.

I guess it cannot and doesn't have to be 100% save.  Maybe if the web
interface is used for a new message a long random number (let's call
it newID) can be included, which elog remembers for some time (say 1
day).  Now elogd accepts a new message only if 

  1) the cookies is there and valid or
  2) if the cookies are NOT THERE, but the newID matches one of the
       stored ones.     

The new message is rejected if the cookies are there, but are wrong.

> Anothe thing which bothers me is if you specify the password explicitly on 
> the command line of elog, it's visible in some scripts etc, which yould be a 
> security issue as well.

Maybe the encoded password should be specified.  I use wget to
retrieve some entries automatically over a cron job and with wget
you specify a cookie-file with --cookie-file (or something like
this).  The content of this file corresponds to the content of the
netscape cookie file.

> 
> Any ideas?

Can one delete or edit messages with elog?  If yes then this should not be
possible.

> I guess it cannot and doesn't have to be 100% save.  Maybe if the web
> interface is used for a new message a long random number (let's call
> it newID) can be included, which elog remembers for some time (say 1
> day).  Now elogd accepts a new message only if 
> 
>   1) the cookies is there and valid or
>   2) if the cookies are NOT THERE, but the newID matches one of the
>        stored ones.     
> 
> The new message is rejected if the cookies are there, but are wrong.

Ok that sounds a good idea to me, I will work on that.

> Can one delete or edit messages with elog?  If yes then this should not be
> possible.

No this is not possible.

> Anyone seen similar problems? 
Probably not if you read the config file, 'cause I didn't. Shame on me...

But what this shows (Stefan: correct me if I'm wrong) is that if you set 
the port number in the [global] section of the config file, the command-line
option '-p' is ignored. FYI...

Joeri

> > Anyone seen similar problems? 
> Probably not if you read the config file, 'cause I didn't. Shame on me...
> 
> But what this shows (Stefan: correct me if I'm wrong) is that if you set 
> the port number in the [global] section of the config file, the command-line
> option '-p' is ignored. FYI...
> 
> Joeri

I changed that behaviour, so from 2.0.5 on the command line port setting has 
precedence over the configuration file (as it should be).