I use the Show Diagram debugging request on DQMH modules all the time. But sometimes it's not quite enough, like if there is a bug in my module *initialization*. By the time I fire the Show Diagram request, there is no way for me to debug the initialization problem. And when I say "initialization", I'm not only referring to the Initialize message in the MHL, but also all the code on the left side of the diagram that executes before we even get to the EHL and MHL.
I propose the following:
1. Add a new data member to the Module Admin class: "Show Diagram on Init"
2. Add a new input to Start Module.vi that sets this flag on the Module Admin class that is passed to the Main VI. Default is FALSE.
3. In the Main VI, if this flag is true, then Init Module.vi will show the diagram of the main VI on initialization AND turn on Retain Wire Values.
With these changes, the block diagram of the Main VI will appear immediately on init, and we can probe any wires on the diagram that executed during initialization to see their values.
It would be nice if there were a validate+fixer for this, but given that it is a debugging feature (as opposed to a change in framework behavior), I'm fine if there is no validate+fixer.
Including DQMH modules into our application framework, we need to script the creation of new modules / requests and so on.
However, current scripting GUIs do not have any controls connected to the connector pane.
Also, even if we could pass some values to these interfaces, we would even need to control if we want to show their HMI or control the creation / cancellation of a scripting action whitout having to press on the OK / Cancel button.
Allowing to programmatically control the DQMH scripting VIs would be great !!
I would like a right-click plugin where I could right-click a DQMH broadcast subVI and "Find Event Frames". This would search all VIs in my current project for event structures that are registered for the broadcast event fired by the subVI I clicked on, and show me a list of results that I could double-click and be shown the event frames one at a time. Or I guess it could just open all the diagrams for me, since I probably want to walk through all of them anyway.
The operation could take a while, but would be worth it. I often find myself wondering where all the places are in my code that are registered for a particular broadcast.
"Sometimes, the error cluster that feeds into the Delacor QMH Error Handler - Message Handling Loop.vi doesn't convey enough information to identify the origin of the error. For example, an Error "91 - Variant To Data in xyz.lvlib:Main.vi" does not tell me in which MHL case the variant to data operation failed. It would be nice to have the selector label of the MHL's case that the error occurred in."
Feature Request: Somehow (not sure what the best way would be) make the error handler include the last message's name (string) in the error broadcast."
It's not completely related to the framework itself, but I'd like to have a tool to generate an "error VI" (like Module Not Running--error.vi) with custom error code not already use in the project or selected among the existing ones.
If we could also have an API that list error codes and text, I would like it 🙂
When creating new module, I'd like a way to add a text explaining its responsibility. It will reinforce good conception practices and allow Antidoc to retrieve information to generate a valuable documentation.
Note: IMO, this content should be added to the module lvlib description.
If this field could optionally mandatory to create the module, I would find this great 🙂
When I need one of the reply payload values of a Request and Wait for Reply VI, I need to unbundle 100% of the time. What if the Request and Wait for Reply VI output the reply payload elements individually on the VI conpane so I don't need to unbundle? I often make this change manually to my Request and Wait for Reply VIs. And I never unbundle the error from the payload, since it's already merged into the error stream inside the VI. So I wouldn't expect that output to be on the conpane. But all the other payload parameters, you betcha!
Just a very, very simple proposal for consistency, as per what the title says: when a "Panel close?" event is triggered in "External Launch" mode, the module should probably broadcast a "Panel hidden." Status updated. Like this:
Do you agree or is there any reason I'm missing for which the broadcast was not placed there?
When you add a new Request and wait for reply event, the scripting tool adds automatically, in the Modules consumer, the handler case. In this case, there is also added the bundle for the Reply message and the Wait for reply? case structure.
Personally, i move every time the bundle inside the Wait for reply? case structure to have a cleaner area.
The scripting tool can add this automatically for a cleaner view and maybe an optimized code. There is no need to create a bundle, if you do not use it forward.
I sometimes create Cloneable modules that I intend on usually calling as singletons. For these modules, I often manually update each request to have its Module ID input recommended (instead of required) and the Module ID default value of 0 (instead of -1). I also make the 'call as singleton' input on Start Module.vi have a default value of TRUE (instead of FALSE).
I'd like for there to be an option when creating a new cloneable module that says something like "optimize for calling as singleton" that would create the default requests as described above, and would also be tagged in some way so when I add new requests they will be created as described above.
Instead of selecting each item to be updated then click update. It would be nice to have an update all or be able to select multiple items to be updated.. Especially when going to a newer version (like 4.x to 5.0)
When using the Request and Wait for Reply pattern, the time-out happens locally (with a usually hard-coded default-value).
The module receiving the message has no idea of the time-out on the client side (timeout meaning: When did I send the message to the module?, When do I not care about an answer anymore?).
I suggest incorporating such info (i.e. "Timeout End Timestamp") into the request message automatically, so that the module can do sanity checks before processing the request (i.e. "Time-out occured already, so I'm not executing the request at all, since the caller doesn't care anymore").
Furthermore, I think it is helpful, if you can choose during creation of a "Request and Wait for Reply" event with the wizard, if the time-out should be exposed or the default constant should be used, bringing this decision to the attention of the developer.
A time delayed message in my opinion would be an useful edition to DQMH.
I understand that helper loops can be used to do timing with event structure timeouts. This becomes problematic when you need arbitrary number of timing instances at runtime. I agree resource intensive timing should be in helper loops but you may want to set up a heartbeat or check a certain signal periodically.
I did this in my application by creating a child of the messaging class and extending the class with AF style timing. But it would be nice to have this naively in the messaging library.