87 views
in Embedded Wizard Studio by
Hi,

PresentDialog() not working as expected with Embedded Wizard 11.0 but its working properly in 10.0. Any update has been done in latest release?

We are presenting a dialog of bounds of complete screen resolution i.e. 800*480 but left portion of the dialog is moved out of the display and pixels after that can be viewed in the display but its moved towards the left.

This we could observe in Prototyper itself if we open the same solution of 10.0 in 11.0

Best Regards,

Preethi S

1 Answer

0 votes
by

Hello Preethi,

in version 11 we have added following three improvements affecting dialog operations (see also Release Notes):

Whether these improvements are the cause of the observed issue, is difficult to estimate. Can you provide us an example project demonstrating the issue?

Best regards

Paul Banach

by
Hi Paul,

The issue is there for class which are derived from Class Menu of Components Templates. When we are trying to present those class derived from Menu using PresentDialog, then the position of the dialog is not proper. Anything we can do to resolve this.

Best Regards,

Preethi S
by

Hello Preethi,

I tried to reproduce your application case. By using version 10 I have created a small example containing a Menu component template and a class derived from it. In this example I present the menu by using PresentDialog(). Then I have tested this example with version 11. The behaviour was correct except the following situation:

In version 11 the method autoResize implemented in the Menu component template is invoked before all operations caused by PresentDialog() are executed. In the version 10 the order was opposite. This could lead to a problem in version 10 with GUI components which adapt their size dynamically at initialisation time. The Menu is such component. It adapts its size automatically according to the number of items included in it.

In version 10 the component updated the size after the PresentDialog() performed its operations. Thereupon PresentDialog() calculated with the original (still incorrect) size of the Menu component before the component was able to estimate its final size - before autoResize was executed.

To correct this issue we have modified the Mosaic in version 11 to additionally defer the operations resulting from PresentDialog():

The behaviour in version 11 is so far correct. Possibly, you have modified the Menu component to compensate the issue from version 10 and now the modification interferes with the corrected implementation in version 11? To answer this question it would be necessary to see an example project demonstrating this concrete issue in your application case. Can you provide use an example for review purpose?

Another idea: With version 11 we have also reworked the Menu and Menu Item component template. You could modify your project, remove the old Menu class and then add a new Menu from the new version 11:

Maybe it would be worth to update your Menu to the new template from version 11?

Best regards

Paul Banach

by

Hi Paul,

Thanks for your hints. We have different kinds of menu like one aligned in center and other menu with top alignment , so we have customized our autoResize() slot with different Bounds for each type of Menu, thats where the issue pops up. Now in OnComplete slot of PresentDialog() if i post the autoResize() i.e. postsignal autoResize is triggered from there, then this issue gets resolved

Is this the right way to do?

Thanks,

Preethi S

by
Hi Paul,

In addition to the above, we also removed the old Menu Class and added the new Menu Class from V11. Still the issue persists. Only way we could see here is posting the autoResize after the completion of PresentDialog() as we mentioned above.

Best Regards,

Preethi S
by

Hello Preethi,

Now in OnComplete slot of PresentDialog() if i post the autoResize() i.e. postsignal autoResize is triggered from there, then this issue gets resolved. Is this the right way to do?

Not really. Especially if you specify animations to perform during PresentDialog(), it will not work. From your latest description I have understood that you have modified the autoResize method to arrange the menu in a particular manner (to override the default positioning imposed by PresentDialog()). This seems to fail even with the new version of Menu templates.

Can you provide the implementation of such autoResize method for analysis purpose?

Per default dialogs are always centered. See also About positioning of Dialogs. As explained in the referred documentation, if you intend to arrange the menus (or generally any other dialog) in a particular way (e.g. top aligned), the best would be to prepare a transition object configured accordingly to align the dialogs in the desired manner. For example, if you want the menu to appear/disappear instantly (without fading animations), then:

Step 1: You create a new Show/Hide Transition object.

Step 2: Configure the object how to arrange the Dialog within its owner. In this way you specify alignment rules.

Step 3: Use the transition object when invoking PresentDialog() method. For this purpose you pass the transition object in the second parameter of PresentDialog() invocation (see also Perform Dialog transitions with animations):

PresentDialog( theMenuToPresent, YourUnit::TransitionObject, null, null, null,
                          null, null, null, null, false );

PresentDialog() uses the transition object to calculate the position for the menu to present. This is also true if you decide to present the menu with some animation. In such case you create the transition object by using the adequate template. See also Customize provided Dialog transition animations.

Best regards

Paul Banach

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...