Hi Pierre, I'm not aware of any deliberate change in behaviour. This sounds like a bug in Nuke 10 to me, possibly as an inadvertent side-effect of another change. I would agree with Bruno that in this situation, Nuke should know that an abort has occurred, regardless of the value returned by the plug-in. If Nuke continues to process after it has been aborted, something else will go wrong very soon.
Could you - or someone else from the discussion group - send this issue in to our Support team, please? This is the best way to ensure it is tracked properly and that time can be allocated for a developer to look into when and why this behaviour changed. There is an online Support portal now for logging issues: https://supportportal.thefoundry.co.uk/hc/en-us Many thanks, Lucy On Thu, Dec 15, 2016 at 7:19 PM, Pierre Jasmin <jas...@revisionfx.com> wrote: > > Genarts reports a change in Nuke with regards to abort() - i.e. Interrupt > during interaction (ofx-discuss...@googlegroups.com - I pasted the > message at bottom of this email) > > 1) Is this true? From what version exactly down to dot dot? > > 2) Wouldn't there be a way to inform developers when you do that? > > 3) What error message is fine for you? > > Historical Note: Initially I wanted to add a Cancel Error Message for > this but Bruno said host knows it requested aborted. It took from Nuke 4.7 > to 7 to iron out abort() bugs in Nuke. > > Thanks for paying attention, > > Pierre > > > " > > Hi all- > > We just discovered an interesting interaction between Sapphire and Nuke > that seems worthy of discussion... (and we're a little surprised this > hasn't come up before...) > > During render Sapphire calls OfxImageEffectSuiteV1->abort() to check if > the user/host wants to cancel the render. Historically Sapphire has > returned kOfxStatOK if the render is aborted, as in "the host requested we > abort, and we have done so without error". But we just found in a customer > project that returning OK can cause Nuke 10 to crash -- most likely because > they think Sapphire successfully finished rendering *despite* the abort. > While the spec for abort() is vague regarding the plugin return code, the > documentation for kOfxImageEffectActionRender seems pretty clear that > kOfxStatOK is *not* the right answer: "Return Values: kOfxStatOK, the > effect rendered happily." > > So going forward, Sapphire will return kOfxStatFailed following an abort > -- this eliminates the Nuke 10 crash and seems more correct based on the > current spec. Would this change in behavior cause problems for any > existing hosts? > > While we were looking at it though we thought maybe a kOfxStatAborted > status would be helpful in this situation, i.e. "the host requested an > abort and the plugin has done so, not to be confused with plugin > encountering an internal error". Would the distinction between > kOfxStatFailed and kOfxStatAborted be useful to host developers? > > Thanks! > > Stephen > > " > > _______________________________________________ > Nuke-dev mailing list > Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > > -- Lucy Wilkes Lead Software Engineer - Nuke Engine The Foundry 5 Golden Square, London, W1F 9HT Tel: +44 (0)20 7479 4350 Web: www.thefoundry.co.uk Email: l...@thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027
_______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
