Event names created with , (comma) in the name results in non functional code

[heel]

1. Create an event with a comma in the name - like "Set (X,Y)",
2. The message string sent to MHL will also be "Set (X,Y)"
3. In the MHL this string will be expanded to  "Set (X", "Y)" , i.e. two strings as far as case structure concerns.
4. The message "Set (X,Y)" will thus never be handled but generates an error in the default MHL case.
5. The DQMH module verifier catches this error.
6. It is posible to manually overrride the incorrectly expanded MHL label to: "Set (X,Y)" and the module works, but DQMH still reports "Unrecognized message strings detected"

Suggestion:

• DQMH tool should either disallow names with comma during creation.
• or patch-up the message string to a value compatible with a case label
• or...

DQMH version is the latest as of today.

[FabiolaDelaCueva · Accepted solution]

Hi Heel,

Thanks for reporting this issue to us. We have filed DQMH-659 in our internal system and we will look into this.

Thanks for your trust in DQMH,

Fab

[Ozfarmboy]

If you recall Fab, I had a similar issue when I used "(" in the name of a module last year.

I like Heel's suggestion that "DQMH tool should either disallow names with comma during creation" - and expand this to apply to any other illegal characters. 

That would be the easiest than trying to convert the illegal characters afterwards.

[heel]

while touching this part of the code - also disallow creation of events with names from the list:

• Default
• Tool generated standard events like: Exit, Start, Error, Initialize
• User's already defined events.
• And if very nitty gritty: also names  from MHL's readabilty infrastructure like: "--- Exit and Error Handling---"

It does take a bit of work and tool familiarity to properly clean up after accidentally creating events like above. For instance you may have created a VI on file with this name which need to be manually removed. So, a guard against such mistakes has some relevance.

thanks for a great tool

[heel]

As often is the case, things are  more complex than what meets the eye.

If user has previously renamed an event, the original name is still used in the MHL labels. Therefore to properly deal with case DQMH-659 and the derived suggestions of limiting the choice of event names, I think one should either

1. fix the event rename to also rename the  case label to reflect the new name and not keep the old name. Also to avoid confusion.
2. compare new event names against existing MHL case labels to avoid collision

I would think that 1.) would be the better option.

[Darren]

I think (2) is the better option, as (1) will cause existing code to malfunction if there are places in the Main VI that enqueue the old MHL frame name other than its associated request in the EHL.