Hello,
I am facing the same issue. In my use case, the popup lives on a separate route in Angular, so it is already defined with [visible]="true"
.
I hope this issue is addressed, all the tickets related to this are 2 years old.
Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.
Hi Alex,
The behavior remains the same. The best approach is to use the workarounds we previously described. If you’ve already tried them and they didn’t work in your scenario, we’d be happy to explore alternative solutions. In that case, could you share a small sample project that reproduces the issue? This would help us better understand the specifics of your setup and investigate further.
Hi Artem,
I think that simplest and cleanest workaround that I found, was hooking into
onShown
and changing the content after the popup was done with the animation.The reason why I opened this issue is just to highlight the importance of this bug getting solved.
Thank you for your input, Alex.
The main issue is that the ResizeObserver (used in Popup) triggers resizing right when the animation appears. In our initial solution, we attempted to delay the resizing logic to avoid interrupting animations. However, the overall results were worse than the current behavior. Thus, we opted for a custom solution at that time and postponed the task until we decided to implement new animation logic. This might require improving the size tracking logic as well.
Anyway, I understand that additional coding in this case looks excessive. I have logged your request and shared it with our team. If we decide to reconsider the current animation implementation, we will add a corresponding item to our Roadmap and update related tickets.
Let me know if you have additional questions.
Hi Artem,
Thank you for giving me an insight into this issue.
You're welcome, Alex.
Should you have further questions, feel free to contact us.