Memory leak in confirmation dialog

Here's some replacement code for the interim. Just change the Ui. to My eg

//class SaveDelegate extends Ui.ConfirmationDelegate {
class SaveDelegate extends MyConfirmationDelegate {

//Ui.pushView(new Ui.Confirmation("Save result?"), new SaveDelegate(), Ui.SLIDE_IMMEDIATE);
Ui.pushView(new MyConfirmation("Save result?"), new SaveDelegate(), Ui.SLIDE_IMMEDIATE);




using Toybox.WatchUi as Ui;
using Toybox.Graphics as Gfx;


const CX = 105;
const CY = 110;
const XY = 53;
const CANCEL = "Cancel";
const CONFIRM = "Confirm";


class MyConfirmationDelegate extends Ui.InputDelegate {


function onKey(event) {
var key = event.getKey();


if(Ui.KEY_ENTER == key) {
enterEvent();
}
else if(Ui.KEY_ESC == key) {
escEvent();
}
return true;
}


function onTap(event)
{
var coords = event.getCoordinates();
var x = coords[0];
var y = coords[1];
if(y > CY - 15 && y < CY + 15) {
if(x > CX - XY - 40 && x < CX - XY + 40) {
escEvent();
}
else if(x > CX + XY - 40 && x < CX + XY + 40) {
enterEvent();
}
}
}


function enterEvent()
{
onResponse(true);
popView(SLIDE_IMMEDIATE);
}


function escEvent()
{
onResponse(false);
popView(SLIDE_IMMEDIATE);
}
}


class MyConfirmation extends Ui.View {


hidden var mMsgText;


//! Load your resources here
function onLayout(dc) {
onUpdate(dc);
}


function initialize(msgText) {
mMsgText = msgText;
}


//! Restore the state of the app and prepare the view to be shown
function onShow() {
}


function onUpdate(dc) {


var font = Gfx.FONT_MEDIUM;
var just = Gfx.TEXT_JUSTIFY_CENTER|Gfx.TEXT_JUSTIFY_VCENTER;


dc.setColor( Gfx.COLOR_TRANSPARENT, Gfx.COLOR_BLACK );
dc.clear();
dc.setColor( Gfx.COLOR_WHITE, Gfx.COLOR_TRANSPARENT );
dc.drawText( CX, CY - XY, font, mMsgText, just);
dc.drawText( CX - XY, CY, font, CANCEL, just);
dc.drawText( CX + XY, CY, font, CONFIRM, just);
}
}

Yeah, implementing a confirmation dialog is a reasonable workaround. Unfortunately my application is bumping up against the memory limits, so adding new code is problematic. Of course leaking memory is worse... :)

Thanks for the report. We'll look into this.

I think this problem is the same as in this thread. That that behavior occurs after a key has been written. The Confirmation Dialog in itself will work fine most of the time.

You've already linked to the related thread, but I thought I'd mention here as well that the issue has been addressed and the fix was included in the 1.1.1 SDK release.

Was the confirmation dialog memory leak meant to be fixed in 1.1.1 ?

It was, but I don't believe the fix actually went out until this latest 1.1.2 release. Apologies for the misinformation.