What is the recommended version of gcc to use with elog 2.5.9?  I searched
the discussion database but found nothing pertaining to this. 

Thanks  

> What is the recommended version of gcc to use with elog 2.5.9?  I searched
> the discussion database but found nothing pertaining to this. 

Well, the same code compiles on gcc and on Visual C++ under Windows, so
hopefully there is no dependence on the gcc version (;-)

I use gcc 3.2.3 on Scientific Linux 3.03.

> > What is the recommended version of gcc to use with elog 2.5.9?  I searched
> > the discussion database but found nothing pertaining to this. 
> 
> Well, the same code compiles on gcc and on Visual C++ under Windows, so
> hopefully there is no dependence on the gcc version (;-)
> 
> I use gcc 3.2.3 on Scientific Linux 3.03.

I ask because I get a dependency that I did not have before with 2.5.3. 
Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.

> I ask because I get a dependency that I did not have before with 2.5.3. 
> Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
> strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.

mxml.h and strlcpy.h are part of the elog tar ball. When untar'ed, they get copied
into a separate directory:

...
-rwxr-xr-x ritt/lke      15090 2005-05-09 13:09:54 elog-2.5.9/eloglang.japanese
-rwxr-xr-x ritt/lke      17587 2005-05-09 13:09:54 elog-2.5.9/eloglang.spanish
drwxr-xr-x ritt/lke          0 2005-05-09 13:09:54 mxml/
-rwxr-xr-x ritt/lke      45577 2005-05-09 13:09:54 mxml/mxml.c
-rwxr-xr-x ritt/lke       2198 2005-05-09 13:09:54 mxml/strlcpy.c
-rwxr-xr-x ritt/lke       4359 2005-05-09 13:09:54 mxml/mxml.h
-rwxr-xr-x ritt/lke        567 2005-05-09 13:09:54 mxml/strlcpy.h

I have right now no access to 3.4. Once I get it, I will address the errors
occuring there.

> > I ask because I get a dependency that I did not have before with 2.5.3. 
> > Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
> > strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.
> 
> mxml.h and strlcpy.h are part of the elog tar ball. When untar'ed, they get copied
> into a separate directory:
> 
> ...
> -rwxr-xr-x ritt/lke      15090 2005-05-09 13:09:54 elog-2.5.9/eloglang.japanese
> -rwxr-xr-x ritt/lke      17587 2005-05-09 13:09:54 elog-2.5.9/eloglang.spanish
> drwxr-xr-x ritt/lke          0 2005-05-09 13:09:54 mxml/
> -rwxr-xr-x ritt/lke      45577 2005-05-09 13:09:54 mxml/mxml.c
> -rwxr-xr-x ritt/lke       2198 2005-05-09 13:09:54 mxml/strlcpy.c
> -rwxr-xr-x ritt/lke       4359 2005-05-09 13:09:54 mxml/mxml.h
> -rwxr-xr-x ritt/lke        567 2005-05-09 13:09:54 mxml/strlcpy.h
> 
> I have right now no access to 3.4. Once I get it, I will address the errors
> occuring there.

Ah, now I need to figure out how to pickup the new includes.  
BTW, personally I wouldn't take my word regarding the 3.4 errors -- I was simply
trying an alternative version and it is likely that the way ours is configured is the
problem.

Thanks!

> > > I ask because I get a dependency that I did not have before with 2.5.3. 
> > > Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
> > > strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.
> > 
> > mxml.h and strlcpy.h are part of the elog tar ball. When untar'ed, they get copied
> > into a separate directory:
> > 
> > ...
> > -rwxr-xr-x ritt/lke      15090 2005-05-09 13:09:54 elog-2.5.9/eloglang.japanese
> > -rwxr-xr-x ritt/lke      17587 2005-05-09 13:09:54 elog-2.5.9/eloglang.spanish
> > drwxr-xr-x ritt/lke          0 2005-05-09 13:09:54 mxml/
> > -rwxr-xr-x ritt/lke      45577 2005-05-09 13:09:54 mxml/mxml.c
> > -rwxr-xr-x ritt/lke       2198 2005-05-09 13:09:54 mxml/strlcpy.c
> > -rwxr-xr-x ritt/lke       4359 2005-05-09 13:09:54 mxml/mxml.h
> > -rwxr-xr-x ritt/lke        567 2005-05-09 13:09:54 mxml/strlcpy.h
> > 
> > I have right now no access to 3.4. Once I get it, I will address the errors
> > occuring there.
> 
> Ah, now I need to figure out how to pickup the new includes.  
> BTW, personally I wouldn't take my word regarding the 3.4 errors -- I was simply
> trying an alternative version and it is likely that the way ours is configured is the
> problem.
> 
> Thanks!


