Access the ProcessModelClient FileGlobals from the Process Model?

[Jed_Davidow]

How can I access the FileGlobals int he client from the process model?

[Jed_Davidow]

Eventually found this: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000000YH6dCAG&l=en-US

Apparently to edit the runtime ProcessModelClient from the ProcessModel you need to use the activeX API.

EDIT:  This example may be wrong.  It passes the argument runState.SequenceFile to the API Call (sequenceFileParam in the module parameters), but that will reference the file you are running from.  If you are running from the process model, I think you need to use RunState.Root.RunState.ProcessModelClient to access your sequence.

I also had to store the Object Reference returned in the Get FileGlobals() call to a new local, and passed that to subsequence API calls to modify it.  You can't pass the object reference out to "FileGlobals", this makes no sense.

[Oli_Wachno]

---

@Jed_Davidow wrote:

How can I access the FileGlobals int he client from the process model?

---

But that means, you are directly coupling your ProcessModel to your sequence file.... i that a good idea?

[Jed_Davidow]

---

@Oli_Wachno wrote:

---

---

But that means, you are directly coupling your ProcessModel to your sequence file.... i that a good idea?

---

Basically what I am doing is generating a path that is used throughout our code, in both the Client and in shared sub-sequences called by the Client.  This is a universal path for all our tests, conforming to a design/engineering decision.

All our tests use this process model (or it's equivalent parallel version).

So now this path is calculated in the processModel and pushed into the clients automatically; and it's available in a convenient location (Client FileGlobals, rather than Engine.TemporaryGlobals or something like that).  I am running it in ProcessSetup, so it can be over-written.

I suppose I could override ProcessSetup with a shared sequence utility too; but if I am going to require it in every sequence we run, why not embed it in our custom process model?

[Oli_Wachno]

I am avoiding cyclic dependencies whereever I can....  that's why I am asking

The issue I am seeing with your approach is "pushing" the data to the client sequence...

Since you are modifying the ProcessModel anyway, why don't you save that path as a local in your entry point(s)? Thus it would be accessible in any client sequence file via RunState.Root.Locals like the socket information.

[Jed_Davidow]

---

@Oli_Wachno wrote:

Since you are modifying the ProcessModel anyway, why don't you save that path as a local in your entry point(s)? Thus it would be accessible in any client sequence file via RunState.Root.Locals like the socket information.

That is actually a fantastic idea.