Expected Object Reference?

[RobBoyer]

Hello,

I am attempting to create my own version of modelsupport2.dll's parallel UUT dialog.  (It will use the TestStand Sync Manager to enqueue requests just like the existing Parallel model's parallel UUT dialog does.)  I am faced with a couple issues right off the bat that don't make a whole lot of sense to me.

For one thing, despite the fact that my dialog box (written in VB .NET by the way) is initialized in a sub-sequence of the TestUUTs execution entry point that is configured to run in a separate thread, the TestUUTs sequence still hangs around and waits for the dialog box to close before continuing on.  (This is clearly a problem since the whole point is to have the main thread continually process requests while the dialog box on a separate thread is busy enqueuing requests...)  Does anyone have any idea why that could be happening?  Maybe other sequence settings that I'm not aware of?

Another problem I'm having (although I wasn't initially having this problem) is the following error message: "Expected Object Reference, found Object Reference".  The error code shows "-17308; Specified value does not have the expected type".  This happens in the .NET action step in which I call my .NET assembly to create the object representing the dialog.  The object reference specified for the create object call is a parameter called CustomDialogRefParam - a parameter of type Object Reference.  The TestUUTs execution entry point has a CustomDialogRef local variable of the same type, and it passes it by reference to the Run UUT Info Dialog subsequence...  The idea was that the Run UUT Info Dialog subsequence would create the object, and from that point on, it would be available to the TestUUTs sequence.  Is there anything fundamentally wrong with this idea, or does anyone have any suggestions as to what may be causing this sort of error?

Thanks for any suggestions.  Let me know if I need to clarify anything.

[Patrick_P.]

Hey Rob,

I don't think there are really any settings you could have set that would force this to wait aside from putting an actual wait step to wait on the thread.  Are you sure that it is waiting before continuing on?  I created a very simple process model that does exactly what you are describing and mine does continue on.  I am creating the dialog in C# rather than VB, but they should be similar. One thing I would recommend is to use a notification to determine when the dialog has initialized as we do in the regular parallel process model.

On your second question, there isn't anything wrong with your logic.  Again I created a small example here that passed the object reference as a parameter and created it in the subsequence, and I was able to access it in my calling sequence (execution entry point) so long as the step that created the object had finished.  

If you want to post the process model you have so far as well as the source for your dialog, I would be more than happy to take a look at it.

[RobBoyer]

Hello,

Thanks for the feedback.  I actually fixed the problem with the thread not operating independently, (although I can't say I'm completely sure why I needed to do what I did).  The function call that starts the dialog is passed the sequence context from TestStand.  In order to allow TestStand to continue I had to set the sequence context's thread to the "externally suspended" state.  I can now get it to work in a very simple fashion.  (Basically, all it does is open up and wait for the user to click the exit button.  When that happens, the dialog uses the sync manager component to enqueue the appropriate requests to cause TestStand to stop all test sockets and exit the "process dialog requests" consumer loop.  Only problem I have now, is that for some reason, if I put a break point in the sequence after the dialog has been initialized, execution on the main thread stops as expected, but then attempting to step into, step over, or continue cause it to just hang.  (I can't even terminate the process - I have to actually close TestStand entirely.)  So long as I don't pause execution though, it runs flawlessly.

I'm still stuck on the passing of the .NET object reference though.  Oddly enough, it seems to work if I reference the object reference in a subsequence using the following syntax:

RunState.Caller.Locals.CustomDialogRef

But if I try to create an object reference parameter and pass the custom dialog ref by reference, it still fails with this strange "type mismatch"...  I still can't find any solution that works for accessing the object reference from sequences that are started on a separate execution...  Maybe I can store the reference in a station global...  I hate using globals though - it goes against my idea of good programming.

Anyway, thanks again, and any additional suggestions are certainly appreciated.