Scott, how's version 2 coming along? Every time I fire up 1.0.1 it takes around five minutes before it's ready for use.
Yeah, I know - sucks, huh?
The horrible load-time is a stupid bug on my part, that I'm unable to fix as I don't have the source code anymore. Bloody annoying. So I've re-written about half of it so far (and fixed the stupid bug), but there are a few things getting in the way from finishing. First up is University. I pretty much have zero time to work on fun things like this, plus I'm hardly ever in Windows in the first place anymore! I haven't even tried out MC11 properly yet!! Second is the real show-stopper though... It seems making COM calls (to MJAutomation) from a multi-threaded .NET environment causes so much overhead in marshalling stuff around the place that the export itself takes about 10 times longer than it used to.
Basically I want to have the export taking place in a separate thread, allowing the GUI to remain responsive, as well as allowing other things to happen, like scheduled exports running in the background, or simultaneously.
In version 1, everything happened in a single thread. Each time round the main export loop the screen was repainted to make it look like things were happening. The main draw-back to this approach is that we can't cancel a currently running export, as the MouseDown event won't be received untill the export loop is finished. Bleh.
I don't really know the answer. You can either have exports that take an order of magnitude longer than they used to, with the ability to do cool new things, or you can have it how it's always been, but unable to cancel
Or someone can find the answer to this COM/.NET madness. I don't quite hate myself enough to delve into the depths of COM threading models, but here's what (I think) I know about the situation:
- COM objects (MC, MCXMLExport, etc) get put into Apartments
- There are two types of Apartments, Single Threaded (STA) and Multi Threaded (MTA)
- Objects in the same type of Apartment can communicate directly - objects in different types of apartment require an in-between object to marshal data back and forth
- MC creates my plugin inside an STA
- All's well until I spawn a new thread (the exporter thread), which, obviously, gets put in an MTA
- Calls coming from the export thread are in an MTA, and are targetting the MC object, which is in and STA
- Slowness ensues.
Any Windows programmers care to comment? I wouldn't have the foggiest idea. Surely this is a common thing?