Ok, now I see the issue - the tar extract created the mxml directory in the root (not
under the created directory elog-2.5.9).  Is there a reason why these includes are not
placed in the src dir like the regex.h/.c include?

> > > > I ask because I get a dependency that I did not have before with 2.5.3. 
> > > > Compiling with my same 'ole gcc 2.95.2 I see that I now need mxml.h and
> > > > strlcpy.h.  Trying to compile under gcc 3.4 results in all kinds of errors.
> > > 
> > > mxml.h and strlcpy.h are part of the elog tar ball. When untar'ed, they get copied
> > > into a separate directory:
> > > 
> > > ...
> > > -rwxr-xr-x ritt/lke      15090 2005-05-09 13:09:54 elog-2.5.9/eloglang.japanese
> > > -rwxr-xr-x ritt/lke      17587 2005-05-09 13:09:54 elog-2.5.9/eloglang.spanish
> > > drwxr-xr-x ritt/lke          0 2005-05-09 13:09:54 mxml/
> > > -rwxr-xr-x ritt/lke      45577 2005-05-09 13:09:54 mxml/mxml.c
> > > -rwxr-xr-x ritt/lke       2198 2005-05-09 13:09:54 mxml/strlcpy.c
> > > -rwxr-xr-x ritt/lke       4359 2005-05-09 13:09:54 mxml/mxml.h
> > > -rwxr-xr-x ritt/lke        567 2005-05-09 13:09:54 mxml/strlcpy.h
> > > 
> > > I have right now no access to 3.4. Once I get it, I will address the errors
> > > occuring there.
> > 
> > Ah, now I need to figure out how to pickup the new includes.  
> > BTW, personally I wouldn't take my word regarding the 3.4 errors -- I was simply
> > trying an alternative version and it is likely that the way ours is configured is the
> > problem.
> > 
> > Thanks!
> 
> 
> Ok, now I see the issue - the tar extract created the mxml directory in the root (not
> under the created directory elog-2.5.9).  Is there a reason why these includes are not
> placed in the src dir like the regex.h/.c include?


Ack, ok, I moved the includes into src and tried re-compiling -- and received several
"undefined symbol" errors from the linker.  Clearly the libraries cannot be moved into src?

> Ok, now I see the issue - the tar extract created the mxml directory in the root (not
> under the created directory elog-2.5.9).  Is there a reason why these includes are not
> placed in the src dir like the regex.h/.c include?

Yes. I use these files in several other projects as well, and want to maintain only a
single copy. So I have

elogd-x.x.x/
elogd-x.x.x/src/
....
mxml/
mxml/strlcpy.h
mxml/strlcpy.c
mxml/mxml.c
mxml/mxml.c
...
other-project-x.x.x/
other-project-x.x.x/

So both elogd and "other-project" can use strlcpy.c and mxml.c. If I would copy it to
elogd-x.x.x/src and fix a bug there, "other-project" would use a separate copy and not
profit from the bug fix. So I would have to mainain verious copies of the same file, which
make things complicated. I compile everything also under windows, so I cannot use soft
links. If there is a better way of how to do it, please let me know.

[ritt@pc5082 /tmp]$ tar -xzvf elog-2.5.9-2.tar.gz
elog-2.5.9/
elog-2.5.9/doc/
elog-2.5.9/doc/adminguide.html
...
mxml/
mxml/mxml.c
mxml/strlcpy.c
mxml/mxml.h
mxml/strlcpy.h
[ritt@pc5082 /tmp]$ cd elog-2.5.9
[ritt@pc5082 elog-2.5.9]$ make
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elog src/elog.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o regex.o src/regex.c
... skipping warnings ...
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o mxml.o ../mxml/mxml.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o strlcpy.o ../mxml/strlcpy.c
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -I../mxml -o elogd src/elogd.c regex.o
mxml.o strlcpy.o
gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elconv src/elconv.c
[ritt@pc5082 elog-2.5.9]$

