Demo Discussion
Forum Config Examples Contributions Vulnerabilities
  Discussion forum about ELOG, Page 335 of 808  Not logged in ELOG logo
    icon2.gif   Re: Recursively open a new attribute of the same type, posted by Stefan Ritt on Thu Apr 22 12:29:05 2010 

Diogo Alves wrote:

Hi,

I have a logbook which, among other things, contains these attributes:

Options Ingredient = Egg, Oil

Options Quantity = 2, 0.1L

Now, I would like to, every time I select an ingredient and respective quantity, that another Ingredient and Quantity field opens up for me to procede addind them.

I've searched in the documentation and found nothing related to this. Maybe I missed it. Is it possible to do this?

Also, is there a way to display 2 attributes in the same row? Messing with CSS is probably the only answer ... correct?

Recursive attributes are not possible. All you can do is to define a certain number (like Ingredient1, Ingredient2, Ingredient3) and use Conditional Attributes to show them using the "Show Attributes Edit = ..." option.

To display two attributes in the same row, use 

Format <attribute> = 1

for the second attribute.

    icon2.gif   Re: Recursively open a new attribute of the same type, posted by Diogo Alves on Fri Apr 23 08:32:10 2010 

Stefan Ritt wrote:

Diogo Alves wrote:

Hi,

I have a logbook which, among other things, contains these attributes:

Options Ingredient = Egg, Oil

Options Quantity = 2, 0.1L

Now, I would like to, every time I select an ingredient and respective quantity, that another Ingredient and Quantity field opens up for me to procede addind them.

I've searched in the documentation and found nothing related to this. Maybe I missed it. Is it possible to do this?

Also, is there a way to display 2 attributes in the same row? Messing with CSS is probably the only answer ... correct?

Recursive attributes are not possible. All you can do is to define a certain number (like Ingredient1, Ingredient2, Ingredient3) and use Conditional Attributes to show them using the "Show Attributes Edit = ..." option.

To display two attributes in the same row, use 

Format <attribute> = 1

for the second attribute.

 

 Ok, thank you for your answer.

 

I guess my next question is whether it is possible to have, for example, 2 attributes:

Options Ingredient1 = 

Options Ingredient2 = 

Extendable options = Ingredients1, Ingredients2

sharing the exact same possible list of values.

 

Thanks agin.

    icon2.gif   Re: Recursively open a new attribute of the same type, posted by Stefan Ritt on Fri Apr 23 08:33:53 2010 

Diogo Alves wrote:

I guess my next question is whether it is possible to have, for example, 2 attributes:

Options Ingredient1 = 

Options Ingredient2 = 

Extendable options = Ingredients1, Ingredients2

sharing the exact same possible list of values.

If you add via an option to one Ingredient, you have to add it to the other as well. There is no automatic way to do that. 

    icon2.gif   Re: Record date isn't set to current date when replying to elogs, posted by Stefan Ritt on Mon Apr 15 17:50:20 2024 

Have you tried the config option "Preset on reply <attribute> = $date". On a reply, the <attribute> will be preset with the current date.

Stefan

Celeste Torkzaban wrote:

Hello,

I started using the record date feature in one logbook, since we plan to copy over old entries Joplin/Onenote. When starting a new entry, I see that the record date is automatically set to the current date, but when I reply to an elog, the record date is automatically set to the record date of the elog I'm replying to. Is there a way to fix this?

 

 

    icon2.gif   Re: Record Proliferation, posted by Stefan Ritt on Wed Mar 14 14:45:23 2012 

Paraic Fahey wrote:

Saving, using Submit sees recently updated fields cleared after hitting SUBMIT.

MOre significantly this then leads to a proliferation of instances of the same record being generated in the logfile and consequently on the logbook.

Has anybody a fix or advice on this?

I have not heard of that problem before.

The key to fix is to reproduce it, then teach me how to reproduce it. Only errors I can reproduce on my computer I am able to fix.

 

 

Best regards,

Stefan

    icon5.gif   Re: Record Proliferation, posted by David Pilgram on Wed Mar 14 15:34:41 2012 

Stefan Ritt wrote:

Paraic Fahey wrote:

Saving, using Submit sees recently updated fields cleared after hitting SUBMIT.

