Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 576 of 808  Not logged in ELOG logo
    icon2.gif   Re: MS Fonts only in ELCode options?, posted by T. Ribbrock on Tue Jan 10 10:42:18 2006 

Stefan Ritt wrote:

In revision 1593 I implemented a "Fonts = ..." option where you can specify a list of fonts to be shown on the list. I tried however the MS set of fonts on a Linux system, and found that the MS fonts got mapped to Unix fonts in a reasonable way. Even the Comic Sans MS font was avalilable.


Very nice, thanks! Yes, vou're right, MS fonts have a chance of working on newer Linux distributions, but not on all and there are still older ones out there - never mind all those folks sitting behind some kind of Solaris/Sparc box or similar... Big grin
icon3.gif   Suggestion additional ElCodes, posted by T. Ribbrock on Tue Jan 24 14:43:19 2006 
I have to say, now that I'm finally on 2.6.x, I grew really fond of the ElCode stuff - great addition! It saves a lot of straight HTML typing for me... THANKS!

However, there are two things I'm missing:
  • Headings
    It would be great to have a range of

    ,

    , ... tags that map directly to their HTML counterparts (and have buttons, of course... Big grin ). That makes structuring an entry much easier in my opinion (and the output is easier to deal with for tools like html2ps) and I'm really missing those.
  • Tables
    This one is probably more difficult to add, but support for simple tables would be enough. But this is more a "nice to have"...
    icon2.gif   Re: Suggestion additional ElCodes, posted by T. Ribbrock on Wed Jan 25 12:31:14 2006 

Stefan Ritt wrote:

Yes, I missed tables myself already. The headings I just put into the current SVN version (see this forum for how it works).


Very nice, thanks! I'm a bit torn as to whether I like the way I have to enter the level by keyboard or whether I'd rather see something like with the smileys (i.e. some "level menu" opens once "H" is pressed). The former is faster, while the latter doesn't require moving between the mouse and the keyboard. But that's just a detail - not really that important.


Stefan Ritt wrote:
Tables are a bit harder to implement and will come later. Do you have a proposal for a possible syntax?
[...]
Maybe somehting like

heading 1 heading 2 heading 3
data 1 data 2 data 3


this looks a bit like the "pipe" mode from a Wiki

what do you think?

Yup, I remember using that kind of "pipe" structure in Wikis and I actually liked it. I think it's a lot easier to read in the "source" as well - and it reminds me remotely of LaTeX... Wink Also, it doesn't require much to just type it out instead of using buttons to make the cells. Definitely good enough for the simple type of tables I had in mind!
icon4.gif   Numbered lists get closed by </ul>, posted by T. Ribbrock on Mon Jan 30 16:26:08 2006 
I just ran into the following problem (and was able to reproduce it in the "demo" logbook on this site):

  • Create a new entry
  • Create a numbered list:
    [LIST=1]
    [*] 1st entry
    [*] 2nd entry
    [/LIST]
    
  • In the resulting HTML code, the closing statement of that list translates to </ul> instead of </ol>, causing the list to remain open and all following text to be intented by the list indentation. This gets worse when several such lists are used in one document. I'll include an example below.

Numbered list follows:

  1. one
  2. two
  3. three

This text is indented, as the list was not closed properly.

  1. four
  2. five
  3. six

And now we have double indention...
icon13.gif   Upgrade to 2.6.4 broke quick search, posted by T. Ribbrock on Tue Mar 6 16:59:13 2007 
Hi!

I just went from 2.6.1 to 2.6.4 and since the upgrade, the quick search drop-down menus no longer work. I can select an attribute, but when I do so, I only get an empty page with the following message:
Attachment #0 of entry #0 not found
Please use your browser's back button to go back

When I do go back, the attribute I selected is still selected, but all entries are listed. With 2.6.1, this worked like a charm.

Any idea?

Thanks in advance,

Thomas
    icon14.gif   Re: Upgrade to 2.6.4 broke quick search, posted by T. Ribbrock on Tue Mar 6 17:03:43 2007 

T. Ribbrock wrote:

[...]
I just went from 2.6.1 to 2.6.4 and since the upgrade, the quick search drop-down menus no longer work. I can select an attribute, but when I do so, I only get an empty page with the following message:
Attachment #0 of entry #0 not found
Please use your browser's back button to go back
[...]


Apparently, this must have been some session-oddity - I just logged out and got an error message about a bad URL. I then went to the base URL of the logbook (i.e. http://server:8080), chose the correct logbook and logged in again. Things work fine since. No idea what went wrong the first time round... Frown

Regards,

Thomas
icon4.gif   Using the command line tool to edit, posted by T. Ribbrock on Thu Aug 7 10:12:25 2008 

I intend to create a script that updates one of our elog logbooks based on mails it receives. I was hoping to be able to do this using the "elog" command line tool. Adding a new entry works fine, as does "replying" to an existing entry. The only thing I cannot get to work is editing an existing entry. All entries ahve several attributes and I intend not to use the "message" itself. I tried the following (on the machine this elogd is running on):

  1. Create a new entry with Attribute1 set to "value":

    elog -a 'Attribute1=value' -x -h localhost -l 'LOGBOOK' -p 8080 -u USER PASSWD

    This works - the entry gets created and is displayed properly.
    NOTE: I found that this does not work if LOGBOOK has any spaces in it - I would get error messages where the logbook was not found.
     
  2. Edit this entry to set a second attribute:

    elog -e 1 -a 'Attribute2=something' -x -h localhost -l 'LOGBOOK' -p 8080 -u USER PASSWD

    The result was: Error transmitting message. Running the same command with -v gives me a whole bunch of text with at the end this message (I've stripped the HTML): "This entry has in meantime been modified by someone else. Submitting it now would overwrite the other modification and is therefore prohibited." However, I know for certain that this entry is not being editied by anyone at that moment, so I'm wondering what I'm doing wrong here...

Also, I have a second, related question: Editing by the ID of the entry seems to be the only way of editing an entry - this makes it a bit difficult for me, as all entries already have a unique ID (which is defined as one of the attributes) that is non-numerical and not sequential. What is the easiest way to retrieve an ID from the command line (basically something like: "What ID has the entry with Attribute1==NAME?")? Is it possible at all? Otherwise, I would not be able to automatically edit the entries, as I don't know which is which... :-}

    icon2.gif   Re: Using the command line tool to edit, posted by T. Ribbrock on Fri Aug 8 14:50:56 2008 

Yoshio Imai wrote:

T. Ribbrock wrote:
NOTE: I found that this does not work if LOGBOOK has any spaces in it - I would get error messages where the logbook was not found.


You might try to escape the space in the form
elog -a 'Attribute1=value' -x -h localhost -l 'LOG\ BOOK' -p 8080 -u USER PASSWD


I forgot to mention that I tried both 'LOG\ BOOK' and 'LOG%20BOOK' - neither worked. Running elog with -v seemed to indicate in both cases that the correct logbook could not be found.



Yoshio Imai wrote:

T. Ribbrock wrote:
What is the easiest way to retrieve an ID from the command line

I don't know if this helps you (depends on how much the application that edits the entry communicates with the application the generates the entry), but the elog client should output something like
Message successfully transmitted, ID=12345
which you could e.g. redirect into a file that the editing application then reads to determine the ID.


Good point, thanks - I'll have to generate some kind of mapping table (ID<->Attribute) when the logbook gets populated, but that should be possible. It would be very cool, though, if elog was able to identify an entry by attribute value - maybe something for a day when Stefan gets bored... Wink

However, none of this will have any relevance unless I can solve the non-working "edit" function... Frown
ELOG V3.1.5-3fb85fa6