Dedicated place for user created requests, broadcasts etc.

[1984]

Problem: 

Currently the DQMH stock requests / broadcasts (eg: Stop module, Hide panel etc) are mixed with the user created requests / broadcasts so if one likes to check which requests, broadcasts etc are in the module he needs to open different subfolders and visually filter out the stock events. 

This is a readability issue which makes it significantly harder to quickly understand (or recall) what events are available for the given module.

Possible solution: 

Instead of mixing the stock DQMH events with the non-stock events create a virtual folder above all the virtual folders called "Module Specific" with subfolders like Requests, Broadcasts, Private and Controls and put everything the user create to there by default.

Big advantage of this of organizing the files this way would be that one could assume that whatever is module specific can be found in the these dedicated folders instead of spreaded somewhat randomly in the virtual folder structure of the module. I said somewhat randomly because the strucure as is currently is hard to read so developers try to make it more readable, everyone on his own way (eg: creating different folders, prefixing the user created events etc). So besides the increased readability of the module by applying this feature there is a very good chance that modules' structure will become more standardized across developers working at different companies.

[joerg.hampel]

I'm not against this suggestion, but I'd like to add that the "stock" events are completely equal to the user-created ones in that they are part of the API. For a potential user of any DQMH module, it's not important which events might have been created manually vs. which were part of the vanilla module...

[T.L.]

I guess, those stock events and requests are not completely equal: You can't rename or remove them using the DQMH tools.

I do create a virtual folder for stock requests (not for events) to see and find easily the capabilities of a module.

[1984]

Mixing stock and user created features is similar to somebody developing his code under <program files>/National Instrument/LabVIEW 2020

I guess nobody is doing that, because its benefitial to keep the 'framework' and the functions built on the framework separately.

-------

(A clarification to the original post: I used the word "event" as a interchangably with "requests" and "broadcasts" which is not correct technically. I didnt want to talk about events, but broadcasts / requests / controls etc)

[Olivier-JOURDAN]

Hi @1984,

Thanks for taking the time to share your thoughts here.

After internal discussions, we declined your idea mainly because we are not hearing complaints about the actual module organization.

As a side note, we can encourage you to test the Panther Dashboard for DQMH utility. It presents the DQMH module differently and could be a solution for you.

Again, thank you for your input; it is most appreciated. Please keep those ideas coming!