Hi,
Just wondering if this is a known limitation:
An input control to a text attribute with static choices works - it shows a drop down with the predefined choices.
However, an input control to a text attribute with dynamic choices doesn't. The query works and the choices are correctly filled out, but the input control itself does not show anything (no drop down, no results, nothing).
I can provide here a BSV to demonstrate this if anyone is interested.
andrei
Input Control doesn't work when choices are determined at runtime?
-
- Posts: 1463
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: Input Control doesn't work when choices are determined at runtime?
Can you create a BSV please, it's not possible to diagnose from this info. Thanks
Re: Input Control doesn't work when choices are determined at runtime?
No problem, but it tells me Error Invalid file extension: Test_20220524_2204_InputCtrl.bsv
So I can attach only pictures?
Edit:
I the meantime, here are screenshots:
I've set up two text attributes, one with static choices and one with dynamic choices taken from a query:
seems I can upload only 3 images, so one more to come..
So I can attach only pictures?
Edit:
I the meantime, here are screenshots:
I've set up two text attributes, one with static choices and one with dynamic choices taken from a query:
seems I can upload only 3 images, so one more to come..
-
- Posts: 1463
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: Input Control doesn't work when choices are determined at runtime?
Got it.
A test user profile needs to be created, and a few test properties like Property1, Property2, Property3, etc.
Then the admin RegularUser needs to be connected to the test user profile.
A test user profile needs to be created, and a few test properties like Property1, Property2, Property3, etc.
Then the admin RegularUser needs to be connected to the test user profile.
-
- Posts: 1463
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: Input Control doesn't work when choices are determined at runtime?
At first glance it looks like an issue with the layering of the Regular User.
You are setting up an input box independent of the RegularUser and then storing the details in the RegularUser BO.
AIM does not handle multiple depths particularly well, for example you can't use multiple nested forms within forms, you can only go to one level.
This may be a similar issue.
If you showed a form of the RegularUser then this would work, but you wouldn't be able to get that into a menu toolbar and have a menu toolbar showing.
You are setting up an input box independent of the RegularUser and then storing the details in the RegularUser BO.
AIM does not handle multiple depths particularly well, for example you can't use multiple nested forms within forms, you can only go to one level.
This may be a similar issue.
If you showed a form of the RegularUser then this would work, but you wouldn't be able to get that into a menu toolbar and have a menu toolbar showing.
Re: Input Control doesn't work when choices are determined at runtime?
PointsWell, thank you very much for looking at this.
I don't understand the layering issue.
From the point of view of the text attribute in RegularUser, it holds values, either predefined or that are filled using the query. In both cases the text attribute has choice values, e.g. the query works fine.
From the point of view of the Input Control, it points to that text attribute and uses whatever values it has stored, regardless or where they come from. So a normal non-expert user like me doesn't expect there to be a different behavior between the two scenarios. Yet there is.
What do you mean with "setting up an input box independent of the RegularUser"? The input control belongs to the visual perspective anyway, or is there another way of doing this that is more fail-safe?
andrei
I don't understand the layering issue.
From the point of view of the text attribute in RegularUser, it holds values, either predefined or that are filled using the query. In both cases the text attribute has choice values, e.g. the query works fine.
From the point of view of the Input Control, it points to that text attribute and uses whatever values it has stored, regardless or where they come from. So a normal non-expert user like me doesn't expect there to be a different behavior between the two scenarios. Yet there is.
What do you mean with "setting up an input box independent of the RegularUser"? The input control belongs to the visual perspective anyway, or is there another way of doing this that is more fail-safe?
andrei
-
- Posts: 1463
- Joined: Tue Jan 24, 2017 5:51 am
- Location: 'Stralya
Re: Input Control doesn't work when choices are determined at runtime?
There is a very slight semantic difference.
The input control is saving to the Regular User BO. It is not a representation of the Regular User.
So there is a degree of separation between the input control and the field it references. I am guessing that the distance means that that the dynamic lookup is "too far away" for it to work.
Vlad can confirm or correct.
The input control is saving to the Regular User BO. It is not a representation of the Regular User.
So there is a degree of separation between the input control and the field it references. I am guessing that the distance means that that the dynamic lookup is "too far away" for it to work.
Vlad can confirm or correct.