Hello,

we have been using elog 2.7.1 as a logbook to signal problems and so on in our Engine Room Simulator for a couple of months now. Since this is exactly what we're looking for, I've installed the latest release in our sailing simulator as well. On this occasion I thought about updating the logbook in our engine room simulator as well. Unfortunately I cannot do that, because I get the error "elogd.exe is not a valid Win32 application" with every version of elog higher than 2.9.2 (so every version 3.x.x). The difference between our two simulators is that the elog package for the sailing simulator is installed on a Windows Vista machine, while the version for the engine room simulator is installed on a Windows 2003 Server.

Question: can I get/find/compile the latest version as a Win32 application and if yes: how or where?

Thanks,

Jean Pierre

From Version 2.2.5 on, the configuration file entries

User = ...
Group = ...

have been changed to

Usr = ...
Grp = ...

in order not to conflict with the new "Group = ..." option which is used by 
hierarchical logbooks.

Hello,

Is there a possibility to use like the time stamp a user stamp: by clicking the button in the main text entry it adds the username, just like the time stamp button does: Tue Apr 12 08:58:46 2022 ?

I searched but I'm not sure how this would be correctly named.

Thanks,

G

Have a working copy of 1.35 running on NT4 server.
Went to upgrade to latest version.
Stopped service, installed the 2.52 version, restarted service and when 
trying to connect get nothing but server not found, dns errors, etc.
Copy back the 1.35 elogd.exe and everything is fine - I can connect and add 
entries to log.
Copy 2.52 elogd.exe and nothing.

So being the bright boy, I unistalled E-log, went through the registry and 
yanked everything out that referenced ELOGD, rebooted, installed 2.52, made 
the necessary registry changes, started service and nothing. 

Stopped service and copied 1.35 Elogd.exe back into folder, started service, 
and everything works.

Any ideas on why 1.35 works like a charm but 2.52 won't? I've tried stepping 
back to 2.10 version before giving up.

This is a server that is patched to latest and runs quite well with 1.35.

We have a logbook in which we use two "Status" attributes, both of which are MOptions. What we want to do is have the corresponding line of the list change its colour depending on the combination of those attributes. I have done so successfully using "Style" for a single Options or MOptions or even two Options (using conditionals and a third attribute), but up until now I have no luck with two MOptions. Conditionals do not seem to work with MOptions (the manual only mentions Options and when I tried anyway, it did not work... ) and multiple "Style" statements also do not seem to work. I've tried the following:

MOptions StatusA = Status-A-red, Status-A-orange, Status-A
MOptions StatusB = Status-B-red, Status-B-orange, Status-B

Style StatusA Status-A-red = background-color:red
Style StatusA Status-A-red | Status-A-orange = background-color:red
Style StatusA Status-A-red | Status-A = background-color:red
Style StatusA Status-A-red | Status-A-orange | Status-A = background-color:red
Style StatusA Status-A-orange = background-color:orange
Style StatusA Status-A-orange | Status-A = background-color:orange
Style StatusB Status-B-red = background-color:red
Style StatusB Status-B-red | Status-B-orange = background-color:red
Style StatusB Status-B-red | Status-B = background-color:red
Style StatusB Status-B-red | Status-B-orange | Status-B = background-color:red
Style StatusB Status-B-orange = background-color:orange
Style StatusB Status-B-orange | Status-B = background-color:orange

As far as I can see, the "Style" statement for StatusB only gets evaluated if none of the statements for StatusA matches (i.e. StatusA = Status-A). What I would want to achieve is that any "red" condition in either StatusA or StatusB takes precedence over "orange" and "none" and that "orange" takes precedence over "none".

Is there any solution for this problem short of merging both status attributes into one (which would be very unwieldy, especially, as StatusB is not used at all in some cases)? Any suggestions are most welcome!

Thanks in advance,

Thomas