DQMH Better Practices

1. Model the different DQMH Modules to be created for the application and the events in between them before starting to code. This model can be a simple bubble diagram showing the events as arrows in between the bubbles or a more formal model like an UML Sequence diagram.
2. Avoid circular dependencies. If the modules are going to be built into different packages or are going to be used by themselves in other packages, do not have Module A calling Requests for Module B and Module B calling Requests for Module A. Instead consider using broadcast events for one of the two communication paths.

See also:

• https://dqmh.org/techniques-for-starting-your-dqmh-based-project/
• https://dqmh.org/tips-and-tricks-for-a-successful-dqmh-based-project/

Deciding who starts the modules is not a black and white decision. Here are some guidelines:

1. If a module main (A) makes calls to the public API of another DQMH module (B), then consider starting that other module (B) within the first module’s Main (A). If for whatever reason you don’t want to do that (for example, when considering lazy loading) then make sure you handle the errors when calling module B requests, as it may have not started yet.
2. If a module registers for the broadcasts from other modules, you need to be careful about calling “Obtain Request Events for Registration.vi”, because if the module is not already running, this VI just determines the broadcast datatype. You should consider creating a private request to register for the events if the module launches later.
   • You can create a Private DQMH Request Event as a regular DQMH Request Event and then move its API VI call to a virtual folder in your Module (configure the virtual folder with private access scope). This is to make it clear to you and others that this Request is intended to be used only within this module and it is not part of the public API as regular DQMH Request event would.

1. Do not call DQMH Request and wait for Reply events within the Message Handling Loop (MHL) of the Module’s Main.vi. If you do, the call will time out every time.
2. When creating a Request and Wait for Reply event, consider creating a broadcast that has the reply cluster as its argument. This will ensure that the DQMH Module API Tester, as well as any other VI registered to listen to broadcasts, can see the reply as well.
3. When a DQMH Module has DQMH Request and Wait for Reply Events, ensure that none of the MHL cases last longer than the timeout. For example, if a case has a one-button dialog pop up and a Request and Wait for Reply event is received while the dialog has not been acknowledged, the request will time out.
4. If the Request and Wait for Reply event is going to wait for a long time, make sure the code handling the request is registered to the stop module event and is able to abort the MHL case if the stop module event is received before the waiting period is over.

1. As new events are being created, keep the DQMH API Tester up to date, even if you do not think you will use it now. The tester can be used later as a sniffer, even if the DQMH module is a top-level module. If you follow this guideline, you will not need Desktop Execution Trace toolkit to debug your executable. Simply add your DQMH API Test.vi to your exe and use it as a debugging tool. Leave Desktop Execution Trace Toolkit for extreme cases.
2. When adding wrapper VIs that will become part of the Module’s public API and that call a series of Request and Wait for Reply (or any other Request events), make sure to add the wrapper VI to the DQMH API Tester. This will not be done automatically for you via the scripting tools, but it will help you identify problems like timing issues when calling different Requests back to back.
3. If a Request and Wait for Reply DQMH event can wait for a long time, modify the API Tester to have that Request and Wait for Reply in a helper loop within the API tester. Otherwise, the tester seems unresponsive and the developer loses the ability to stop the module, click to show the block diagram and the continuous update of the Status Updated events.

1. When coding a repetitive operation, use a helper loop that is registered to the stop Module event and does the repetitive operation inside the timeout case. Leave the changes to the local data cluster to be handled via the traditional EHL→MHL and then use a Private Request to update the data in the helper loop. This ensures that if the event structure in the helper loop has several events already in the queue, it contains the latest information the next time the timeout is handled.
2. Calling Status Updated.vi should be used over enqueuing Update Display message, even if done as a high priority message. Otherwise, the order of the status messages is not correct in the DQMH API Tester VI.
3. Atomic operations should be in a single MHL case. We cannot guarantee that other actions do not get enqueued in between MHL cases.