[Scilab-Dev] Regarding tooltps in uitable
Rishubh Jain
rishubhjain at ymail.com
Sun Jun 5 16:03:26 CEST 2016
Hi,
I am sorry I didn't explain properly, I will elaborate from the scratch.
For now I have made 2 features available through which one can input tooltip String.Case 1: table_variable.tooltipstring=["a","b","c","d"];
//Here a,b,c,d are string literals. table_variable.tooltipstring=[a,b,c,d]; //Here a,b,c,d are variables where a,b,c,d can be single string literal so a="tooltip1";b="tooltip2";c="tooltip3";d="tooltip4"; table_variable.tooltipstring=[a,b,c,d]; The format of output will be:
!tooltip1 tooltip2 tooltip3 tolltip4 ! //suppose table_variable.tooltipstring=["a","b","c","d";"a","b","c","d"]; I want to assign "[a,b,c,d]" to 2nd row and 3rd element. table_variable.tooltipstring(2,3)="[a,b,c,d]"; The format of output: !a b c d ! ! ! !a b [a,b,c,d] d !
One can also input tooltips in the given fashion below;
TT=emptystr(.string); TT([pos1 pos2 pos3..]) = ["tt1 "tt2" "tt3"...];
Case 2: table_variable.tooltipstring="[a,b,c,d]"; 1-> How this will be used? This will be useful when all the elements passed in the tooltipString are strings and not variables.
table_variable.tooltipstring="[a,b,c,d]"; <-> table_variable.tooltipstring=["a","b","c","d"]; //so a,b,c,d are characters and not variables
2-> When this will be used? This is useful for a particular case i.e when the elements to be passed are string literals and
not variables AND when the string is large so user wont have to enter the double quotes("") so many times,for example;
table_variable.tooltipstring=["a","b","c","d","e","f","g","h","i","k"]; etc...now in this case table_variable.tooltipstring="[a,b,c,d,e,f,g,h,i,k]"; will be easier then the number of elements(n) increases significantly.
This is not very useful but it was something I thought so I incorporated.
I hope this may solve the confusion,
Thanking YouRishubh
On Sunday, 5 June 2016 1:32 PM, Samuel Gougeon <sgougeon at free.fr> wrote:
Hello,
Le 05/06/2016 09:31, Rishubh Jain a écrit :
Hello,
Thank You for your inputs. 1) I have updated my code and now I accept both types of input. ut.tooltipstring = ["a","","c","d"]
and
ut.tooltipstring = "[a,b,c,d]"
The first one if the user want to input variables(string type) and also as Samuel suggested one can input only few non-empty strings TT=emptystr(.string); TT([pos1 pos2 pos3..]) = ["tt1 "tt2" "tt3"...];
The second one if the user wants to just input strings(no variables) but dont want to input so many "" (This is my opinion)
.
I am afraid i don't understand your point at all.
If you use
ut.tooltipstring = ["a","","c","d"] // to input variables(string type) (i guess named "a", "c", "d"),
then how will it be possible to input the literal strings ["a","","c","d"] ?
Moreover, if i want to set just one component tooltipstring(2,4) = "[a,b,c,d]" with "[a,b,c,d]" being a single literal string, how should i do?
IMO, interpreting symbols as variables should really be abandoned. BTW, what would be the interest wrt to = [a,b,c,d], a, b,c,d being some variables containing a single string?
2) Q: Could you confirm that your implementation for the case 2) updates .tooltipstring when .string is modified? A: Yes, it does :)
Great.
3) If possible I wanted to know what exactly the flag I should use, I want to use a flag instead of passing the whole data because of the reason I described. So if you think its better to use flag then I would like to know which flag I should use.
.
A flag is needed mainly because this is the only way to tell/trigger that the automatic mapping .string => .tooltipstring must occur.
The literal single string "values" looks convenient to me. We will never build a table with only one cell. It is meaningless. So there won't be any ambiguity.
Thanks
Samuel
_______________________________________________
dev mailing list
dev at lists.scilab.org
http://lists.scilab.org/mailman/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/dev/attachments/20160605/3337c1f8/attachment.htm>
More information about the dev
mailing list