--------------
No undefined functions here. I guess you have an old Makefile? Just use the complete tar
package from the last version.

> [ritt@pc5082 /tmp]$ tar -xzvf elog-2.5.9-2.tar.gz
> elog-2.5.9/
> elog-2.5.9/doc/
> elog-2.5.9/doc/adminguide.html
> ...
> mxml/
> mxml/mxml.c
> mxml/strlcpy.c
> mxml/mxml.h
> mxml/strlcpy.h
> [ritt@pc5082 /tmp]$ cd elog-2.5.9
> [ritt@pc5082 elog-2.5.9]$ make
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elog src/elog.c
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o regex.o src/regex.c
> ... skipping warnings ...
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o mxml.o ../mxml/mxml.c
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -c -o strlcpy.o ../mxml/strlcpy.c
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -I../mxml -o elogd src/elogd.c regex.o
> mxml.o strlcpy.o
> gcc -O3 -funroll-loops -fomit-frame-pointer -W -Wall -o elconv src/elconv.c
> [ritt@pc5082 elog-2.5.9]$
> 
> --------------
> No undefined functions here. I guess you have an old Makefile? Just use the complete tar
> package from the last version.

Ok, now I have it.  Old Makefile because I had to perform some deletions to make "make" work
right under Solaris.  Basically, I took out the ifdef structures - "make" was blowing up on
these.  Everything now compiles perfectly -- don't change anything.  Thanks for that last pointer.

Steve

Just upgraded from stable running 2.5.2-2 to 2.5.9-2 in case of the usable
Duplicate function. After the problem discribed below i made a new, clean
installation again and played araound with the demo logbook, copying my
testlogbook (part of a real used and under 2.5.2-2 working logbook) into the
demo cfg file. 

ia figured out two serious problems:

1. If I copy the following section to the global into the demo lgbook,
elogd.exe crashes emediatly ewhile starting as a prozess:

[global]
Language = German
Theme = default
logbook tabs = 1
main tab = INHALT
welcome title = <b><big>Ulrich Rolf Trüssel</big></b>
Adressverwaltung
(Geschäft & Privat)
Mensch-Tier
Coaching&trade;&nbsp;&nbsp;-&nbsp;&nbsp;Mensch-Hund
Coaching&trade;
Interessengemeinschaft Familienhund&reg; - Regionalgruppe
Zentralschweiz
Lorenz Tierschule
port = 8080
Theme = default
Message Width = 100
Message Height = 25
Filtered browsing = 1
Suppress default = 2
Suppress Email on Edit = 0
Email Format = 0
Filtered browsing = 1
HTML default = 3
Reverse sort = 1

2. problem (the ting) that made me playing with teh demo cfg:
There are totally 8 logbooks running, but just one has this strange problem
of not giving a link to to the datasets in full and summary mode. I cutted
down all the stuff back to this only lines:

[Adresse2]
Attributes = Kundensegment, Duzis, Hauptadresse, Selektion, Sperre, Adresse,
Unterlagenversand, Empf. gegeben, Gruppe, Mitglied, URT, IGFH, Letzte
Anmeldung, IGFH Gruppe, IGFH JB, Anrede, Titel, Briefanrede, Vorname, Name,
Firma, Abteilung, Adresse Zusatz, Strasse, Landeskennung, PLZ, Ortschaft,
Postfach, Postfach PLZ, Postfach Ort, Telefon Geschäft, Telefon Privat,
Telefax, Telefon Mobil, EMail, HomePage, Funktion, Beruf, Geburtstag, Name
Hund, Rasse, Sex, Wurfdatum, Anmeldung, Impfbüchlein, Welpenkurs,
Erziehungskurs, Hundesport, Bestätigung, OCCH LN, Andere Kurse, Weitere
Hunde/Tiere, Referenzen, KlientIn/KundIn
List Display = Name, Vorname

and got still the same problem. if i create a new logbook it will works,
also ut works under 2.5.2-2 but not longer under 2.5.3 up (even not
2.5.9-2). any idea? mening this may be a VERY basic logbook... trued with
list display etc. around, nothinh happen. Need to go back to 2.5.2-2 where
this wasn't a problem? 

thanjs for any idea of this to problems...

Hi,

I would like to have the author email addresses listed only for users which
have logged in, but not for guest users. In the elogd.cfg file I have:

