Opened 15 years ago
Last modified 9 years ago
#206 new enhancement
multi selection boxes
Reported by: | westram | Owned by: | devel |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Library (GUI) | Version: | SVN |
Keywords: | Cc: |
Description (last modified by 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)
Change History (12)
comment:1 Changed 15 years ago by westram
- Owner changed from devel to westram
- Status changed from new to assigned
comment:2 Changed 15 years ago by westram
- Component changed from Libraries (several) to Library (GUI)
comment:3 Changed 15 years ago by westram
- Description modified (diff)
comment:4 follow-up: ↓ 5 Changed 11 years ago by epruesse
- Cc epruesse@… added
comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6 Changed 11 years ago by 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.
comment:6 in reply to: ↑ 5 ; follow-up: ↓ 7 Changed 11 years ago by 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).
comment:7 in reply to: ↑ 6 ; follow-up: ↓ 8 Changed 11 years ago by 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...");
comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 11 years ago by 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?
comment:9 in reply to: ↑ 8 Changed 11 years ago by westram
Replying to epruesse:
Do you have a place with a simple example where I can try a multi-select API?
Delete field?
comment:10 Changed 11 years ago by westram
- Owner changed from westram to devel
- Status changed from assigned to new
comment:11 Changed 9 years ago by westram
remove outdated recipient
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?