| Stefan Ritt wrote: | Well, you didn't realize, but you were my beta-tester for the keyboard shortcuts  . I didn't yet publish it, so you must have gotten this brand new feature from SVN. |
You should really have told me  . Actually, I found out about the <Ctrl-C> issue while using this logbook.
| Stefan Ritt wrote: | | So get the SVN update, and let me know what you think |
Did so, we are running now -1826. I think it is very usable, with maybe one exception (this might be a browser issue, however): When using the shortcuts and/or the ELCode buttons, sometimes the code is generated and the cursor in between the [XX] and [/XX] directive, but sometimes, the whole code directive is selected as if for editing
which prevents from immediately continuing to type (which, I guess, was the idea behind the shortcuts). The behaviour is not completely reproducible, and I have even seen it change during one and the same browser (=firefox) session while working on the same entry (*). I also had it once that the browser out of a sudden completely ignored the ELCode meaning, and instead used <Ctrl-I> for page info and <Ctrl-B> for the history.
(*) It just happened again!
BTW, there are (of course ) two other issues. They are still present in -1826
- one bug was reported by a logbook user: when using the "find" function in a logbook, and selecting one value from the "Author" drop-down list and another from the "Category" drop-down list, the elogd reports no entries found, but when specifying only the "Author" and leaving "Category" blank, many entries are found, including those with the "Category" being looked for. When specifying only the "Category" and leaving the "Author" blank, the elogd also reports no entries found. Has anyone reported a similar behaviour?
- We have one logbook top group for the beamtimes. Under certain conditions, a preset text is to be displayed.
{2&a} Preset Text = resource/text_1.txt
{2&b} Preset Text = resource/text_2.txt
However, the definitions of these conditions have to be repeated for every logbook in the group (putting it only under [global beamtimes] doesn't do it), otherwise they are ignored.
Any idea on these? |