> > 'sort attributes' sorts the logbook entries when they are displayed.  Or?
> 
> Right
> 
> > What I want is to rearrange the entry mask.  E.g. if 'Entry type' article is
> > selected then the attributes 'Author', 'Journal', 'Title', and 'Year' 
> > should be listed first, as they are required for this bibtex entry type.
> > Is it possible with the current elogd version to also sort (rearrange) the 
> > attributes in the entry mask?  If yes, how?  
> 
> Attributes are shown in the order you specify them in the config file, so what about
> 
> Attributes = Entry type, Author, Journal, Title, Year     ???

Because for 'Entry type'='InProceedings' one needs:
'Author', 'Title', 'Booktitle', 'Year', 'Volume', 'Number'.
So, depending on the entry type that was chosen the entry mask should change,
with the required fields first and the not valid fields should not be shown
at all, which can nicely be done with the 'hidden attributes' config option.
Only the sorting (of the entry mask!) is missing! :)

There is a problem with the 'Show Attributes' option
causing the 'Format ...' options to be ignored.

See attachment for patch.

Segmentation fault when searching for empty regex
--------------------------------------------------

Searching for a regex like 'm*', which also includes zero 'm's, an empty
expression is found indefinitely in 'highlight_searchtext(...)', which 
eventually results in an overflow of 'pt1'.  The patch below fixes this
particular problem, but I would guess there are many other regular 
expressions that would lead to an overflow of 'pt1', so its size
should definitely be checked before every 'strcpy(pt1,...)' and
the loop be aborted accordingly.  (Or 'pt1' should be allocated 
and enlarged dynamically.)

*** 14777,14782 ****
--- 14777,14784 ----
        if (status != REG_NOMATCH) {
           size = pmatch[0].rm_so;
  
+        if (size == 0) break; /* check for zero size -> infinite loop */
+ 
           /* copy first part original text */
           memcpy(pt1, pt, size);
           pt1 += size;
***************
*** 14788,14795 ****
--- 14790,14799 ----
           /* see also rsputs2(char* ) */
  
           if (hidden)
+          /* need to check size of pt1 !!! */
              strcpy(pt1,
"\001B\004style=\003color:black;background-color:#ffff66\003\002");
           else
+          /* need to check size of pt1 !!! */
              strcpy(pt1, "<B style=\"color:black;background-color:#ffff66\">");
  
           pt1 += strlen(pt1);
***************
*** 14802,14814 ****
--- 14806,14821 ----
  
           /* add coloring 2nd part */
           if (hidden)
+          /* need to check size of pt1 !!! */
              strcpy(pt1, "\001/B\002");
           else
+          /* need to check size of pt1 !!! */
              strcpy(pt1, "</B>");
           pt1 += strlen(pt1);
        }
     } while (status != REG_NOMATCH);
  
+    /* need to check size of pt1 !!! */
     strcpy(pt1, pt);
  }

[quote="Stefan Ritt"][quote="Heiko Scheit"]The 'reverse sort' option does not work for quick filter searches. 
In the
URL there is always written 'reverse=0'.  For normal 'Find' it works OK.[/quote]

I don't understand the problem. If I take the example elogd.cfg from the distribution, it sorts in reverse
order, since the file contains [i]Reverse sort=1[/i]. If I apply a quick filter, the result is still sorted in
reverse order (entry ID from high to low). If I set [i]Reverse sort=0[/i], the even after applying a quick
filter, the entries are sorted with their ID from low to high. Applying a quick filter should not put a
[i]reverse=0[/i] into the URL, so it's strange to me where this comes from. Can you try to reproduce the problem
with the demo elogd.cfg?[/quote]

I played with the quick filter settings somewhat.  Here is what I get.
I can't really make sense of it, but maybe you can figure out what
happens.  Below, the first line always contains the 'Quick filter'
config setting.  The lines below show the URL after searching with the
quick filter for the 1st, 2nd,... attribute listed in the quick filter
setting.  (The common base of the URL was removed.  Shown is
everything after the last '/'.)  Each 'quick search' was started from
the 'List' or 'Back' page, i.e. the URL ended with a '/'.

As you can see below the result depends on the number and on the order
(!) of the attributes.  Only a few give the desired result (marked
with # OK).  Incidentally the option 'Date, Something' works fine,
which is the combination found in the demo config file.  :)

Quick filter            = Subject, Date, Login
?Subject=sd&Login=           # OK
?last=1&&reverse=0
?Login=sdf&reverse=0

Quick filter            = Subject, Login, Date
?Subject=scd&reverse=0
?Login=sdf&reverse=0
?last=1&reverse=0

Quick filter            = Date, Subject, Login
?last=1&&reverse=0
?Subject=sd&Login=           # OK
?Login=sd&reverse=0

Quick filter            = Subject, Date
?Subject=sd                  # OK
?last=1&reverse=0

Quick filter            = Date, Subject
?last=1&Subject=             # OK
?Subject=ddsd                # OK

Quick filter            = Login, Date
?Login=sch                   # OK
?last=31&reverse=0

Quick filter            = Subject, Login
?Subject=dsd&Login=          # OK
?Login=sd&reverse=0

Quick filter            = Login, Subject
?Login=sd&Subject=           # OK
?Subject=sd&reverse=0

?cmd=Activate&new_user_name=test1&new_full_name=Test1

http://my.ho.st/?cmd=Activate&new_user_name=test1&new_full_name=Test1

http://my.ho.st/myLogBook/?cmd=Activate&new_user_name=test1&new_full_name=Test1