[texworks] SCRIPTING: TW.deleteLate()

[Paul A Norman]

Thanks  Stefan,

Just confirming for complete clarity ...

So    TW..deleteLater(showMoreDialogue);

Must be ... ?

 showMoreDialogue.deleteLater();

Your .odt notes to me late last year (now in Scripting Api) noted to leave
TW.deleteLater() alone (
http://twscript.paulanorman.com/docs/html/files/deleteLater.html ), I
got confused when trying to work out how to get rid of dialogues.

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

For me, afaik, no problem with signals ever so far ever since UI became
available in Scripting.
Especially using the Qt supplied connection  model style in last email:

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

I haven't tried the other way.

> and doesn't cover some cases, where dialogs would be created on-the-fly
based on user input

Ok, created and deleted locally in creating function then?

Or when needed to be used in other functions once created, could
just declare the var global say as a string = "I'm not a dialogue yet", not
know whether the User initialised it or not as a dialogue, and at
finalisation test the global var's .toString().indexOf() for either
the dialogue QDialog className or "I'm not a dialogue yet", if appropriate
 then run .deleteLater() on it during Script finalisation?

Otherwise if being used in more than one function once the User has made it,
you'd never know whether and when to deletLater() on it or not.  Could also
test for initialisation on "I'm not a dialogue yet" in any function that
wants to use it calling a function to do that test which can then create it
if necessary?

Note: I think a created  scriptDialogueName.toString() call should give a
string including the className of QDialog, and the name= of the object.

>  e.g., dialogs could be kept in TW.globals for later use.

Had tried that when Script UI first came out, and thought it didn't work
(might have to retry and make sure I got it right). Really like the idea!

Thanks,

Paul



Paul

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

> **
> 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/20110621/bb33034e/attachment-0001.html>