child class from Delacor_lib_QMH_Message Queue.lvclass can't access the queue

[T.L.]

Hi Fab and Community,

i just wanted to create a child class from Delacor_lib_QMH_Message Queue.lvclass to extend its functionality.
But when i try to access the queue, i get an error that the type definition for the queue element can’t be found. The Context help for the element shows the name for the typedef:
‘Delacor_lib_QMH_Message Queue.lvclass:Message–cluster.ctl’

But in the class i can only find this typedef:
‘Delacor_lib_QMH_Message Queue.lvclass:Delacor_lib_QMH_Message–cluster.ctl’

When inspecting e.g. “Delacor_lib_QMH_Flush Messages.vi” i can see the name
‘Message Queue.lvclass:Message–cluster.ctl’ for queue data type.

I wasn’t able to fix this by dropping the typedef into the accessor controls and classes private data element.

Can you fix that?

best regards
Thomas

[FabiolaDelaCueva]

Hi Thomas,

What version of the DQMH toolkit and DQMH palette are you using?

Thanks,

Fab

[FabiolaDelaCueva]

Hi Thomas,

Now that NI Week is over, I took a second look at your question.

I created a child class of the DQMH Queue and created an override for the Dequeue message VI. The code is rubbish but it shows how it does have access to the queue and the message contents.

I hope the image below helps.

Regards,

Fab

 

[T.L.]

Hi Fab,

i'm back from vacations now.

I use latest DQMH Version 4.0.

Here is a screenshot showing my problem:

I do also attach my project. Instead of overriding the deque method i added a new method to my class. But it behaves similar.

I hope you can find and solve type definition issue.

best regards,
Thomas

[FabiolaDelaCueva]

Hi Thomas,

I don't know what is going on, but the gif below shows how I solved it. I think it is one of those cases where we just need to tell LabVIEW: "LabVIEW, go home, you are drunk!"

1) Moved the DQMH library from Dependencies to My Computer

2) Open the Protected virtual folder

3) Open the Test.vi

4) Drag the cluster to the front panel of the Test.vi

5) Cut it

6) Paste it on top of the element indicator

7) Paste it on top of the element 2 indicator

Let us know if this solves or doesn't solve the issue.

Regards,

Fab

[T.L.]

Hi Fab,

thanks for the instruction. This works almost. Did you take a closer look on the block diagram?

There are finally 2 coercion dots at the indicators. The Vi is executable cause the types of dequeued element and indicator are comparable but they have different names:

Queue: "Delacor_lib_QMH_Message Queue.lvclass:Message--cluster.ctl"

Indicator: "Delacor_lib_QMH_Message Queue.lvclass:Delacor_lib_QMH_Message--cluster.ctl"

(inside accessor: "Message Queue.lvclass:Message--cluster.ctl")

I have seen this rarely when renaming lvclasses (inside  lvlibs?) with typed elements for queues and events.

Until now i haven't found a neat way to update changed names if this happens. Usually i have to go thru class cluster, accessors, creators, ... then update types, recreate controls and rewire to get lost the old name

best regards
Thomas

[FabiolaDelaCueva]

Thomas,

We will look into it. Does this work around works for you?

What is your concern about the coercion dot?

Regards,

Fab

[T.L.]

Hi Fab,

i can start my work with that work around.

My concern about that coercion dot? This one shouldn't be there...

best regards
Thomas

[FabiolaDelaCueva]

---

@T.L. wrote:

Hi Fab,

i can start my work with that work around.

My concern about that coercion dot? This one shouldn't be there...

best regards
Thomas

---

OK, we have created a case (DQMH-504) for us to figure out how to remove the coercion dot, but will not rush a new build for that. I wanted to make sure there was no urgent need to remove the coercion dot and that this workaround was acceptable to you.

We will try a couple of things and see what works. We will keep you posted.

Thanks again for your trust on DQMH and for bringing this issue to our attention.

Regards,

Fab

[FabiolaDelaCueva]

Hi Thomas,

We have done some extra research on this issue.  The ultimate cause of the coercion dots appears to be a bug in LabVIEW (which I think we all suspected from the beginning). One of the easiest ways we reproduced this was by going into a VI that is showing the pre-build typedef name on one of its subVI terminals. If we disconnect the terminal, then reconnect it, the typedef name changes to be correct.

We tried building the package with the project open and all of the contained VIs open. This did not fix the issue. Then we tried building the package with SourceOnly turned off on all VIs and classes in the project. No change. We tried building the package with LabVIEW 2018, in case there was a bug fix. No change. Finally, we tried building the package with the renaming set to only rename the three classes in the package. The class property nodes still exhibited the issue, although it looks like the subVI terminals may have been fixed.

We are making the decision to leave things as is. We understand the coercion dots should not be there but at the same time, this should not impact your code behavior. We will follow up with NI to see if there is a CAR already filed for this type of issue. If they do fix it, we will let you know.

Thanks for your understanding.

Regards,

Fab