ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
66505
|
Mon Aug 10 21:19:50 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Comment | Linux | 2.7.7-2251 | Re: Comment on: Alphabetize Quick Option filter | I've just noticed that it has also sorted another Option, which are selected as radio buttons. Again, this is a
list which has a natural - again, in this case, chronological - order.
Because of this, I'm going to have to turn off this feature as it is on my system. I hope something can be sorted
on this.
> (For some reason I could not add this in Dennis's thread.)
>
> I like this new feature, BUT
>
> I happen to have two Options: Options System, and Options Status.
>
> System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to.
> Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> this is made up)
>
> Options System: 3.1, NT, 2000, XP, Vista
>
> where the natural order here is chronological.
>
> Perhaps the configuration file option could be more specific, for example
>
> Sort attribute Options Status = 1
>
> which would then NOT sort Options System. If both are needed to be sorted, both should be specified, or back to
> the original syntax which defaults to sort *all* Options. |
66510
|
Tue Aug 11 08:38:56 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Comment | Linux | 2.7.7-2251 | Re: Comment on: Alphabetize Quick Option filter | Ok, that makes sense, so I changed it to
Sort Attribute Options Status = 1
as you suggested.
> (For some reason I could not add this in Dennis's thread.)
>
> I like this new feature, BUT
>
> I happen to have two Options: Options System, and Options Status.
>
> System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to.
> Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> this is made up)
>
> Options System: 3.1, NT, 2000, XP, Vista
>
> where the natural order here is chronological.
>
> Perhaps the configuration file option could be more specific, for example
>
> Sort attribute Options Status = 1
>
> which would then NOT sort Options System. If both are needed to be sorted, both should be specified, or back to
> the original syntax which defaults to sort *all* Options. |
66511
|
Tue Aug 11 10:07:08 2009 |
| David Pilgram | David.Pilgram@epost.org.uk | Comment | Linux | 2.7.7-2251 | Re: Comment on: Alphabetize Quick Option filter | Thanks Stefan! Works great.
> Ok, that makes sense, so I changed it to
>
> Sort Attribute Options Status = 1
>
> as you suggested.
>
> > (For some reason I could not add this in Dennis's thread.)
> >
> > I like this new feature, BUT
> >
> > I happen to have two Options: Options System, and Options Status.
> >
> > System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to.
> > Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> > sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> > this is made up)
> >
> > Options System: 3.1, NT, 2000, XP, Vista
> >
> > where the natural order here is chronological.
> >
> > Perhaps the configuration file option could be more specific, for example
> >
> > Sort attribute Options Status = 1
> >
> > which would then NOT sort Options System. If both are needed to be sorted, both should be specified, or back to
> > the original syntax which defaults to sort *all* Options. |
66515
|
Tue Aug 11 17:46:33 2009 |
| Dennis Seitz | dseitz@berkeley.edu | Comment | Linux | 2.7.7-2251 | Re: Comment on: Alphabetize Quick Option filter | Yes, many thanks, Stefan, from me, too! It's really great that you respond so quickly to requests and suggestions.
And thanks to David for the fine tuning, great suggestion.
Dennis
> Thanks Stefan! Works great.
>
> > Ok, that makes sense, so I changed it to
> >
> > Sort Attribute Options Status = 1
> >
> > as you suggested.
> >
> > > (For some reason I could not add this in Dennis's thread.)
> > >
> > > I like this new feature, BUT
> > >
> > > I happen to have two Options: Options System, and Options Status.
> > >
> > > System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to.
> > > Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
> > > sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
> > > this is made up)
> > >
> > > Options System: 3.1, NT, 2000, XP, Vista
> > >
> > > where the natural order here is chronological.
> > >
> > > Perhaps the configuration file option could be more specific, for example
> > >
> > > Sort attribute Options Status = 1
> > >
> > > which would then NOT sort Options System. If both are needed to be sorted, both should be specified, or back to
> > > the original syntax which defaults to sort *all* Options. |
66492
|
Wed Aug 5 01:07:04 2009 |
| Richard Stamper | r.stamper@rl.ac.uk | Bug report | All | 2.7.7-2246 | init_resize sometimes not defined | 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 |
66493
|
Wed Aug 5 13:36:44 2009 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | 2.7.7-2246 | Re: init_resize sometimes not defined |
Richard Stamper wrote: |
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
|
Perfect! Not only your analysis but also your suggested solution. I implemented that in revision 2249.
Stefan |
66519
|
Mon Aug 24 21:47:14 2009 |
| Allen | bastss@rit.edu | Bug report | Linux | 2.7.7-2246 | Fix text prevents user from editing text during creation, instead of just edit | When we set Fix text = 1, according to the syntax, this should prevent users from modifying the text field during an edit, but it looks like it is blocking access at both time of edit and creation, meaning you can never add anything to it. Is that the intended functionality? |
66520
|
Tue Aug 25 21:08:51 2009 |
| Arno Teunisse | A.teeling3@chello.nl | Question | Windows | 2.7.7-2246 | fckeditor update | Hello
Just a few fckeditor related questions. How do elog versions and fckeditor versions relate. ?
Can I just drop another version of the fckeditor over an other version? What things should I consider when doing so ?
thanks for you're time.
|
|