LVOOP DVR with non-blocking Dynamically-dispatched calls

[Intaris]

OK, obscure question time again.

I have a current architecture where I have several different self-displaying classes inheriting from a common parent class.  I have a dynamic dispatch method defined within the parent class which calls a UI specific for the class which enables me to present the user with the correct UI for edtiing the object properties depending on which object type is currenly being used in my software.  Each class may or may not have different methods for manipulating the data, it's not just the UI which changes, the method of editing the data changes also so a common UI is impossible.

I have a central repository of these objects (instantiated according to the Factory method).

What I would like to do is have a method to retrieve the current selected object (Class unknown but certainly an ancestor of the common parent), call the "show" function (Dynamic dispatch) which then opens up the specific UI for editing.  I can get this part working OK and have shown that the "By Ref" design is inherently working.  But....

I want the editing of the object parameters (Within the Dynamically dispatched VI) updates to run asynchronously with the repository.  I want to have the UI be able to run indefinitely but have the values cahnged be reflected in the repository, thus saving a huge amount of headaches in synchronising.

Class 1

Show()

Class 2 (Child of Class 1)

Show()

I want to store a DVR for Class 1 (Edit-time Class 1: Run-time: Class 1 or Class 2), retrieve the DVR, call the Show() method in an unblocking way (i.e. not simply calling Show() within an IPE) so that any changes made on the respective UI will be reflected imemdiately in the repository.

Any ideas?

This (Image below) is all I can come up with but I don't know if this is legit or not.  I would have to add some checking for a destroyed DVR int he editor to cover a change oy repository object type at run-time.

Shane

[Ben]

Hi Shane,

This a lame reply but it is an attempt to help out.

How about turning it inside out and put all of the editable stuff in a class held in the DVR and pass teh DVR ref to the dynamic dispatched code that will share the data of the class via the DVR.

WHen the edit stuff is not live, the class can get at its data with no competition. When the UI is active they only have to run into conflicts when they are both trying to manipulate the data and that is where I would want them to be serialized.

Ben

[Intaris]

Hi Ben,

Thanks for the not lame answer.  I'll think about it but here's my "solution" to the problem which I think might be suitable.

Attached is a small project highlighting what I'm getting at.  I've "Simulated" my repositors which is in reality a non-reentrant State machine very similar to the actor framework.

Shane.

Ps I should probably have the IPE structure visible above within a class member VI to maintain encapsulation.....

[Intaris]

Ben,

I think what I've shown above is essentially what you've suggested but I'm not sure.  Since the UI uses the DVR ONLY upon user interation (almost atomic operations ont he object data) there is no deadlocking.

Shane.

[Ben]

Yes sir!

Thank you for understanding what I meant and not what I wrote.

Ben

[Intaris]

Ben,

I will always take time to try to understand what you mean, guaranteed.  Either way, I think anyone who takes the time to try and understand MY posts (which can be severely rambling at times) deserves an award!

Shane.

PS Here's an updated version where each object signals its own changes via user events so that all editors (there may be many active at once, even with different UIs perhaps) stay current.

PPS the Clue is that I use the IPE to give me the ACTUAL object type without using the data within.  The DVR passed to the same function is my gateway to the class data, thus I can call the editor asynchronously and have parallel synchronised editors running.  This is cool, I think I'll be using this a lot.

[Intaris]

OK, I'm getting kind of happy with my results here (Technically, not aesthetically).

Here's a version where all Editing and Display routines are functions of the class.  No access to class data is done from without the class istelf except for setting event refnums (which can be placed within the class also) and a subpanel refnum (which HAS to be exposed).

I added a simple VI to display the private data of the class (Display, not output) in a given format so that we can monitor what's going on int he repository while we're editing.  I'm starting to like this approach very much.

Shane.

[Ben]

---

@Intaris wrote:

OK, I'm getting kind of happy with my results here (Technically, not aesthetically).

Here's a version where all Editing and Display routines are functions of the class.  No access to class data is done from without the class istelf except for setting event refnums (which can be placed within the class also) and a subpanel refnum (which HAS to be exposed).

I added a simple VI to display the private data of the class (Display, not output) in a given format so that we can monitor what's going on int he repository while we're editing.  I'm starting to like this approach very much.

Shane.

---

Well then in true LVOOP tradition, you should either;

1) Find an existing design pattern that describes what you are doing or

2) Make up a new name that is "copmetely correct but sufficiently nebulus" to ensure that nobody can figure out what it means.

Ben

[Intaris]

So do you know of such an existing pattern?

I vertainly don't.....  I'm sure there's one though.  I would have called them "Active objects" but that's already taken.  How about exhibitionist objects?  They like showing their dirty bits to the world.....

Shane

[Daklu]

---

@Intaris wrote:

Here's a version where all Editing and Display routines are functions of the class.  No access to class data is done from without the class istelf except for setting event refnums (which can be placed within the class also) and a subpanel refnum (which HAS to be exposed).

Shane.

---

Interesting stuff.  Every time I've looked at sub panels they ended up twisting my brain in knots.  Maybe it's time for me to revisit them.

I realize this is a example and you need to minimize the complexity, but I do have a couple minor comments:

• The parent Get DVR method is out of place and unnecessary.  I believe it actually hinders understanding the code.  I'd change the class properties to allow references and replace it with a Create DVR function.  Much easier to understand and it removes the risk of accidentally using the Get DVR class output terminal.
• The repository stores all the data and only gives other components references.  That's fine, but exposing the DVR itself to all the clients creates the risk that one of them might call Delete DVR and bring the whole system down, lock the DVR while performing extended calculations, or simply copy the object out of the DVR and not understand why the system isn't working correctly.  You might consider wrapping each data object (i.e. the parent and child classes) in a reference class and giving that class to the clients.