Cascades Development

[Zmey]

Yes, but when the sheet is closed it will not be destroyed. Can you please suggest how to destroy it in QML?

[AlexXF]

In current release problem is - Sheet destroyed after close (in Application Menu object).

[ekke]

---

Zmey wrote:

Yes, but when the sheet is closed it will not be destroyed. Can you please suggest how to destroy it in QML?

---

recently learned this ;-)

x.destroy()

from QML did it

[AlexXF]

Can you post QML sample code + signal processing for new sheet created?

[jasoncheung]

Thank goodness I found this thread.

I thought I was going insane wondering why my application would act on weird after closing the sheet that I opened from the Applicaiton menu......

sigh.

[Jack00513]

tks!

[jasoncheung]

I don't think calling .destroy() in QML is valid for a sheet.

It compiles and runs and all, but I don't think it actually does anything.  I ran my app through a profiler, and the memory keeps on piling up with the sheets....

We better not be punished for this since this is an OS bug, as we are creating a workaround to make sheets work with the Application Menu....

[peter9477]

An alternative workaround is to have the Menu trigger a singleShot QTimer with a delay of 350ms or more (probably 500ms to be safe), and have the onTimeout of the QTimer do the actual sheet.open() call.

It appears the issue may be related to having the Menu onscreen at the time the sheet arrives... maybe a conflict in animations? Anyway, the delay seems to be long enough to prevent that, and you can repeatedly open/close the same Sheet if you do this.

Of course, this only helps those who want to do this approach in the very short term, since there's a new release coming which apparently fixes this.

[HorizonXP]

Just want to chime in to say that I appear to have fallen victim to this bug, but from a different approach.

In my app, I have a Sheet that instantiate in QML via createObject(). I have a signal that gets sent up to my Python code to validate the input on the Sheet, which fires a signal back to the sheet telling it what inputs are valid or not. The sheet then pops up a SystemToast alerting the user to the problem.

After closing and reopening the sheet, the signal gets sent once but results in 2 SystemToasts. If I close it and reopen again, I get 3 of them.

Modifying my code to destroy the object causes my code to crash when I call sheet.close(). I could rearchitect to work around this, but my code to insert data also depends on this. It would result in multiple rows being added. Furthermore, I'd really like to keep this architecture as it results in more modular code. 

[peter9477]

Are you explicitly connecting something in the dynamic objects to a signal/slot elsewhere, as in signalName.connect(functionInDynamicObject)?

If so, you might need an explicit disconnect() too. Otherwise it might be something about the way you're getting those signals into the Sheets in the first place... is something still being left around after the sheet is closed, resulting in the closed-but-not-destroyed one participating in the same interactions somehow?