After THREE tries to enter a long detailed list of questions, all have been 
replaced by just one:  why do ELOG textareas and entry forms lose all data 
if the browser goes back/forward?  Or if a submission causes an error?  
Other forms in other applications don't have this kind of data loss.

Submitting this now before I lose it again.  Will submit rest of questions 
as separate entries.

> After THREE tries to enter a long detailed list of questions, all have been 
> replaced by just one:  why do ELOG textareas and entry forms lose all data 
> if the browser goes back/forward?  Or if a submission causes an error?  
> Other forms in other applications don't have this kind of data loss.
> 
> Submitting this now before I lose it again.  Will submit rest of questions 
> as separate entries.

Really strange. I tried with Mozilla Firefox and IE 6.0 and none of them lost
the entry data. What browser did you use? As far as I learned, data only
vanishes on pages which have an HTTP header containing "Expires: ..." with a
date in the past. But I made sure that the entry form does not contain this.

Please refreain in the future from sending many small entries. People being
registered with email notifications on the forum get flooded by notifications.
In worst case, write your posting using an editor and do copy-and-paste into a
single posting.

> > After THREE tries to enter a long detailed list of questions, all have been 
> > replaced by just one:  why do ELOG textareas and entry forms lose all data 
> > if the browser goes back/forward?  Or if a submission causes an error?  
> > Other forms in other applications don't have this kind of data loss.
> > 
> > Submitting this now before I lose it again.  Will submit rest of questions 
> > as separate entries.
> 
> Really strange. I tried with Mozilla Firefox and IE 6.0 and none of them lost
> the entry data. What browser did you use? As far as I learned, data only
> vanishes on pages which have an HTTP header containing "Expires: ..." with a
> date in the past. But I made sure that the entry form does not contain this.

IE 6.0.   

I am accessing an internal ELOG instance through an Apache reverse proxy on port
80, per the FAQ.  Just tested without the proxy and there is no data loss problem
with back/forward.  

When I access the ELOG forum, I am going through a forward proxy to the Internet,
which probably explains the data loss on error messages.

Will investigate proxy configuration regarding "Expires: " headers and post here
if I find a solution.

> Please refreain in the future from sending many small entries. People being
> registered with email notifications on the forum get flooded by notifications.
> In worst case, write your posting using an editor and do copy-and-paste into a
> single posting.

Sorry about that, will do.

Date selection from the calendar widget does not work in Konqueror.  

Clicking on a date results in year being populated, but month and day are 
blank.

> Date selection from the calendar widget does not work in Konqueror.  
> 
> Clicking on a date results in year being populated, but month and day are 
> blank.

I use following Javascript to populate the date:

function submit_day(day)
{
  opener.document.form1.d3.value = "24";
  opener.document.form1.m3.value = "11";
  opener.document.form1.y3.value = "2004";
  window.close();
}

which workes everywhere except in Konqueror. If you tell me how to convince
Konqueror to accept this, I'm happy to put it into the elog code.

Version 2.5.2 of ELOG has been released today. It contains CSV (comma
separated values) import and export, as well as XML export (through the
"Find" page). Since these features are new, I would appreciate some feedback
on how this works in different environments. I made sure I can import data
from Excel and Outlook (like my address book), but I have no experience with
other applications.

As with the XML export, I'm not sure if the format I chose is a good one.
People working more with XML should tell me if it should be changed.

> Version 2.5.2 of ELOG has been released today. It contains CSV (comma
> separated values) import and export, as well as XML export (through the
> "Find" page). Since these features are new, I would appreciate some feedback
> on how this works in different environments. I made sure I can import data
> from Excel and Outlook (like my address book), but I have no experience with
> other applications.
> 
> As with the XML export, I'm not sure if the format I chose is a good one.
> People working more with XML should tell me if it should be changed.

I was able to find the export feature under find. Could you let me know where 
the import feature is? Or how I turn it on.

-Charles-

> I was able to find the export feature under find. Could you let me know where 
> the import feature is? Or how I turn it on.

Oops, I frogot to document this, thank you for reminding me. You have to add the
"CSV Import" command manually to the list of menu commands, like:

Find menu commands = New, Find, Select, Config, CSV Import, Help

I was wondering if I should make this as the default, but many people maybe do not
have the demand of having CSV Import, so it might be annoying for them. What do
you think?

> > I was able to find the export feature under find. Could you let me know where 
> > the import feature is? Or how I turn it on.
> 
> Oops, I frogot to document this, thank you for reminding me. You have to add the
> "CSV Import" command manually to the list of menu commands, like:
> 
> Find menu commands = New, Find, Select, Config, CSV Import, Help
> 
> I was wondering if I should make this as the default, but many people maybe do not
> have the demand of having CSV Import, so it might be annoying for them. What do
> you think?

I needed the export feature and could not find documentation on it in the latest 
version. I finally read the code and added Find Menu Text = <filename>
where filename had the tags XML, CSV1, and CSV2
This always exports all records. Shouldn't it just export the records appearing in 
the window?
Also, there is a CSV Import menu item, why isn't there CSV Export? Or just Export 
with radio buttons controlling the format.
(BTW, the XML export is not valid. Internet Explorer complains about the first line)

