Delacor Toolkits Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Clever Move or Bad Move?

Hi,

 

I am just getting started with DQMH and I am wondering if this technique is a good move or if there are reasons to avoid it.

 

Lets say I have two modules, Module A and Module B. I create a Request event in Module B called "Call Module B Message Case" with the same arguments for enqueuing a message, a string for the message and a variant for the data. Module A can then use this single Public Request to execute any case in the MHL of Module B and change its state.


Thoughts?

 

 

0 Kudos
Message 1 of 8
(218 Views)

My question is: Why?

 

What are you trying to achieve?  What is your use case?

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
automatedenver.com
GCentral
0 Kudos
Message 2 of 8
(198 Views)

also try not to be a clever programmer, because the next guy who comes along is probably not as clever and won't have a clue what you were trying to do (and that next person could be you, several years from now.)

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
automatedenver.com
GCentral
Message 3 of 8
(195 Views)

In this case, Module A is a system controller module and Module B is a display module. The controller module contains the main user interface meaning that the controls/buttons reside there, while the display module is mostly reserved for indicators / graphs.

 

My thinking for creating the "Call Module B Message Case" request is: if I have a lot of interactions/requests that go down into the display module or need to extend it's functionality in the future, I have a generic request already created that I can use to facilitate. I would just need to create the new message case in the display module and could then call it from the controller with the generic request- rather than create a new unique DQMH request event.

 

Does that clarify the use case? You are right, clear programming is better than clever programming. To me it seemed harmless to do it this way but wasn't sure if there was a can of worms that I was opening somewhere.

0 Kudos
Message 4 of 8
(164 Views)

If I understand right what you're proposing, I don't think that's a good idea. You'd circumvent the strongly typed API - my favorite feature of DQMH.

 

Would you create typedefs for the manually created messages? If not, you end up with "external" functions that are not documented at all in the API. If yes, what's the benefit of not just creating a request?

 

Would you make Module A use the typedefs of Module B's messages? If yes, then you don't really gain a lot (and you still have static linking). If no, then you still need to know the data type, so Module A needs to know about Module B's internals (they're are still linked, even if not statically).

 

Maybe I got your idea all wrong, so please let me know your thoughts. 


An opportunity to learn from experienced developers / entrepreneurs (Fab and Steve amongst them):
DSH Pragmatic Software Development Workshop @ NIDays Europe in Munich on 22nd November
Message 5 of 8
(147 Views)

Ok, thank you for the clarity!

 

I figure that since I was asking the question in the first place, deep down I must have known that there was something smelly about this method. You've cleared it up nicely. The self documenting of the API with defined requests is preferred. A future developer could quickly understand the scope of the module's event structure. Thanks.

Message 6 of 8
(135 Views)
Highlighted

It's important to understand a framework's intended use before trying to improve it.  Although using weak instead of strong typing is a legitimate choice, that is not what DQMH is built for.  One could easily lose the advantages of strong typing without gaining the full benefits of weak typing.

Message 7 of 8
(107 Views)

Hi Ben,

 

Expanding on what everyone has already said:

The Queue in the DQMH module is private, the idea is for the Request VIs and registering for the Broadcast events to be the public API. The API Tester that pops up every time you add a new event is there to test and provide a map for future developers on how to use the public API for the DQMH module. 

 

Another advantage is that you know that if something makes it into the MHL, it was generated internally, if something arrives via the EHL then it comes from the outside. 

 

The generic message would open a back door into the module and remove that troubleshooting advantage.

 

Thanks for your trust in DQMH,

Fab



Get Going with G! at G Central GCentral
DQMH Lead Architect * DQMH Trusted Advisors DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?

0 Kudos
Message 8 of 8
(82 Views)