www.si-community.com

Are there any C++ plugin experts here that could help me understand why my MD3 exporter code fails to capture the event associated with pressing the Cancel button in a progress bar? I check if the progress bar "isCancelled" but it does nothing...

I'm happy to share my code repo with anyone who can help... thanks.

I've written an exporter recently but not even sure if the cancel button worked. https://github.com/specularity/softimag ... ts/STL.cpp

might have to do with the application thread being blocked, I will check when I'm back at my desk

I tried to stop an STL export with the above plugin, which worked.

So probably nothing to do with threads being blocked, because there's no application calls in the for loop.

If you can share or pm the repo I'll have a look.

rray wrote: ↑16 Oct 2017, 19:22 I tried to stop an STL export with the above plugin, which worked.

So probably nothing to do with threads being blocked, because there's no application calls in the for loop.

If you can share or pm the repo I'll have a look.

Yes, the Cancel button does work to cancel my export-- the crash happens if the user then modifies export settings and attempts to re-export. It behaves like it picks up where it left off when first cancelled... then crashes. When I tried to debug it with breakpoints-- pressing "Cancel" never triggered a breakpoint.

One thing I noticed that can possibly cause crashes.. I would try to stay away from global variables inside DLLs because it depends a lot on the environment where the dll is loaded/how often it us loaded/unloaded whether you get the same instance of your variables. It's quite hard to predict especially because I think XSI uses a cache for plugin dlls. Will look around some more later about the progress bar issues when I get a chance.

@rray - did you get the MD3 exporter to crash after attempting a re-export following a" Cancel" ?

3 canceled exports, no crashes - didn't notice any issues with the progress bar either (always resets to 0 position for a new export).

I tried to let the 4th export run though - this runs into an endless loop (I set the range to 0-20, the exporter exports 0-100 and then exports 0-100 again and again)

I canceled it in the 3rd "round" - that made XSI crash then.

Hmm... After you press Cancel-- it does cancel the export, but then go and change frame range and/or settings and press export again. It will restart the export-- BUT seems to pick-up where the first cancelled export ended... and then crashes SI shortly thereafter. My attempts to use a logical:

if (pBar.IsCancelPressed){...}

never gets triggered.

I just noticed the SDK example discussing class ProgressBar puts the IsCancelPressed() in a while loop. My code does not... I simply have checks for it using if statements at key points during the export, but shouldn't my checks still get triggered?