Community
Participate
Working Groups
In unbound modules are the following test steps for checking existence and enablement of tabs: 1. ub_tpn_checkExistenceOfTab_byValueOrIndex (String) 2. ub_tpn_checkEnablementOfTab_byIndex (Integer) 3. ub_tpn_checkEnablementOfTab_byValue (String) if I want to use the integer parameter in a module I have to provide to parameters of the same value (one for Integer, one for String). Every change has to be done twice. It would be better to split the first step in two: 1.a. ub_tpn_checkExistenceOfTab_byValue (String) 1.b. ub_tpn_checkExistenceOfTab_byIndex (Integer) This way I can also avoid problems with tabs that has a number as name.
Another alternative would be to join the modules that currently use just index or just value so that they also act with either. We made the decision to go this way for new modules (e.g. table headers) a while ago to keep the libraries "slimmer". Tabs which have numbers as names should be able to be addressed using the operator "matches" like so: .*12345.* or '12345'. "12345" is then interpreted as a string, not an integer. Another possibility would be to make String and Integer parameters compatible with each other.
(In reply to comment #1) > Another alternative would be to join the modules that currently use just index > or just value so that they also act with either. We made the decision to go > this way for new modules (e.g. table headers) a while ago to keep the libraries > "slimmer". > > Tabs which have numbers as names should be able to be addressed using the > operator "matches" like so: .*12345.* or '12345'. "12345" is then interpreted > as a string, not an integer. > > Another possibility would be to make String and Integer parameters compatible > with each other. This is another possibility. But I think the test developer should make a decision if he want to use the index or the value. The .*-Solution smells a little bit like workaround for me ;-)
I still agree that this is a change that we might want to do, but I don't see us doing it in the near future. Marking as wontfix. If anyone has other / new arguments, please reopen.
Closed due to comment 3
