08-11-2022 09:36 PM
Hi
Is there a better way in dealing (or splitting) with the ever increasing height of the DQMH_Reg_Events in my main application...
I'm afraid by the time I finish development it will be double or triple as high...
TIA
Solved! Go to Solution.
08-11-2022 09:41 PM
My first thought, make a cluster of the individual events and register that one cluster.
08-11-2022 09:41 PM
Nest things. Create a heirarchy of modules.
I don't know your particular design or the problem you are solving but I am willing to bet that your main module does not need to communicate directly with that many submodules.
08-11-2022 09:43 PM
@Dhakkan wrote:
My first thought, make a cluster of the individual events and register that one cluster.
That would probably work, but seems like bandaid.
Add more layers to the heirarchy and delegate responsibility.
08-11-2022 09:52 PM
Totally agreed, Sam.
08-11-2022 10:09 PM
I do have nested architecture on top of the amount of modules I already need to communicate with (unfortunately), basically the height as it is now is the bare minimum, I think the band-aid solution will work for my immediate concerns thanks for the suggestions though I appreciate it!
08-11-2022 10:11 PM
This makes sense Sam, but what about if you want to pass all your errors/status broadcasts up to the top?
In the past, we've tried having to pass an error from a module up a layer, only to then have that module turn around and pass that same message up a further layer. This is creating more work than is necessary.
Having said that, I think the error might need to be handled by the immediate module above, but the developer might want to pass all errors all the way up to display or log them all in one place for instance.
08-11-2022 10:22 PM
@Ozfarmboy wrote:
This makes sense Sam, but what about if you want to pass all your errors/status broadcasts up to the top?
In the past, we've tried having to pass an error from a module up a layer, only to then have that module turn around and pass that same message up a further layer. This is creating more work than is necessary.
Having said that, I think the error might need to be handled by the immediate module above, but the developer might want to pass all errors all the way up to display or log them all in one place for instance.
I just let errors bubble up to the appropriate level and get handled there. Sometimes that means bubbling all the way up to Main. Sometimes it can be handled at a lower layer.
I generally let status broadcasts bubble all the way up for debugging.
I've never had an issue. Although I could see if you had enough DQMH modules, that might create problems and performance bottleknecks. You could always cross that bridge when you get there and just aggregate them or condense them or do some filtering or something similar.
08-11-2022 10:44 PM
The other thing BCousins is to be mindful of having too many dqmh modules.
I think everyone has a different view on this, but at WiS we've found that constraining the number of modules is a good thing. We don't have a hard limit. We just don't turn every single function into a module.
08-12-2022 02:18 AM
@Ozfarmboy wrote:
The other thing BCousins is to be mindful of having too many dqmh modules.
I think everyone has a different view on this, but at WiS we've found that constraining the number of modules is a good thing. We don't have a hard limit. We just don't turn every single function into a module.
Noooo...
Ok, and now with less dogma 🙂 I find it interesting to read this. In my experience, I've never thought "if only I had not created this module", whereas I've found myself a number of times trying to be clever by avoiding a module, only to end up recreating most of the framework functions and eventually creating a module after all.
The nature of your application (or rather your system) will already dictate a certain number of modules which represent the physical world. On top of that, modelling the application will show how certain functions should operate independently or be built to be reusable. A DQMH module is a quite natural way to cater to this. This is also what I communicate to our customers in trainings or consulting engagements.
I'd really like to hear some more tangible reasoning so I can reflect on my position on this. Chris can you share more about how many modules made your life harder? How do others think about this?
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® (The Future of Team-Based LabVIEW Development)