kerrymcclain

Playing with it a little more, I've mapped the output parameter to a document property instead of a column, displayed in a label at the top of the text area shown below. This makes me curious about when multiple ID's are already selected...the aggregation in the expression that should be creating our sort column is always going to be working with everything that's been marked (3 properties in this example)...how will we know which ID was just clicked/marked and which were already marked? It almost seems like we need a timestamp in the mix somehow to identify when each click occurred in a temporal context to order them properly. what do you think?

I think I'm close, but something is still not quite right. Here's where I'm at... The R script setup: Input parameter setup: Output parameter setup: When I set it all in motion, I get this error: I feel I'm missing something basic here, but I'm not able to see what's wrong... Any ideas? Thank you, Kerry

Good morning, Olivier - I'm tinkering with it now. I believe your solution will work, and I should know for sure shortly. I'll update with my findings soon. Thank you again for the concept!

Thanks for your quick response, Olivier. I thought it might be good for me to clarify my use case, I think I may have not explained it clearly. Here are some screenshots, and I'll walk through the use case for clarity... On the map, we need to select a group of polygons (representing real estate parcels). Each one of the parcels has a unique identifier, a Parcel ID. As we go through the one-at-a-time selection process, I want to build a list of the Parcel ID's in the order that they were selected. Conceptually similar to loading a LIFO queue. So...here's the first step. The user marks the first parcel (R000069319), and that row shows up in the child table below. I'll mark each row with a red number to denote which click it was: Next, the user clicks parcel R000069142, and the second row appears in the child table as we had hoped: So far, so good. Now, the user clicks the third parcel (R000101858), and the issue appears: Instead of the rows in the table being in the click order of 3, 2, 1...we've now got 2,1,3. If we carry this one more step, the 4th click also gets farther from what we want: Now the rows are in click order 2,4,1,3...when we need is 4,3,2,1 (the order they were selected in). So...that's more detail about what I'm trying to achieve...hopefully this will make more sense than my first try. Thanks again for any ideas you can throw out, I appreciate your time. Kerry

Seems like this should be easier to crack, but I haven't put all the clues together yet and would appreciate any ideas... Use case: Assume a dataset that contains an arbitrary number of rows of data, with each row containing a unique identifier. A user needs to be able to select (mark) one row at a time, on a map chart in this case. With each successive marking, I'd like to dynamically generate a sequential list of the unique identifiers that will be *IN THE ORDER THAT THEY WERE SELECTED BY THE USER*. This requirement seems to be the rub. Native functionality using a child table visualization for the selected rows to show up in works for the first few rows, but as you add more selections, the rows will not stay in the sequential order in which they were selected. That's a messy explanation, but that's what I'm trying to achieve. There's got to be a way to achieve this via IronPython, but I'm not sure how to go about it. I've been using IronPython scripting for years, just haven't run into this particular puzzle before & I'm not sure how to tell which particular row was just marked (to be able to add just that unique ID to the derived, sequentially ordered list) + how to account for a user changing their mind about a marking and unmarking it (which should remove just that unique ID from the list). Any ideas on an approach that might work? Thank you, Kerry