Scripting API

[joerg.hampel]

Wouldn't it be great if we could hook into the scripting process of DQHM and, for example, add our own automation steps to the creation of new modules or new events? Something like the "post-build VI" feature of the application builder...

[FabiolaDelaCueva]

We are curious to learn how would you and others want to extend the scripting utilities. 

Don't forget to add this feature request at: http://forums.ni.com/t5/Delacor-Toolkits-Documents/DQMH-Feature-Requests/ta-p/3537845 and include a link to this post. People can vote there for the feature request and keep the discussion going here.

Regards,

Fab

[joerg.hampel]

We're starting to extend the structure within the DQMH modules in a way that - I guess - could be scripted, too.

For example, we're changing / extending the Message Queue Class to also send the notifier refnum for request events with response. It would be nice to put the VI that we created and that takes care of baking the notifier refnum into the variant that's then sent in between the bundle function and the Enqueue Message.vi. Automatically.

Other, similar thoughts have crossed our minds recently...

[mRadziwon]

I indeed like the idea.  However It will require some standardisation as it would be the greatest tool if it will work not only with current DQMH version, but also foth at least several future ones. I mean sth like rather rigid definition of what can be modified. I know it may be a hard one. 

On the other hand QDMH was designed to be LabVIEW rookie friendly - and it is.  Such 'post scripting' callback could allow to transform DQHM towards object oriented solution which will ease some implementations and potentially allow some degree of inheritance. 

[Evan]

I have also thought about using an API to extend the code.

An example is I like to take the code from the Message Handling Loops cases and create a subVI for each new event, so the DQMH block diagram stays small and all the code is easy to find.  I end up naming those "Message Handler.vi".  So rather than re-doing the step every time, I could add that script.

As a side note: a solution that was offered to me is to write my own post process tool and simply insert that into the LV menus, so when I want it done, boom it can be selected.  I have not actually done it yet, but that is a nice work around for a Post Process style call.

[FabiolaDelaCueva]

---

Evan wrote:

As a side note: a solution that was offered to me is to write my own post process tool and simply insert that into the LV menus, so when I want it done, boom it can be selected.  I have not actually done it yet, but that is a nice work around for a Post Process style call.

---

Another option would be to create a custom right click menu (see: ni.com/lvmenus )

[FabiolaDelaCueva]

---

@Mike_CCM wrote:

I indeed like the idea.  However It will require some standardisation as it would be the greatest tool if it will work not only with current DQMH version, but also foth at least several future ones. I mean sth like rather rigid definition of what can be modified. I know it may be a hard one. 

---

If we were to do this, we would make sure it would be compatible. Have you used the "Validate DQMH Module" tool? When we release a new version of DQMH, if we made changes, we create a validate tool that can retrofit your existing DQMH modules to have the new features. 

---

@Mike_CCM wrote:

On the other hand QDMH was designed to be LabVIEW rookie friendly - and it is.  Such 'post scripting' callback could allow to transform DQHM towards object oriented solution which will ease some implementations and potentially allow some degree of inheritance. 

---

What type of conversion towards LVOOP were you thinking of? Have you tried the DQMH Module Templates?  The example in the documentation has the local data cluster being an object instead. As long as all the items that make a DQMH module be recognized as a DQMH module, the scripting tools will work. 

The list of what makes a DQMH module be recognized as a DQMH module is found at the bottom of this page in the documentation.

[joerg.hampel]

Seeing as we have the proper Feature Requests section for DQMH now, please go there and vote for this feature:

https://forums.ni.com/t5/DQMH-Feature-Requests/Scripting-API/idi-p/4092135