InterruptedException is not processed by Aspose.Slides for Java

Aspose.Slides Product Family
1

Hi,

In some cases I have complex PowerPoint files that take a lot of time to process (hours).

In order to stop the processing when it takes too much time I tried to use the same mechanism available in Aspose.Words for Java, Aspose.Words for .NET and Aspose.Slides for .NET - interrupting the thread.

While this works for Word documents, for PowerPoint it doesn’t work. I’m using Aspose.Slides 17.6, is this fixed in upper versions?

Thank you!

2

@DaeMoohn,

I have observed your requirements and like to share that Interruptible library support has been included in latest Aspose.Slides for .NET 18.4. I suggest you to please visit this documentation link for your convenience.

1 Like
4

Is it available for Java also?

5

@DaeMoohn,

Yes, it is available for Aspose.Slides for Java as well. Please visit this documentation link for your convenience.

1 Like
6

Can this control the saving of the document also? In the example it is attached only on the loading options, but there seems to be no control on the saving part.

7

@DaeMoohn,

I like to share that interruptible options is set using presentation LoadOptions and they control presentation for all operations including rendering and saving presentations. I hope the shared information will be helpful.

8

@mudassir.fayyaz,

I played with Aspose Words, Cells and Slides for Java, regarding interrupting processing.

There is

  • thread.interrupt for Words

  • InterruptionTokenSource for Slides

  • InterruptMonitor for Cells

Why does a common set of libraries, built by the same company, offer totally different APIs for the same facility? You don’t even have same common packages. Can you fix this in the future somehow?

Thank you.

9

@DaeMoohn,

I like to share that these all three APIs are of different nature and with different architectures, objects and attributes etc. So using a common set of APIs might not be possible. Moreover, conversion or parsing of objects b/w these APIs are not completely possible either. On the basis of these differences, we may not consider these APIs to use singular approach. I hope the shared elaboration will be helpful and we have comprehensive documentation available for all three APIs exposing the available features.