[texworks] SCRIPTING: TW.deleteLate()

[Stefan Löffler]

Hi,

On 2011-06-20 08:17, Paul A Norman wrote:
> 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.

Exclamations of warnings below ;).
Well, scripting is powerful - even more so in combination with C++, but
of course there are also hidden dangers...

> TW.deleteLater(showMoreDialogue);

This deletes the TW object! The deleteLater() method is invoked from its
own object and doesn't take any arguments (thought ECMA is quite lenient
when it comes to the question of the number and types of arguments, so
it apparently doesn't complain here).

>
> }
>
>
> 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");
>

It says here "cannot access member [...] of deleted QObject" - this
means that you can't call member functions of the TW object anymore
because that has been destroyed (though, normally, this should be
impossible, *unless* of course you're mixing event loops - which can be
a side effect of nesting dialogs; technicallities @
http://doc.trolltech.com/4.7/qobject.html#deleteLater). So you've
effectively nuked your connection to Tw ;).

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

Just a word of caution: as discussed before, connecting to signals is
not guaranteed to be stable ATM.

> 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?
>

I can't tell off-hand. One thing that is sure is that it's safe to call
deleteLater() multiple times. Note that deleteLater() implies that the
object is not deleted immediately, but is scheduled for deletion when
the control returns to the event loop. Normally, this is when the script
ends (then, control returns to the main event loop), but dialogs can
have their own event loops (so they can run modally), and in that case
things might be more difficult.
The more difficult question is what happens if a variable is "declared",
but is not a QObject. So, e.g., what happens if you say
    var a = "test";
    a.deleteLater();
I'd naively think that this causes an error, but depending on the
implementation it might not (e.g., if all types are implicitly derived
of or castable to QObject).

Generally, though, I'm inclined to think that if there are no
errors/messages, the implementation probably handles everything behind
the scenes silently correctly.

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

Yeah, I'd go with "no worries mate" ;).

> 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.
>

It's certainly tidy, but requires a lot of book-keeping (and doesn't
cover some cases, where dialogs would be created on-the-fly based on
user input). Plus, there is the flickering.

So, all in all, I guess the first solution is the more general solution,
but then again this is probably just a matter of taste.

> 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?
>

Yes, maybe, and no (actually, these were 3 questions ;)); as I tried to
point out in my previous mail, dialogs are not tied to the script, and
it is the responsibility of the script that creates it to ensure that
they get deleted properly. That said, this doesn't necessarily happen
during the lifetime of the script. You must make sure you keep a
reference to it, though, as the variables to use the dialog don't
survive; e.g., dialogs could be kept in TW.globals for later use.

HTH
Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/texworks/attachments/20110620/e62b1b88/attachment.html>