Attributes = Author, Author Email, Category, Subject
Guest Display = Author, Category, Subject, Text

But these attributes

  ID Date Author Author Email Category Subject Text

are shown also when visting the logbook as a guest. For the guests I would
like to show only these attributes

  ID Date Author Category Subject Text

Any ideas what I am doing wrong or why this does not work?

Johan

> I would like to have the author email addresses listed only for users which
> have logged in, but not for guest users. In the elogd.cfg file I have:
> 
> Attributes = Author, Author Email, Category, Subject
> Guest Display = Author, Category, Subject, Text
> 
> But these attributes
> 
>   ID Date Author Author Email Category Subject Text
> 
> are shown also when visting the logbook as a guest. For the guests I would
> like to show only these attributes
> 
>   ID Date Author Category Subject Text
> 
> Any ideas what I am doing wrong or why this does not work?

Guest List Display = Author, Category, Subject, Text
      ^^^^

- Stefan

> > I would like to have the author email addresses listed only for users which
> > have logged in, but not for guest users. In the elogd.cfg file I have:
> > 
> > Attributes = Author, Author Email, Category, Subject
> > Guest Display = Author, Category, Subject, Text
> > 
> > But these attributes
> > 
> >   ID Date Author Author Email Category Subject Text
> > 
> > are shown also when visting the logbook as a guest. For the guests I would
> > like to show only these attributes
> > 
> >   ID Date Author Category Subject Text
> > 
> > Any ideas what I am doing wrong or why this does not work?
> 
> Guest List Display = Author, Category, Subject, Text
>       ^^^^
> 
> - Stefan

Hi Stefan,

Thanks for the prompt answer and sorry for not reading the docs carefully enough.
The "Guest List Display" is of course what I should use. It works perfectly. And
thanks for the fantastic and very useful ELOG package!

Johan

is it possible to make the "+" sign, indicating a thread in the threaded
view, to be clickable in order to be able to expand a single thread each time ?

of course elog should remember the choice, so it will be possible to expand
N threads over the M total ones..

thanx :-) 

> of course elog should remember the choice, so it will be possible to expand
> N threads over the M total ones..

How should elog remember that? If you put this into the URL like

http://<elog-host>/<logbook>/?exp=12&exp=14&exp=18

to expand the entries 12, 14 and 18, it might work fine. But imagine that some uses
have very long list with thousands of entries. This would make the URL very long,
everything very slow and could even crash some browsers.

What I usually do is to not expand the list. If I click on an individual entry, I
see then the expanded thread for that entry above that entry. But you probably
realized this possibility already.

> > of course elog should remember the choice, so it will be possible to expand
> > N threads over the M total ones..
> 
> How should elog remember that? If you put this into the URL like
> 
> http://<elog-host>/<logbook>/?exp=12&exp=14&exp=18
> 
> to expand the entries 12, 14 and 18, it might work fine. But imagine that some uses
> have very long list with thousands of entries. This would make the URL very long,
> everything very slow and could even crash some browsers.
> 
> What I usually do is to not expand the list. If I click on an individual entry, I
> see then the expanded thread for that entry above that entry. But you probably
> realized this possibility already.

:-) yes I do 

A way may be using cookies, otherwise one can implement a kind o session mechanism
(using cookies or QS to pass sessid and storing user data on the server for a limited
time...)
the session method may be useful, but more difficult to implemnet, of course

> A way may be using cookies, otherwise one can implement a kind o session mechanism
> (using cookies or QS to pass sessid and storing user data on the server for a limited
> time...)
> the session method may be useful, but more difficult to implemnet, of course

The concept of a session ID is not present in elog, so implementing it would be harder
than writing elog from scratch. Keeping the thousand 'expansion' flags in cookies is bad
as well, because your browser will send them all each time you request a page, which can
then slow down things considerably over slow lines.

> > A way may be using cookies, otherwise one can implement a kind o session mechanism
> > (using cookies or QS to pass sessid and storing user data on the server for a limited
> > time...)
> > the session method may be useful, but more difficult to implemnet, of course
> 
> The concept of a session ID is not present in elog, so implementing it would be harder
> than writing elog from scratch. Keeping the thousand 'expansion' flags in cookies is bad
> as well, because your browser will send them all each time you request a page, which can
> then slow down things considerably over slow lines.

ok, i've downgraded my request then ...

