Subscribe to this thread
Home - General / All posts - "Selected" via Release 9 API
joebocop
380 post(s)
#05-Mar-19 20:07

In release 8 a recordset's record object had a boolean "Selected" property that indicated, you guessed it, if the record was "selected".

I've been struggling to detect the equivalent state in Release 9.

Sequence.GetValues() produces as ValueSet object, but the individual values returned do not include a "Selected (I)" or some other such obvious marker.

Is there a way of detecting this? Anything better than creating and running a query to CALL SELECTION() and then just iterating on that resulting Sequence?

Thanks.

Dimitri


5,452 post(s)
#06-Mar-19 04:07

Taking a look at SQL functions for selection may be helpful: SQL Example: Using Selection Query Functions

adamw


8,579 post(s)
#06-Mar-19 06:42

What's wrong with CALL Selection(...)?

If you want to save the selection into a field, you can run UPDATE on the result of CALL Selection(...):

--SQL9

 

-- unmark all records at first, if needed

--UPDATE component SET selected = FALSE;

 

-- mark all selected records

UPDATE (TABLE CALL Selection(component, TRUE)) SET selected = TRUE;

Anyway, if you are looking for a per-record flag similar to [Selection (I)] from 8, you can do this:

--SQL9

 

-- if selection is inverted, selection keys store data for unselected records

--

SELECT * FROM mfd_root WHERE

  (mfd_id IN CALL SelectionKeys(mfd_root)) =

  (NOT SelectionIsInverted(mfd_root));

 

-- or:

SELECT * FROM mfd_root WHERE

  (mfd_id IN CALL SelectionKeys(mfd_root)) XOR

  SelectionIsInverted(mfd_root);

This requires knowing the field(s) used as a selection key - you can determine them for any component by checking the output of TABLE CALL SelectionKeys(<component>).

ColinD


1,918 post(s)
#06-Mar-19 10:53

Similarly, in M8 I frequently theme Selection (I) to turn selected points visible by selecting based on an attribute such as scientific name from among over 100k points. Many of the points are records of several different species at the same location so a simple select will not show all selected. This is done to get a quick feel for distribution within particular geographic areas. I know even I could write a query to create a table of occurrences within the areas of interest but sometimes a quick visual is all that's needed. Is it likely that M9 will provide a similar function?


Aussie Nature Shots

Dimitri


5,452 post(s)
#06-Mar-19 11:38

Is it likely that M9 will provide a similar function?

You mean... slower to use, and profoundly less capable than the way it is done now in 9? :-)

This is no faster than the 9 way, but it is way more limited:

I frequently theme Selection (I) to turn selected points visible by selecting based on an attribute such as scientific name from among over 100k points.

adamw


8,579 post(s)
#06-Mar-19 15:33

Is it likely that M9 will provide a similar function?

We'll probably extend View - Filter to work on components other than tables.

That way, you'd select something, and then be able to do View - Filter - Selected to limit display in the current window to just the selection.

dchall8
614 post(s)
#07-Mar-19 18:21

In M8 my typical use for Selected is to turn labels from off to on. I set the default label color to invisible and use the color theme to change the color to black or cream based on selectedness. When I open a M8 file in M9, that selectedness feature comes across, but not quite as I expected. In this picture from M9 you can see a selected parcel with the label created in M8. Instead of being black, the label is red. Never mind that the label does not have valid data, that's another issue. The point is that selectedness is already in M9. We just need to find the best way to use it for what we need. The functions seem to be those highlighted in yellow. Writing a query every time I want to do something based on selection would be very discouraging to use.

Attachments:
Selection Functions in M9 - Expressions.jpg

adamw


8,579 post(s)
#08-Mar-19 11:29

Selections in 8 and 9 differ in that in 8, selections are persistent, and in 9 they are not. That's why in 9 we don't have a field analogous to Selection (I) in 8. But that's also why we can select read-only data, for example - couldn't do it in 8, the data had to be writable and the act of selecting it was altering it, asking for a save after.

The main question is how dynamic you want the way your labels show and hide to be.

You can, for example, save the selection into a regular boolean field using the Saved tab in the Select pane, then format labels using that field. Then, when you change the selection, you can resave it to the field using the same Saved tab in the Select pane and the labels will reformat (if we don't currently detect changes to fields used for labels automatically, we'll do so - I'll check later).

If the Saved tab in the Select pane is too tedious to reach, we can work on that. Eg, we can provide enough data for add-ins to allow creating an add-in to save the selection to a pre-defined field and we could allow putting add-ins to the toolbar. Or we can do something else.

Mike Pelletier


1,602 post(s)
#08-Mar-19 15:29

Seems like this approach also creates problems with wanting to apply styles to read-only vectors.

Could 9 create some sort of internal table that acts as an interface table to allow persistent selection, styling, robust undos, and not require a save after every vector edit (currently really slows down editing)? If possible, it could benefit more than just read-only data. Maybe it could act like a sketch pad before committing it to the canvas of a fine painting.

It would be great if the selection pane had some sort of selection history, sort of like photo editing programs show a history of changes and allow one to go back to a prior state.

tjhb

8,760 post(s)
#08-Mar-19 18:09

Wow, that’s a real mixture of ideas Mike.

Regarding the first thing, we can create any number of additional drawings for a read-only table, and each of those drawings can be separately (and persistently) styled. The geometry remains read-only, because that is in the table, but styling goes with the drawing, which is not.

Regarding the last thing, we already have saved selections. Are you looking for automatically saved selections? If so why—when would they be useful?

Mike Pelletier


1,602 post(s)
#08-Mar-19 19:05

Well its Friday here so why the heck not :-)

Yes we can copy the read-only drawing, paste it, rename it, and style it, although without full suite of styling options created by having a style field. What purpose do these steps and limitations serve when it could be handled internally? When do we want to view a read-only drawing and not style it?

Admittedly this is not a big deal on its own, but I'd dearly love to have fast vector editing (free of constant saving commands) and robust undos. There has to be some way for Mfd to offer that with simple data (non-multi-user). Mfd has been reluctant to tackle this in the past, seemingly because of a stronger desire to work with big, multi-user data in traditional ways. Perhaps if there was enough justifications, they would figure out a way to make it work.

Applying filters to images is an exploratory process to reach the best option. Same thing happens when digging through different filtering techniques to find the best data in a table or drawing for a particular question. Once you find it, wouldn't it be nice if Mfd kept track of your method and perhaps allow removing a step and re-running it. Saving the selection of course is good, but saving the method would be even better.

adamw


8,579 post(s)
#09-Mar-19 07:16

We are hearing you on fast vector editing and the undo, and have some plans for that.

Regarding treating filters as an exploratory process and saving the method - you can do this right now with queries and computed fields. Eg, instead of doing filter A, then filter B, then filter C in the transform pane, then starting all over because the final result is slightly different from what you wanted, you can set up filter A, click Edit Query, then add filter B and filter C into the query text - altering and re-running the query until the result is what you want. The query is the method. I get that you might prefer having something more visual, like a history of applied transforms - maybe we could have that as well eventually.

Manifold User Community Use Agreement Copyright (C) 2007-2017 Manifold Software Limited. All rights reserved.