Calling the plugin API from a thread in the plugin

[jemmyell]

Hi Les,

I am deep into my first control plugin for my VBA apps.

First, please look at scLoadJob, it always displays a dialog to pick a job, even if passed a valid path to a valid job.

Second, I need to make my API calls from a thread started in SheetCAM's context during the scInit call. This has gone well up to and including handing a function pointer to the thread through shared memory and then calling the plugin API. BUT I cannot get data to SheetCAM and I crash it, showing that my thread has a different data context. Would it be possible to allow me to set a data context based on the plugin ID? I see a chicken-and-egg problem here since the PluginID is data itself. Maybe you could capture my process ID and use that to set a data context (data segment) to be used for my threaded plugin calls?

If we can't resolve the process context for using true threads, maybe you could add an option to scInit where I could ask you to call an entry point 'scProcessingLoop' which I would implement as a loop with calls to SheetCam for all of my processing. This function would NOT be expected to return to SheetCAM until all of my processing is complete. I would trigger callbacks with named events and pass parameters through the system registry.

Third, scExit would be very useful now for formalizing my thread lifetime control.

I am attaching a plugin that attempts a scLoadJob through a function pointer inside of a thread context.

-James

[Les Newell]

Hi James,

First, please look at scLoadJob, it always displays a dialog to pick a job, even if passed a valid path to a valid job.

Works for me with both BCB and VC++ in a single threaded dll. It sounds
like you are passing a NULL pointer or one that points to an empty string.

Second, I need to make my API calls from a thread started in SheetCAM's context during the scInit call. This has gone well up to and including handing a function pointer to the thread through shared memory and then calling the plugin API. BUT I cannot get data to SheetCAM and I crash it, showing that my thread has a different data context.

This is not a data context problem. It is a thread synchronisation
problem. SheetCam is crashing because the UI is not MT safe. This should
not happen because I use a Borland function that is supposed to
synchronise the two threads. It looks like it is not working properly. I
am working on a mutex based solution.

Third, scExit would be very useful now for formalizing my thread lifetime control.

In the next release which will be out as soon as I nail down the thread
synchronisation.

I am attaching a plugin that attempts a scLoadJob through a function pointer inside of a thread context.

Thanks. It is very helpful. The filename is being passed correctly but
OpenGL is crashing big-time because of the MT issues.

Les

[jemmyell]

Hi Les,

Ok, all sounds good. I am glad that I can move forward with the MT approach, it solves quite a few issues for me with calls from the VBA side (I think, still at prototype stage).

BTW, I am basing my report on scLoadJob activating the 'pick file' dialog on a test done from scInit, since that's the only place I had not crashing from a threading problem. In order to show the job I wanted at initialization time, I removed all the paths from the sheetcam.ini. I did this since sheetcam was displaying the current job after loading my test job. With all the paths gone, this does not happen. Here is another test plugin that shows the 'pick job' dialog activating.

-James

[Les Newell]

Hi James,

I have your MT example successfully loading a job. Borland components
really don't like being accessed from an external thread, even if the
thread is synchronised with the main thread. I have ended up using a
rather untidy message based arrangement which should however be totally
safe, even if it is accessed by multiple threads simultaneously.

In order to show the job I wanted at initialization time, I removed all the paths from the sheetcam.ini. I did this since sheetcam was displaying the current job after loading my test job. With all the paths gone, this does not happen. Here is another test plugin that shows the 'pick job' dialog activating.

You probably have Options->reopen last job on startup selected. Your job
was loading then the last job was loaded over the top. I have changed
the plugin initialisation so it occurs after the last job is checked.
This will fix the problem. I am not sure why you are getting the pick
file dialog. It is working for me.

Next version due out in 1/2 hour or so...

Les

[jemmyell]

Hi Les,

I have my inital parameter passing all fixed from VB. There will never be any reason to call scLoadJob from scInit again. Did I get scExit in this version so I can finally close TaskManager again?

I am embarassed to note that I do have 'reopen last jon on startup' checked. So, since I took all path and job info out of sheetcam.ini it is prompting me...

Thanks for all the work, I will keep at it on my end.

-James

[jemmyell]

Hi Les,

All is well, I have loaded a .job file. I will work more this weekend. For the next step I hope we can document the job file format so I can create them from VBA. Also, I plan to launch SheetCam if it is not running already, so would it be possible to have a command line switch that will start it minimized?

Anyways, good work, this will keep me busy for a while!

-James

[Les Newell]

Hi James,

Did I get scExit in this version so I can finally close TaskManager again?

No.


You got scOnClose() instead

[Les Newell]

Hi James,

I'll see what I can do about the job file format. Hopefully most of it
should be fairly self-explanatory. Some of the process and tool values
have different uses depending on waht process or tool they refer to.
I'll dig out the information next week. I'll also add a command line
switch to the next version.

Have fun

Les