Hi Francois,
as far as I know there is a limit on the number of conditions you can use (See elog:67303).
I guess you did hit that limit.

I think I've mentioned recently that ELOG is not a relational database, didn't I?
It is of course possible to drive screws with a hammer, but there do exist more suitable tools for that ;-)

Kind regards
Andreas

> Hi Francois,
> as far as I know there is a limit on the number of conditions you can use (See elog:67303).
> I guess you did hit that limit.
> 
> I think I've mentioned recently that ELOG is not a relational database, didn't I?
> It is of course possible to drive screws with a hammer, but there do exist more suitable tools for that ;-)
> 
> Kind regards
> Andreas

Got it...
But again, I found it strange that it works from time to time.... is it an elog limit or a javascript issue....

the guide mentions :
Options <attribute> = <list>
Usually, an text field is used for an attribute, where the user can fill in text of up to 100 characters.
but no words on options size...

I would say if it was a size issue it would not work at all no ?... but now it works from time to time....
But you are right, maybe I should get a bigger hammer :)

Seriously, I really hope It could make it... Could you try it on your side ? could I enable some sort of debug mode other than running elogd from a shell ?

 
> Seriously, I really hope It could make it... Could you try it on your side ?

My personal opinion here is, that if you want others to investigate your problems, then the best way to do it is like that:
- attach a minimal configuration that reproduces your problem (never attach a 100 line configuration, unless you've tested that the problem disappears
regardless of which line you remove!);
- attach the entry data, if the behaviour depends on the data;
- use a specific, to the point subject line;
- explain what you did, what happened and what you would have expected to happen;
- ask kindly; and then
- wait and hope for the best ;-)

(This is actually a very general procedure; I think it is applicable to all newsgroups, forums, etc.)

BTW: This tip was absolutely free of charge ;-)

>  
> > Seriously, I really hope It could make it... Could you try it on your side ?
> 
> My personal opinion here is, that if you want others to investigate your problems, then the best way to do it is like that:
> - attach a minimal configuration that reproduces your problem (never attach a 100 line configuration, unless you've tested that the problem disappears
> regardless of which line you remove!);
> - attach the entry data, if the behaviour depends on the data;
> - use a specific, to the point subject line;
> - explain what you did, what happened and what you would have expected to happen;
> - ask kindly; and then
> - wait and hope for the best ;-)
> 
> (This is actually a very general procedure; I think it is applicable to all newsgroups, forums, etc.)
> 
> BTW: This tip was absolutely free of charge ;-)

Andreas,
Thanks for your comments. Thats why I posted in the first msg my configuration details... I just hope there can be a solution :)
I saw in the doc that an attribute cant be bigger than 100 char. but I couldn't figure the maximum size for options...  I'm wondering if the issue comes from the browser not refreshing correctly or if its elog..
Again, I tought that if that was from elog limitations, the attributes wouldn't load the options presets at all... but they do, (attribute volume) ... just not all the time :)

I understand that you are proactive on this forum and eventually I was thinking of contributing with detailed specific config examples but for now I just would like to get on track :) 
The last time I used Elog was 10 years ago :) it changed alot since :)

> I saw in the doc that an attribute cant be bigger than 100 char. but I couldn't figure the maximum size for options...  I'm wondering if the issue comes from the browser not refreshing correctly or if its elog..

The number of possible options is limited in elog to 100. This is defined by MAX_N_LIST in elogd.h. You can try to increase it and recompile elogd, but no guarantee that this works.

The reason that it *sometimes* work is really a bug, I should do better limit checkings...

/Stefan

I just upgraded to 3.1.0 after many years using 2.9.2. Our eLogs are absolutely crucial for the operation of our accelerators, so first of all I'd like to say: thanks a lot for everything you've done! It's a rock-solid application that works really well.

The issue I'm having is a minor one. Some of our users are using Internet Explorer 11, which has a Compatibility Mode option that is enabled by default for intranet sites (of which our eLog is one). This mode emulates IE7, and this causes the CKEditor rich text box to fail to load. I can tell our users to disable the CM setting on their browsers, but it may be that a simple server-side fix is possible as well.

It would be nice if the eLog pages could have a <meta name="viewport" content="width=device-width, initial-scale=1.0"> tag, so that it displays nicely on smaller screens. I've been adding this myself in some Javascript code (see elogHelper.js on the above-linked website), but it doesn't appear on every page (the logbook selection page, for instance). I also made some modifications to the CSS so that the list display collapses down when the browser window is very narrow.

The new autosave functionality is really good. I hacked something together to do this for our log a while ago, but it's nice that it's inbuilt now.

Thanks again!

Ben

I don't get your point. If you add the meta tag wiht the viewport, then the IE7 mode will load the CKEditor? The CKEditor home page says that IE7 is not supported any more, so I wonder if this simple tag might help. Can you turn off the compatibility mode on a per-URL basis?

If I try on my smatphone, the display is correct, so why you need the viewport tag? Can you shouw me examples?

If you have nice CSS features which are helpful for everybody, please send them to me and I can include it in the distribution, but only after you convince me that it works (almost) everywhere.

Best,
Stefan

The viewport thing and the IE7 mode thing are separate issues.

OK, maybe it's a CKEditor thing then. I thought it might be. It seems pretty stupid that the default setting in IE is to emulate an older browser - although I guess a lot of people have very outdated intranet sites. Anyway, we have a fix here so I don't think you need to do anything. Just thought you might want to know.

The viewport tag issue - see attachments. The first two are the log selection page and the list page, both without the viewport tag. Obviously you can zoom in, but this is how they appear by default, as (apparently) Chrome tries to render the whole page width. The third one is how the list page appears when the viewport tag is added, and the fourth is with my custom CSS to put the columns on separate lines. It's probably very bad CSS, so I'm certain that it's not robust or cross-platform, but it works for me :)

/* make things look a bit nicer on smaller screens */
@media (max-width: 700px) {
	table.listframe td, table.listframe th {
		display: none;
	}

	/* show id, date, personnel, summary in separate lines */
	table.listframe td:nth-of-type(-n+2), table.listframe td:nth-of-type(4), table.listframe td:nth-last-of-type(2) {
		display: block;
		border: 0px;
	}
}