[texworks] SCRIPTING: TW.deleteLate()

[Paul A Norman]

Thanks Stefan,

Feeling my way a bit with this.
Appreciate any suggestions, warnings, about what I am doing here.... running
through it for long term understanding ... naively was not expecting to hit
these issues with just Scripting.

function myFunction()
{
var showMoreDialogue = TW.createUI(scriptPath + "showMore.ui");

    dah dah dah -- Prep the dialogue


var   userAction = showMoreDialogue.exec();


  dah dah dah


 TW.deleteLater(showMoreDialogue);


  }


If a later call, in the same Script session, to myFunction() tries to do the
following again,


var showMoreDialogue = TW.createUI(scriptPath + "showMore.ui");


Debugger says,


Uncaught exception at
G:/latexportable/LaTexUtils/TeXWorks/texworks/config/scripts/Image
Handling/convertImage.js:304: Error: cannot access member `createUI' of
deleted QObject

304 var showMoreDialogue = TW.createUI(scriptPath + "showMore.ui");


So recognising that the Main dialogue emits a signal ".finished"


function UIconnectVarious(connectAction)

        {

         // connectAction =  "connect" | "disconnect"


         blah blah



        eval("convertImage.finished." + connectAction +
"(dialog_finished)");

        }


function dialog_finished(resp)

 {

 // resp is code issued by dialogue  at finishing 0 | 1  I think


 // function is used for saving settings, and ...


UIconnectVarious("disconnect");


// delete various dialogue objects

  TW.deleteLater(showMoreDialogue);

TW.deleteLater(confirmInfo);

TW.deleteLater(preview);


  // Keep main dialogue  Last

TW.deleteLater(convertImage);


}


And I declare all potentially used dialogues globally,
else  TW.deleteLater() may be called on something that does not exist.


var convertImage, showMoreDialogue, confirmInfo, preview; // dialogue Script
Objects for later deletion (and re-use)

Does  TW.deleteLater() worry  :) if  it is dealing with is a script variable
that never actually got made into a dialogue (depending upon User's
choices)?


I don't get debugger messages ... but then it may be to far up the chain to
get a Script debugger message?


Am I ok with this or should I test for className on objects ( more involved
-- Script folding back to using QObject .toString()  ) and if
they don't have one, then not deleteLater() them?


Or is no debugger message sufficient - no worries mate? (that's Aussie talk)


This will be no surprise to you, but I was pleasantly surprised that using
global variable names for the dialogues, meant that exec() called on them
any where after creation and closing, would re-present the dialogue in the
same state as last used.


Which gives another (more preferable?) option which I am running with at
present:--


Create all dialogues in script initialisation and immediately call
.setVisible(false) (  and no exec() at that time obviously )  then just
.exec() them when/as needed?



And destroy them all on main dialogue . finished()


I was avoiding this to keep memory usage down ( (re-)creating them on demand
),  but doing this seems stable and ok, and so far no memory issues at all.

Only seems to use 0.01 Gb pagefile for all four dialogues which is more than
ok.


Only draw back is a little screen flicker as the main.first dialogue opens
and the other three open and hide.


Any problems with this last approach at all? - it seems the tidiest.


Just another question, I get the sense the way the debugger was responding
that a created dialogue is potentially still around perhaps even after a
Script closes?

If so are they available to Script later? Or does Script finalisation end
their lives?


Paul


On 19 June 2011 20:19, Stefan Löffler <st.loeffler at gmail.com> wrote:

> Hi,
>
> On 2011-06-18 09:00, Paul A Norman wrote:
> > Should TW.deleteLater() be callled on Dialogues once they are
> > completely finished?
>
> The short answer is: yes.
>
> > i.e.
> >
> >    var convertImage =    TW.createUI("blah.blah/xxx.ui);
> >
> >    var ans = convertImage.exec();
> >
> >     TW.deleteLater(convertImage) ;
> >
> >
> > I have had some memory issues that seem to have been solved by this.
> > Is that the right way to handle this?
>
> The longer answer is a little more complicated. Everything that
> "creates" a pointer (in sloppy C++ terms) allocates memory for that.
> This remains allocated until the pointer is "destroyed" again. This can
> happen automatically by a number of mechanisms, but not for these
> dialogs. In particular, the dialog is not tied to a particular
> invocation of a script (i.e., it's not destroyed automatically when the
> script ends) to allow reusing it (and possibly its data).
> Ultimately, it all comes down to what is often referred to as
> "ownership": the owner is responsible for destroying a pointer, whereas
> everyone else has to be aware that their copy of the pointer may be
> invalidated at any time.
> For the sake of completeness: if you specify a parent (e.g.,
> TW.createUI("file.ui", TW.target)), then the dialog will be destroyed
> when TW.target is destroyed (if it still exists by then). Usually, this
> won't help you much, though, as the script creating the dialog could be
> called hundreds of times before TW.target is destroyed.
>
> > Anything else that TW.deleteLater()  should be used for at all please?
>
> Basically, anything that creates a pointer for the script and returns it
> is a good candidate for deleteLater(). So from quickly browsing through
> TWScriptAPI.h/.cpp, progressDialog will need a deleteLater() as well.
>
> HTH
> Stefan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texworks/attachments/20110620/5db7ccc2/attachment-0001.html>