multi selection boxes

[westram]

Implement a list where the can select multiple values at the same time

• all selected values should be hold as value list (awar containing ';'-separated string of values)
  • ';' in values needs to be escaped
  • provide functions to convert such a list into an array of string and vice versa
• there was already sth started in WINDOW/AW_button.cxx (see create_multi_selection_list)

• needed for several purposes
  • e.g. #65
  • transfer fields of species (merge tool)
  • convert fields (infowin)

[epruesse]

Would it make sense to have "array awars" for this?

We've got string, int, double and pointer so far. Having corresponding array types would make sense as those are already supported by ARBDB.

Incidentally: what is GB_LINK? is that a "name"? would it make sense to have those as explicit awars as well?

[westram]

Replying to epruesse:

Would it make sense to have "array awars" for this? We've got string, int, double and pointer so far. Having corresponding array types would make sense as those are already supported by ARBDB.

Seems to make sense, but there are a few drawbacks:

• currently POINTER can be used with care only (afaik only used in search-tool). e.g it does not macro-record
• all other awar types got an 'as_string' representation, which is also used for macros. This is difficult for arrays.

I think it would be more handy to use a string representing a multi-selection (s.th like "VAL1^VAL2^...").

Incidentally: what is GB_LINK? is that a "name"? would it make sense to have those as explicit awars as well?

It was an attempt to create sth like an alias (done by oli b4 he left). It's mostly unused (and obsolete). So no, makes no sense.

[epruesse]

Replying to westram:

Seems to make sense, but there are a few drawbacks:

• currently POINTER can be used with care only (afaik only used in search-tool). e.g it does not macro-record

The ARBDB backend of AWAR assumes it's a GBDATA*, and ARBDB can store pointers. Are those written to disk? I assume that this could only work for pointers within the same , so there'd have to be checking that the pointer is a GBDATA* that has the same gbmain as the gb_var. Or it'd have to be serialized to a string by finding the path for the GBDATA*.

• all other awar types got an 'as_string' representation, which is also used for macros. This is difficult for arrays.

I think it would be more handy to use a string representing a multi-selection (s.th like "VAL1^VAL2^...").

Isn't that just an implementation of as_string? The awar_*_array classes would simply have to implement serialization and deserialization. Unless we use something like '\0' as separator, there has to be escaping anyway. And using '\0' or similar feels dangerous to me…

Incidentally: what is GB_LINK? is that a "name"? would it make sense to have those as explicit awars as well?

It was an attempt to create sth like an alias (done by oli b4 he left). It's mostly unused (and obsolete). So no, makes no sense.

I can see where he was going with that. Might have been neat, but it's a project for another day (year).

[westram]

Replying to epruesse:

Replying to westram:

Seems to make sense, but there are a few drawbacks:

• currently POINTER can be used with care only (afaik only used in search-tool). e.g it does not macro-record

The ARBDB backend of AWAR assumes it's a GBDATA*, and ARBDB can store pointers. Are those written to disk?

No.

I assume that this could only work for pointers within the same , so there'd have to be checking that the pointer is a GBDATA* that has the same gbmain as the gb_var. Or it'd have to be serialized to a string by finding the path for the GBDATA*.

It just should not be used. I introduced it only to make things a little bit more obvious, while avoiding a rewrite of the db-scanner. Originally "someone" casted a GBDATA* into an int and saved that into an int-awar. Look ​here

I think it would be more handy to use a string representing a multi-selection (s.th like "VAL1^VAL2^...").

Isn't that just an implementation of as_string? The awar_*_array classes would simply have to implement serialization and deserialization. Unless we use something like '\0' as separator, there has to be escaping anyway. And using '\0' or similar feels dangerous to me…

Using '\0' wont work, it has to work from macro-code, e.g.

BIO::remote_awar($gb_main,"ARB_NT","cont/my_str_array","cont1^cont2...");

[epruesse]

Replying to westram:

It just should not be used.

Ok. I'll have to mess with db-scanner anyway if I want to have multi-column . Maybe I can come up with a way that's fast enough but doesn't need to store pointers in AWARS.

Using '\0' wont work, it has to work from macro-code, e.g.

BIO::remote_awar($gb_main,"ARB_NT","cont/my_str_array","cont1^cont2...");

I'm sure perl can somehow handle char arrays with 0 characters in them. But it's ugly, so no.

Do you have a place with a simple example where I can try a multi-select API?

[westram]

Replying to epruesse:

Do you have a place with a simple example where I can try a multi-select API?

Delete field?

[westram]

remove outdated recipient

[westram]

try again