Great Software. Love it. Keep up the good work!

> I needed the export feature and could not find documentation on it in the latest 
> version. I finally read the code and added Find Menu Text = <filename>
> where filename had the tags XML, CSV1, and CSV2
> This always exports all records. Shouldn't it just export the records appearing in 
> the window?

Exporting workes as follows: Click on "Find", and switch the radio button to XML or CSV.
If you click on "Search", you will be prompted where to save the resulting "export.xml"
or "export.csv". I did this through the search page because you can then specify som
filters, in order not to export all records.

> (BTW, the XML export is not valid. Internet Explorer complains about the first line)

The XML charset in the first line was missing. I fixed that, new version under CVS. Or
you can manually change the first line to

<?xml version="1.0" encoding="ISO-8859-1"?>

> > I needed the export feature and could not find documentation on it in the latest 
> > version. I finally read the code and added Find Menu Text = <filename>
> > where filename had the tags XML, CSV1, and CSV2
> > This always exports all records. Shouldn't it just export the records appearing in 
> > the window?
> 
> Exporting workes as follows: Click on "Find", and switch the radio button to XML or CSV.
> If you click on "Search", you will be prompted where to save the resulting "export.xml"
> or "export.csv". I did this through the search page because you can then specify som
> filters, in order not to export all records.
> 
> > (BTW, the XML export is not valid. Internet Explorer complains about the first line)
> 
> The XML charset in the first line was missing. I fixed that, new version under CVS. Or
> you can manually change the first line to
> 
> <?xml version="1.0" encoding="ISO-8859-1"?>

Thanks much!! I can't believe I missed seeing those options. Works great. (There is a 
danger to having the source code. You tend to read it instead of looking at the way the 
program works )

BTW,
Is there any way to turn off the Text column at the right side of the list?

> BTW,
> Is there any way to turn off the Text column at the right side of the list?

Summary lines = 0

Could there be a multi-value option for free text fields, e.g. comma-
separated?  This would allow multi-parent relationships between log items. 

E.g. specifying 12, 15 as a value would create unique Display links 
for "12" and "15", based on the Display specification for that attribute.

This would be like "multiple fixed options", for the purpose of formatting.

Is there a way to disable wildcard matching in searches?

A search for "1" returns "1" and "10" and "11".  

Is there a way to perform an explict match?

Could there be a numeric match if the attribute type is numeric?

Can "Display" links work with multiple options? 

"ABC | DEF" is currently one link.

Ideally, it would be two links, each formatted per the "Display" string.

When compiling elogd on AMD64 (in 64 bit mode) there are many 
warnings like these:

src/regex.c:3769: warning: cast from pointer to integer of different size
src/regex.c:3769: warning: cast from pointer to integer of different size
src/regex.c:3775: warning: cast to pointer from integer of different size

The reason is the (int) cast, which (I think) is not necessary.

> When compiling elogd on AMD64 (in 64 bit mode) there are many 
> warnings like these:
> 
> src/regex.c:3769: warning: cast from pointer to integer of different size
> src/regex.c:3769: warning: cast from pointer to integer of different size
> src/regex.c:3775: warning: cast to pointer from integer of different size
> 
> The reason is the (int) cast, which (I think) is not necessary.

Unfortunately I don't have a 64-bit compiler to try. Can you please check if
elogd.c has similar warnings or only regex.c? The ones in elogd.c I can fix,
but regex.c is straight from the GNU C library, so we would have to wait intil
they fix it. Or can you get it from the 64-bit C library? The point is that I
need the source code, so that I can compile it under Windows as well. Can you
try to compile elogd without regex.c, like 

gcc -g -O -W -Wall -o elogd src/elogd.c

If that works fine, we don't have to compile regex.c under linux. But I guess
it's still needed fot Solaris and other non-GNU Unix brands.

> > When compiling elogd on AMD64 (in 64 bit mode) there are many 
> > warnings like these:
> > 
> > src/regex.c:3769: warning: cast from pointer to integer of different size
> > src/regex.c:3769: warning: cast from pointer to integer of different size
> > src/regex.c:3775: warning: cast to pointer from integer of different size
> > 
> > The reason is the (int) cast, which (I think) is not necessary.
> 
> Unfortunately I don't have a 64-bit compiler to try. Can you please check if
> elogd.c has similar warnings or only regex.c? 

  elogd.c shows the same warnings.

> The ones in elogd.c I can fix,
> but regex.c is straight from the GNU C library, so we would have to wait intil
> they fix it. Or can you get it from the 64-bit C library? The point is that I
> need the source code, so that I can compile it under Windows as well. Can you
> try to compile elogd without regex.c, like 
> 
> gcc -g -O -W -Wall -o elogd src/elogd.c

  This works OK.
 

Hi, we are using ELOG for keeping track of a server maintainance.  I've
translated some of ELOG's strings.  The file is attached.  There will be
more translations, when I get inspired again ;-)