Input Control doesn't work when choices are determined at runtime?

andreic

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

PointsWell

Can you create a BSV please, it's not possible to diagnose from this info. Thanks

andreic

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:

Properties static - no issues.PNG

Properties dynamic - query works.PNG

Input controls on VP - properties static works as expected.PNG

seems I can upload only 3 images, so one more to come..

andreic

Input controls on VP - properties dynamic doesnt work.PNG

PointsWell

andreic wrote
No problem, but it tells me Error Invalid file extension: Test_20220524_2204_InputCtrl.bsv
So I can attach only pictures?

Add .zip to the end of the file name e.g. test.BSV.zip

andreic

Got it.

Test_20220524_2204_InputCtrl.bsv.zip

46.49kB

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.

PointsWell

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.

andreic

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

PointsWell

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.