ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
796
|
Tue Nov 16 22:45:24 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | | | | Re: elog password access without users | > thanks. that seems to get me the functionality i needed. is there any way to
> get rid of the username line when using the "Read Password" feature?
No, this is an HTTP standard. The dialog box is generated by your browser, and I
do not know any way to prevent it. |
800
|
Thu Nov 18 09:40:25 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Linux | 2.5.4-6 | Re: compiling elog on AMD64 | > 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. |
802
|
Sun Nov 21 00:46:28 2004 |
| Heiko Scheit | h.scheit@mpi-hd.mpg.de | Bug report | Linux | 2.5.4-6 | Re: compiling elog on AMD64 | > > 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.
|
803
|
Tue Nov 23 05:41:31 2004 |
| Neil Swartz | junkswartz@optonline.net | Info | All | 2.5.2 | Re: New ELOG version with XML and CSV import/export | > > 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! |
804
|
Tue Nov 23 12:42:43 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | All | 2.5.2 | Re: New ELOG version with XML and CSV import/export | > 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"?> |
812
|
Wed Nov 24 11:45:07 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Info | All | 2.5.2 | Re: New ELOG version with XML and CSV import/export | > BTW,
> Is there any way to turn off the Text column at the right side of the list?
Summary lines = 0 |
813
|
Wed Nov 24 11:52:26 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | All | 2.5.4-6 | Re: BUG: lost entry data | > 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. |
814
|
Wed Nov 24 13:55:22 2004 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | All | 2.5.4-6 | Re: Attribute Negative Search | > Is there any way to search for all attributes _except_ a certain value?
If you mean "search all attrubutes except one specific attribute" then the
answer is no.
> 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.
I don't understand your qyestion. You have an attribute with MOptions, so you
get "ABC | DEF" displayed in the list view. All links in each line point to
the individual entry, so what is the benefit of having two links for ABC and DEF?
> 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?
That should all be possible with the build-in regular expression. Just type
\b1\b
where "\b" means "word boundary". I agree that a numerical comparison for
numerical attributes would be better, I will put that on the to-do list.
> 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.
Again, this is not clear to me. What do you mean by "display specification"?
Is it the "List display = ..." option or the "Format attribute = ..." option?
What is a "multi-parent relationship"? Why do you need multiple options for a
free text field? Why can't you use the MOptions specification? |
|