LIST_TABLE_START function fails in Word Document

KasiaBM

Hello,

I'm quite new to Aware IM and don't know everything about it so forgive for bringing up the same topic.

I already searched through forums and user guides with regards to my problem, which is:

I am trying to create an MS Word document, which contains information about Project objects. Each Project has a lot of attributes and three collections: activities, risks and opportunities (represented by Activity, Risk and Opportunity objects respectively). Each of them have different statutes and that's where I hit the brick wall. I need to display Activities in two different tables: open and completed. When I populate a table with all Activities the document is produced fine. As soon as I try to use a query in LIST_TABLE_START function I get an error "Invalid tag expression... in document null".
The query I am trying to run:

<<LIST_TABLE_START(‘FIND Activity WHERE Activity IN Project.Activities AND Activity.Status=”Open” ’)>><<Activity.DateDue>>

And then goes the remainder of the row in the table.

I tried changing single quotation marks to double, switch them around, omit them around the query etc.
I tried to save this query in Aware IM and then use its name as an argument to the function.
I tried to search for indicators that the syntax is incorrect but it appears to be fine.

If I just use Project.Activities (no quotation marks) as an argument then the document get saved correctly.

Any pointers would be very appreciated.

I am currently on v7.0 on Windows 10 and the template is saved in .docx format.

Many thanks,
Kasia

KasiaBM

Sorted!

Aware IM doesn't seem to accept quotations marks implemented by MS Word. Whilst entering the query in the notepad and copying it into the word document didn't work but copying the query name in single quotation marks into the function worked.

This is a bit of a joke and I hope it'll get resolved in future. I can't imagine having to copy and paste stuff from one application into another to make it work when that shouldn't be the case.

Thanks.