it will be still useful to have the possibility of expland selectively a single thread :-)

> ok, i've downgraded my request then ...
> 
> it will be still useful to have the possibility of expland selectively a single thread :-)

That you can do by clicking on the thread and look at the thread at the top of the page (;-))

That's exactly the same number of clicks as you would need to expand a thread (:-)))

> > ok, i've downgraded my request then ...
> > 
> > it will be still useful to have the possibility of expland selectively a single thread :-)
> 
> That you can do by clicking on the thread and look at the thread at the top of the page (;-))
> 
> That's exactly the same number of clicks as you would need to expand a thread (:-)))

LOL ..this way I can't see the list of other threads .. so il my goal is to inspect the thread
looking for something I have to:
- open the 3d
- return to 3d list
- open another 3d ..
[loop]

my wish would be to reduce it to
- open the 3d
- open another 3d ..
[loop]

of course I'm thinking to a big number of entries in a short number of 3ds .. making ugly to
simply expand everything .. :-)

> LOL ..this way I can't see the list of other threads .. so il my goal is to inspect the thread
> looking for something I have to:
> - open the 3d
> - return to 3d list
> - open another 3d ..
> [loop]
> 
> my wish would be to reduce it to
> - open the 3d
> - open another 3d ..
> [loop]

Well, I have the browser's back button on one of my mouse buttons, so "- return to 3d list" is one
mouse click. My policy is: If I can save someone two or more mouse clicks for am operation, I will
implement it. If it's less, it's not worth investing some hours of programming just to save 0.5s
each tim (;-).

Ok ok, I'll put it on the wish list. Just in case I'm running out of work. :-)

When I define 2 attributes, by default and the second one has to be showed
depending on the first one value the elog correctly handle the thing, but
the rss feed shows an empty comma separeted field corresponding to the
conditional attribute not filled ...

> When I define 2 attributes, by default and the second one has to be showed
> depending on the first one value the elog correctly handle the thing, but
> the rss feed shows an empty comma separeted field corresponding to the
> conditional attribute not filled ...

Can you send me the part of your config files with those things so that I can
reproduce it?

> > When I define 2 attributes, by default and the second one has to be showed
> > depending on the first one value the elog correctly handle the thing, but
> > the rss feed shows an empty comma separeted field corresponding to the
> > conditional attribute not filled ...
> 
> Can you send me the part of your config files with those things so that I can
> reproduce it?

it is attached

Ok, fixed. I do however not evaluate the conditional attribute, but just remove any
empty attribute, I guess that makes more sense.

> Ok, fixed. I do however not evaluate the conditional attribute, but just remove any
> empty attribute, I guess that makes more sense.

ok, it work perfectly, tnx .. I agree with you choice of course :-)

Is it possible to have last runtime filtering and viewing method to be
stored in a cookie in order to make them permanent across navigation ?

I mean:
- if I decide to view "all" entries in the elog and then open one of them, 
  I'd like not to select "show all entries" again and again
- same thing if I choose to view last week
- same for every runtime filter and/or viewing option 

hope this is simple to implement :-)  thanks in advance 

> Is it possible to have last runtime filtering and viewing method to be
> stored in a cookie in order to make them permanent across navigation ?

Sounds like a good idea. Will put it on the wishlist.

Hello Stefan,

I have an question for you :o). Is there any solution to use the filtering 
system with an match case solution ? Add a parameter or something else to 
add a solution ? 
I gave you an picture for the explaination.
Wenn I select GA for example, I just want to habe GA in my array and not 
CofoGAr.
Thanks for answer

> I have an question for you :o). Is there any solution to use the filtering 
> system with an match case solution ? Add a parameter or something else to 
> add a solution ? 

I added a paramet "case sensitive search" which does this. In addition, the
switch defines the default state of the "case sensitive" check box on the find
page. The new functionality will be contained in the next release.

Hi,
Is there anybody that use the MOptions ?
I'am searching some example to understand this fonction could you help 
me ? :)

Thanks a lot for answer!

> Is there anybody that use the MOptions ?
> I'am searching some example to understand this fonction could you help 
> me ? :)

You used it already! (;-)

In this forum, you clicked on OS:Windows. You can select more than one OS
(->"multi" options or MOptions). The according configuration entry is:

MOptions OS = Linux, Windows, MaxOSX, All, Other