When there are two or more Quick Filters available, and one of them is on the Subtext attribute, once one of the other filters has its value changed the null text for the Subtext selection criterion (namely, "-- Text  --") is used as a genuine selection criterion, thus typically preventing any entries from matching. 

This is for v2.7.0-1961 with both Mozilla 2.0.0.9 and IE 6 on Windows XP Professional SP2, and I think has appeared with this release.  You can demonstrate the behaviour on this forum: 

• Go to http://midas.psi.ch/elogs/Forum/
• Quick filter on dates in the "Last Month" and nothing is listed.  The URL is now http://midas.psi.ch/elogs/Forum/?last=31&Subtext=--+Text+--
• Set the date filter back to "-- All Entries --" and the spurious subtext filter remains; the URL is now http://midas.psi.ch/elogs/Forum/?Subtext=--+Text+--
• Delete the "-- Text --" value in the filter box and everything reappears; the URL is back to http://midas.psi.ch/elogs/Forum/

Richard Stamper

Working perfectly!  Many thanks for your usual quick response.

When doing a Select->Edit operation, if an attribute has a type of "numeric" and the records selected already have (some) values for that attribute, then the "- keep original values -" message that is inserted to indicate that the values should be preserved causes the type check to fail.

Would it be possible to modify the Javascript that carries out the type check to treat the "- keep original values -" message as an exception?

With a logbook defined by 

 [test]
 Theme = default
 Comment = Test of auto-increment
 Attributes = Batch
 Subst Batch = %Y%m%d-##

the auto-incrementing of the Batch attribute within dates works when the logbook contains only entries for
today's date but otherwise will give a batch number of "01" for each entry.  

Changing line 8714 of elogd.c as follows, from:

      /* if date part changed, start over with index */
      if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
         old_index = 0;   
      else
         /* retrieve old index */
      if (atoi(attrib[index] + loc) > old_index)
         old_index = atoi(attrib[index] + loc);
to
      /* if date part changed, start over with index */
      if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
         break;            /* <------------- */
      else
         /* retrieve old index */
      if (atoi(attrib[index] + loc) > old_index)
         old_index = atoi(attrib[index] + loc);

appears to fix this bug when I test it.  This code is inside a loop stepping back through all log entries, and
the variable old_index is already set to zero before the loop. The existing code resets old_index whenever the
prefix of the attribute string (containing a date) does not match the "current" value of that prefix as found in
retstr (set using strftime).  So, if there are any records for dates other than today then old_index is reset
and attribute values will be set with the counter = (old_index+1) = 1.  The modified version stops comparisons
once a different date is seen, but assumes that records are date ordered.  An alternative patch:

      /* if date part matches */
      if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) == 0)
          /* retrieve old index */
         if (atoi(attrib[index] + loc) > old_index)
            old_index = atoi(attrib[index] + loc);
  
does not make this assumption and also appears to work OK when I test it.

When adding a log entry containing a datetime field using the IE7 browser a Javascript warning is displayed - see the attachment.  This is due to a change in the naming of the "seconds" field of a datetime entry (made in version 2143) not being propagated to the code that generates the Javascript that checks the supplied values.

Suggested patch follows.

Change "s%d" to "c%d" in lines 9675 and 9678.

Showing lines 9675-9680 below, change from:

               rsprintf("  if (document.form1.s%d.value == \"\") {\n", i);
               sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
               rsprintf("    alert(\"%s\");\n", str);
               rsprintf("    document.form1.s%d.focus();\n", i);
               rsprintf("    return false;\n");
               rsprintf("  }\n");

to:

               rsprintf("  if (document.form1.c%d.value == \"\") {\n", i);
               sprintf(str, loc("Please enter second for attribute '%s'"), attr_list[i]);
               rsprintf("    alert(\"%s\");\n", str);
               rsprintf("    document.form1.c%d.focus();\n", i);
               rsprintf("    return false;\n");
               rsprintf("  }\n");

Regards,

Richard Stamper

On the matter of automatic calculation of fields, it is possible using included javascript but you have to do the work yourself.  For example, we have a log which computes responsivity as the ratio of a photocurrent and optical power.  With log attributes called "Photocurrent", "Optical Power" and "Responsivity" there is a file in the logbooks directory called photomixer_javascript.html containing something like:

<script>

if (document.form1.Photocurrent) {
  document.form1.Photocurrent.onchange = new Function(
    "mod();"+
    "var power = parseFloat(document.form1.Optical_Power.value);"+
    "var current = parseFloat(document.form1.Photocurrent.value);"+
    "if (!isNan(power) && !isNan(current) && power != 0.0) {"+
    "  document.form1.Responsivity.value = Math.round(current/power*100)/100.0"+
    "}"
    );
  document.form1.Optical_Power.onchange = document.form1.Photocurrent.onchange;
}

</script>

and the elogd.cfg file includes

Bottom text = photomixer_javascript.html

for the relevant log.

The assignments to the onchange handlers are guarded because this javascript is included on all pages for that log, including the list pages where there is no such field as Photocurrent, (or Optical_Power) and the event handler function is defined dynamically for the same reason.

Under some circumstances the New/Edit entry screen can invoke the init_resize() function in the onload handler for the <body> tag, but the init_resize() function is not defined.  In my case there is a log where the encoding is plain text (Default encoding = 1) and the message height is restricted (Message height = 4).  Creating or editing entries in this log generates warnings in the Firefox error console and alert boxes in IE about init_resize being undefined.

I think there is some missing logic.  In revision 2246 of elogd.c

• at line 9924, if enc_selected = 1 then init_resize() is included in the onload handler, but
• at line 9801, if enc_selected = 1 but at least one of the  "Message height" or "Message width" attributes is set then the code defining init_resize() is not include

I think you need to duplicate the checks on the Message height and Message width attributes at lines 9924, so that the init_resize() function is only included when defined.

Richard S

Internet Explorer fails to display correctly some aspects of pages generated by elog when the zoom functionality is used (Ctrl + and Ctrl -).  This is really a bug in the IE renderer rather than elog, but since IE can be persuaded to do better relatively easily it might be worth making some minor changes to make elog more robust when used with the buggy Microsoft browser.

The problem I encountered was initially with the multiple checkboxes for an Moptions attribute, but I noticed later it also affects the logbook tabs at the top of the screen.  If you start creating a submission to this forum in IE (7 or earlier, at least) you can see the problem; when zooming, the text labels and  the checkboxes do not scale together so start overlapping, and the same happens with the logbook tabs and the text links on them.  The problem is apparently to do with a proprietary IE concept called "layout" - see http://www.satzansatz.de/cssd/onhavinglayout.html for details - and IE struggles when some elements do not have the hasLayout property set to "true".

The fix is to coerce elements to have the hasLayout element set to "true" by giving them some benign CSS property.  The best I can find is to set "display: inline-block" for some of the key elements, and this can be done by modifying default.css rather than the elogd.c code.

Adding

span {
  display: inline-block;
}

to default.css (e.g. just after the default style definition for the "td" element) and adding

  display: inline-block;

to the style sets for the .sltab and .ltab classes (generic, not those specific to the "a" element) seems to prevent IE doing bad things with the display when zooming without messing up the display in Firefox.  I have not tested this comprehensively or in any other browsers, but I thought it might be worth passing on.

Cheers,

Richard Stamper