12-09-2023 03:12 AM
First impressions are great. The new create event is a lot more sophisticated than what with had in DQMH 6.
Private requests, scripted helper loops, better file organization all checked! The custom broadcast payload practically allows us to convert a Request and Wait for Reply event to a Roundtrip. DQMH was already an invaluable help coding our projects but the new version certainly makes it even better! Congrats all the developers contributed to this release.
Some minor findings:
The Convert DQMH event dialog throws an error if you select a module which has no events to convert but you press OK. Doesnt seem to crash anything but the OK button might not be enabled if the event pulldown is empty.
Having a bigger initial block diagram on the module main is great. Is it possible / reasonable to also increase the API test block diagram?
There seems to be a big empty free label on the FP of the module mains. Is there a reason for that?
The subdiagram label in the MHL loop is unreasonably big even if it doesnt even have any text inside. Is it possible to "size to text?" (this might not be releated to DQMH 7, maybe was like that in v6)
12-18-2023 07:24 AM
Renaming a private request removes the cool new "private" icon from the VI's icon.
12-18-2023 09:23 AM
All of the issues mentioned in this thread are currently covered by Issue #909 reported to the DQMH Consortium. Thanks for the feedback.
01-07-2024 04:34 AM
Hello 1984, a quick update:
FIXED items will be published with the next release of DQMH.
DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
HSE Discord Server (Discuss our free and commercial tools and services)
DQMH® (Developer Experience that makes you smile )
01-08-2024 07:42 AM
Hi,
Today I have noticed that something odd is going on with the dependencies of my project. After couple hours of scratching my head I have found that probably these two items causing the problem:
I'm positive that these get into the dependency list if you validate a DQMH module written in an earlier version and fix the error about the semaphores. This makes these two items showing up in the dependency list and as a side result the "Obtain module Semaphore.vi" of the module is not called by anybody anymore.
I dont know whats going on in the background and I dont know if this is a but but it definitely gave me a headache, cause I thought I did something wrong.
01-08-2024 10:26 AM
@1984, if you could DM me a simple project that reproduces the issue, or alternatively give me exact steps to reproduce the issue, I can submit a Bug report to the DQMH Consortium to investigate further.
01-08-2024 11:02 AM
I'll be off the grid for this week so can't do it anytime soon, but just take a module written in DQMH6.0 (could be simply the stock singleton module), validate and fix the listed issues under DQMH7.0
That - for me - added that dependency to the project. Let me know if you could / couldn't reproduce the issue. If not I'll get back to this once I'm back.
01-08-2024 11:06 AM
Thanks @1984. I've filed Issue #912 to the DQMH Consortium on the 'stub' VIs in Dependencies issue. If you end up being able to share more details about the issue, please post them here.
01-11-2024 03:28 AM
I add a new panel module based 7.0.0.128, but it doesn't work well. During debugging I found that it fail to sync modules.
01-11-2024 11:09 AM
@lbc898 wrote:
I add a new panel module based 7.0.0.128, but it doesn't work well. During debugging I found that it fail to sync modules.
There are some known issues with the Panel Manager (which was written with DQMH 3.1) and the latest DQMH Validation tools. These issues are being tracked by the DQMH Consortium as Issue #901.