MOre significantly this then leads to a proliferation of instances of the same record being generated in the logfile and consequently on the logbook.

Has anybody a fix or advice on this?

I have not heard of that problem before.

The key to fix is to reproduce it, then teach me how to reproduce it. Only errors I can reproduce on my computer I am able to fix.

 

 

Best regards,

Stefan

 Does this occur if you are adding an attachment?  As I am blessed with forever using ancient systems, I've seen fields and indeed text  being cleared  because they were entered between clicking on 'Upload' for an attachment and the .png files being generated and displayed.  Answer here is patience - I use all too much of mine up in this exercise, sadly.

 

    icon2.gif   Re: Record ID corruption, posted by David Pilgram on Sun May 3 18:05:32 2020 

Hi,

I've had problems in the past due to a dodgy pointer creating branches despite a "No branches" in the configuration file.  It would be very interesting to see what the 200428a.log file looks like with these entries: in the screenshot they appear to be shown in time order, but do the "Reply to" and "In reply to" liknes in each entry (in the .log file) show a linear progression through the entires, a branch or indeed this same order as the screenshot.  If the duplicated entry sequential to 5657 (i.e 5658) then I would suspect something akin to my pointer's double click when I only made a single click, so fast that then second entry were created before the "No branches" checking part of the program had been reached.  Not so sure about such an event here unless entry 5658 were already open but not closed?

 

Regards,

David.

Frank Baptista wrote:

Hi all,

I've encountered an occasional problem that seems to be exacerbated by having a message with many replies.

In our use of ELOG, we run lengthy environmental tests (often several days) in multiple temperature chambers (one logbook for each chamber).  We document the start of the test with a log entry, and then periodically create replies -- first to the original log entry, and then to each successive reply (no branching allowed), in order to document how far along the test is.

What I'm seeing is an occasional "hiccup" in the order of records -- in the snapshot below, you can see that the record ID(s) go (in chronological order) ....5654, 5655, 5656, 5659, 5657, 5658, 5660, 5661....

Additionally, in this example, record ID# 5659 and record ID# 5657 are duplicates -- duplicate time stamp and duplicate text.

Has anyone else encountered this? 

Thanks,
Frank
 

 

    icon2.gif   Re: Record ID corruption, posted by Frank Baptista on Sun May 3 22:43:12 2020 200428a.log

Hi David,

Thanks for the quick response!  Well, I'd have to say that the sequence is as tangled as it looks in the logbook -- I've attached a copy of the log file for your reading pleasure. 

This one is definitely a "head-scratcher" for me...it definitely seems like it is more prevalent on log entries with many replies.

Thanks,
Frank

David Pilgram wrote:

Hi,

I've had problems in the past due to a dodgy pointer creating branches despite a "No branches" in the configuration file.  It would be very interesting to see what the 200428a.log file looks li looks like with these entries: in the screenshot they appear to be shown in time order, but do the "Reply to" and "In reply to" liknes in each entry (in the .log file) show a linear progression through the entires, a branch a branch or indeed this same order as the screenshot.  If the duplicated entry sequential to 5657 (i.e 5658) then I would suspect something akin to my pointer's double click when I only made a single click, so fast that then second e second entry were created before the "No branches" checking part of the program had been reached.  Not so sure about such an event here unless entry 5658 were already open but not closed?

 

Regards,

David.

Frank Baptista wrote:

Hi all,

I've encountered an occasional problem that seems to be exacerbated by having a message with many replies.

In our use of ELOG, we run lengthy environmental tests (often several days) in multiple temperature chambers (one logbook for each chamber).  We document the start of the test with a log entry, and then periodically create replies -- first to the original log entry, and then to each successive reply (no branching allowed), in order to document how far along the test is.

What I'm seeing is an occasional "hiccup" in the order of records -- in the snapshot below, you can see that the record ID(s) go (in chronological order) ....5654, 5655, 56 5656, 5659, 5657, 5658, 5660, 5661....

Additionally, in this example, record ID# 5659 and record ID# 5657 are duplicates -- duplicate time stamp and duplicate text.

Has anyone else encountered this? 

Thanks,
Frank
 

 

 

 

ELOG V3.1.5-3fb85fa6