Responsive Sizing for UI Objects not Fully Supported in Blocks Editor

The Designer properly supports responsive sizing by providing the user the ability to specify the UI object height and width percent.
The Blocks editor allows the user to specify height and width percent.
However, the Blocks editor does not provide the a way to retrieve./use those height and width percent values.
Being able to set the height and/or width percent of Object A to be equal (or some multiple) of Object B would be very beneficial to support responsive sizing.

Can this enhancement be provided in an upcoming Ai2 update?

Thanks

Hello,

Would you be able to use blocks like the following for your project?
blocks
This returns a decimal value analogous to a percentage. Testing this I found it to be pretty accurate, although not perfect. I set my label’s height to 10% in the designer, and it returned a value of 0.09793.

I hope that helps!
–Beka

1 Like

Hi Beka,

Your suggestion is definitely a good work-around in getting the job done.
It is definitely easier and more flexible than plugging in numeric values.

Naturally, my preference would be for the height and width percent to be available in Blocks (same as plain height and width attributes). There is no reason that an object attribute that is available in the Designer should not also be available in Blocks. IMHO

Thanks again for your suggestion, I will definitely use the technique.

Best regards
Ed

This method will cause issues if you have like a lot of labels and other components that need to be placed within the Screen.Initialize event. Cause the more blocks we have in Screen.Initialize the more time it will take to complete the process & load all components. So you will end up seeing a white screen till the process is completed.

Start a loading progress bar, end it when initialization is done

Even if I use a progress bar it will also be used within the Screen.Initialize event. How is it gonna reduce the Screen initialization time ? There will still be a white screen.

I agree.
Keep progress bar in Screen.Initialize (), move everything else into a procedure.

I don't understand that logic. Cause now the procedure will itself be a part of Screen.Initialize Event. And the number of actions that the event has to do remains the same.