> > Is there a way to disable editing of the textarea, but still allow editing 
> > of other fields in the entry? (e.g. Fixed Attributes Edit = Text)

I added a flag

Fix text = 0|1

A division in "fix text edit/fix text reply" does not make sense here, since I only
can lock the whole textfield, therefor just the switch.

New version under CVS (see download page).

> > > Is there a way to disable editing of the textarea, but still allow editing 
> > > of other fields in the entry? (e.g. Fixed Attributes Edit = Text)
> 
> I added a flag
> 
> Fix text = 0|1
> 
> A division in "fix text edit/fix text reply" does not make sense here, since I only
> can lock the whole textfield, therefor just the switch.
> 
> New version under CVS (see download page).

Thanks Stefan. Again, my hat is off to you for a great app.

Todd

I just updated ELOG using the latest elogd.c, and now my Quick Filters seem 
to stop working after the first or second filter attempt. I find that if I 
allow fewer quick filter options it seems to work more consistently. For 
example:

Example 1-
Quick filter = Date
The date filter will work without a problem no matter how many times I use 
it.

Example 2-
Quick filter = Date, Category, Status, Priority
The first filter I use will work, but upon trying a new filter, or just a 
new option in the same filter, all options return to "All Entries" and no 
filter options have any effect on the view.
If I exit the log book, and come back in, it works for the first filter 
attempt, then stops again.

This used to work fine prior to the update. I should also mention that the 
original installation of ELOG was from the Debian package. At that point, 
nothing was where the documentation said it should be (e.g. elogd.cfg was 
called elog.conf and was placed in the /etc/ directory). Everything worked 
fine, so I left it alone. When I recompiled with the newer elogd.c, 
anything that required a path was hosed, so I now have to specify the 
resource directory and the path to the conf file when starting ELOG. I 
don't know why this would affect the Quick Filter, and I'd assume that it 
would just stop working all together. Also, when I recompiled using "gcc -
O -o elogd elogd.c", I received the following warning:

elogd.c:546: warning: conflicting types for built-in function `logf'

Any suggestions?

Thanks!
Todd

> > I just updated ELOG using the latest elogd.c, and now my Quick Filters seem 
> > to stop working after the first or second filter attempt.
> 
> Can you try if you can reproduce the problem with the current version? I tried
> your settings and could not reproduce it. I remember that I fixed some problems
> with quick filters, but that was some time ago (Apr 04). If the problem
> persists, can you send me your exact elogd.cfg?

Recai Oktas replied to me and let me know that I needed to use dpkg to create the 
new Debian package instead of manually compiling it. I reverted to the original 
Debian package to get everything running normally again, but I haven't had a 
chance to try the upgrade again. As soon as I went back to the original elogd 
everything worked fine (no changes to the elog.cfg required). I'm assuming that 
the problem came from attempting to recompile a Debian package install manually. 
Sorry for the bug scare!

Todd

 Hi i am new here,

 OK :-|

Thanks for the quick response

Our group is interested in installing elog on a small/low-cost processing platform so that we can provide ready-to-run systems for our collaborators to use.  We selected a candidate platform form Technologic Systems, their wifibox-2 (http://www.embeddedarm.com/products/board-detail.php?product=TS-WIFIBOX-2).  This product is based on the TS7553 CPU board (http://www.embeddedarm.com/products/board-detail.php?product=TS-7553#) which has a 250MHz Cavium ARM9 CPU.

We have had good success getting the elogd executable cross-compiled for use on this platform and have a working system.  However, we are having significant issues with performance.  When we click the "New" item to enter a new event there is a noticable delay.  When clicking "Submit" there is a delay of approximately 10 seconds before the browser window displays the new event.  With the elogd running on other platforms (Virtual Machine or netbook) the delays for these actions are very small - typically less than a second or imperceptible.

So here are some specific questions:

- Is it reasonable to expect a 250 MHz ARM processor to serve an elog logbook with user acceptable performance?

- Our cfg file is attached.  Is there anything in the cfg file creating this performance problem.

- I have spent some time looking at this, and suspect that the delay is due to the cpu load of all the string manipulation and comparison operations (1200 calls to getcfg() on a submit).  Are there other candidate sources of performance issues that should be considered?

- Does anyone have any suggestions on how to improve our performance?

- Does anyone have a suggestion for an alternative small and low-cost COTS platform to use to host the elogd application?  (We would prefer to attain satisfactory performance on the Wifibox-2.)

Thanks for any help that can be offered.

Tim