[Closed] Thread Synchronisation

Are you sure you have to do it that way? I would assume that this is highly unstable, even if you get it to work correctly, and as far as I know there is no option in MXS to prevent another app to edit external files or check if a file is edited by another app.
There might be a different way to do it (if we had more information on what you need to be done).

Actually this is everything that needs to be done: One application creates a couple of values, let’s say integer values. And theese values need to be passed to 3D Studio Max every second. So another way would be to let this application pass values directly via a String stream that is located somewhere in the operating system. But actually that’s even more complicated than having a file that works as a link between those two apps. It would be great if no file was needed and if I could write those values directly in an array in Max Script, but, I guess this isn’t possible at all.

So you need these values in Real-Time while the script is running? What are these values? Can you maybe leave out the external app and create the values directly within MXS?

Realtime would be the top of the iceberg . I’d be glad if they could be read within one second.
As I said the values are simple integers (at the moment). And unfortunately I can’t create theese values in Max script. (Yes I could create a file with another Max-script containing random values, but this would make no sense). Because the other application reads the values from a temperature-sensor. So I’m forced to work with it. As I said it would be cool if I could access this sensor via Max script, but I don’t think that’s possible.

What I would do is this:

When Max reads the file, it also stores the last modified date of the file. Then at its next attempt to access the file, it would check if the date has changed and if it has not, it would wait and try again some milliseconds later.

Or you could create a LOCK file with your VB application while the data is being written and delete it once it is done. MAXScript would check if the file is there and only read the data if it is not there. MAXScript could also write its own LOCK file while reading and the VB app would wait for it to disappear before writing its data.

Or you could pass the data via DotNet…

Thanks Bobo,

the LOCK-file sounds like a good method to start with. I also like the idea of the check-variable. Right now I’ve included a statement like: if the file is eof right after opening then the clock timer “waits” a couple of milliseconds and tries again later. I’m a little bit confused, cause there’s only this “wait” statement in Max Script which holds on the whole system. Is there something else that let’s you still work in Max while waiting?
Anyways Dot-Net is an idea but it would take me weeks or even months to learn all the new commands, so I’d like to stick to MXS.

Thanks

• “ko’gen”

A file-free option could be to use COM. Create a simple OLE/COM server in MaxScript, then connect to it in your VBScript and send the values in every N seconds. The MXS side can stuff the values into a global array or something, for your script to use when needed.

I haven’t tested this, but something along these lines:

In MaxScript:

fn passVBValues value1 value2 = (
   global vbVals = #(value1, value2)
)
registerOLEInterface #(passVBValues)

Then in VBScript:

MXSObj = WScript.CreateObject("MAX.Application")
MXSObj.passVBValues(value1, value2)

If you needed the MaxScript to do the timer part, you could reverse the above, with the VBScript creating the server for MXS to connect to, using createOLEObject instead.

Wow, I’m excited how many interesting solutions there are. I thought there might be only one answer: “No”.
Thanks for the hint vScourge I didn’t know, MXS is able to work with such kind of “individual files” like excell. There was only one problem, when I read the user reference.

The server application that was attached with createOLEObject() is released and terminated when the created MAXScript OLE object is eventually garbage-collected. You can explicitly disconnect from an OLE server application with the releaseOLEObject() function.

and this:

OLE Automation[left]After calling this function, all existing OLE objects become disabled and any attempt to use them further will generate a runtime error.

[/left]
[left]

[/left]
[left]This seems to me that you can only access the application once and after that you’ll get the runtime error?

[/left]

The first item just means when your OLE object falls out of scope and is garbage collected by Max, that OLE interface can no longer be used until you create it again. This is no different than any other variable you define that gets cleaned up later. If you find this happening in your tool you can just make that object global.

All the second item means is when you call registerOLEInterface <array of functions>, it clears out any prior interfaces you’ve made in that Max session. If you’ve never created or used any others, it doesn’t matter.