Possible Query Keyword bug

Hi Josh,

I have reproduced the problem with spaces in keywords.  What is happening is that when the keyword is stored in the show, all spaces get converted to underscores, probably becuase spaces in the keyword make it look like two words to the parser.  The spaces are not getting converted when stored as the Text fields in patch, so when you run a query, they won't match.  I can fix this by converting the spaces to underscores on import, so the mismatch won't arise.

I have not had any luck reproducing the problems with keywords starting with digits or problems with the Template field.  Can you send the file you exported from LW to Eos-Ion.Mailbox@etcconnect.com?

Thanks,

Ann

Thanks, Josh. 

I have emailed you directly, and included a fixed .txt file.

For anyone else experiencing one of the supported columns not reading in correctly, the issue in this case was an errant non-displayable character in the heading "Template".  Retyping the word fixed this. 

As for the other issue, keywords are not allowed to start with a digit, so adding an underscore before the word solves this problem.  1.8 code will automatically add underscores for keywords that require them.

Ann

Hi Ann,

I've also noticed that "greater than" > "less than" < and "circumflex accent" ^ don't post as the first character either, which is how many ALDs input purpose into LW (e.g. <--Low X).

Will it be possible to fix this without using an underscore? or is this an XPE thing.

Thanks,

-M 

Hi Marc,

I checked into this and found the problem, which is more general than just imports.  We will get it fixed for 1.9, where underscores will automatically be added for all keywords which start with a digit or space so that the parser will recognize them in queries.  The underscore won't be needed for < > ^ or other non-numeric characters.

Thanks for the report. 

Hi Marc,

I checked into this and found the problem, which is more general than just imports.  We will get it fixed for 1.9, where underscores will automatically be added for all keywords which start with a digit or space so that the parser will recognize them in queries.  The underscore won't be needed for < > ^ or other non-numeric characters.

Thanks for the report. 

Hey Ann,

I've noticed a couple other curiosities in text fields and queries, regarding LW:

1) For some reason LW exports scrollers into Excel with superfluous quotation marks as:

"7.5"" Colorram II

This is fine if I catch it as I am tweaking the excel file, but if I (or the elec) happens to miss some it breaks query. Trying to [Query] {"7.5""...} posts as either:

[chans] Error: Syntax error--- but then seems to function properly (i.e. I can hit @ and effect channels).

Or

Query Notes " Cue 7.5 Error: Cue does not exist --- and does not function (i.e. I cannot effect channels as there is no channel list).

The difference between the 2 examples is in the former I have a cue 7.5 recorded into the desk, in the latter, I do not.

2) Text fields imported from LW have spaces not underscores (e.g T-3 Strip), but when I type the same thing directly into the text field in patch I *do* gt underscores (e.g T-3_Strip), which creates two separate Keywords in Query. 

Not show stoppers, but I thought I'd share.

-M

Hi Marc,

The fix I intended for 1.9 is to make the patch code automatically convert spaces to underscores before storing keywords regardless of how the keywords are created, so your second example should be fixed by this.  The command line generally doesn't print the underscores, but the query will see them and should work.

I will look into the double quotes problem.  I haven't seen that one before, but we should be able to work it into 1.9 also.

Thanks,

Ann

Hi Marc,

I tried typing 7.5" Colorram II in LW 4, then exported the data to a .txt file, but I did not get the spurious quotation marks.  Then I typed them directly into the LW file so I could try importing it into Eos.  I was able to reproduce the errors that you saw.  The cause seems to be that the Eos parser reserves certain characters for functions, and will throw an error if one of the characters exists in a keyword.  In this case, it is the decimal that is causing the problem.  There were other punctuation characters that could be handled, but were not.  In the fix for 1.9, this won't be an issue, because the characters that the parser doesn't allow won't be able to be recorded into a keyword.  Specifically, the following characters will be replaced by underscores:

+ (plus),    - (minus),    @ (at),     . (decimal),      / (slash),     space

I have tried the same LW file with the 1.9 fix and the keywords come in as _"7_5"" or _7_5", and these both work in queries. 

Thanks,

Ann