MartinMcD Posted January 7, 2011 Report Share Posted January 7, 2011 Hello there everyone, I fear this is a newbie-to-oop question but if you can spare me a minute it would be much appreciated. Is it okay/good/bad to use a single-element-queue to contain an instance of a class object? And to use this to allow two bits of my application to set&get various class properties. I have a daqSettings class which lists currently used channels. I have a separate front panel (part of a windowManager class) which allows the user to change channel settings. This window needs to initialise itself with the current channel settings and then set the updated settings for the daq class to use. Thank you for any advice you can spare. Regards, Martin Quote Link to comment
Black Pearl Posted January 7, 2011 Report Share Posted January 7, 2011 Be aware of deadlocks. The IPE structure should be a way to protect you against this (as required when using DVRs). Why not use DVRs if available? Felix Quote Link to comment
MartinMcD Posted January 7, 2011 Author Report Share Posted January 7, 2011 Hi Felix, Thank you for the response. I'm not sure what IPE and DVR stand for, please could you fill me in. Thanks, Martin I think I should be reading this: http://lavag.org/topic/10666-labview-oop-by-ref/page__st__40 In Place Element structure and Data Value Reference. I'm off & away, thanks for the tip. Quote Link to comment
Norm Kirchner Posted January 7, 2011 Report Share Posted January 7, 2011 One of the best reasons to use them within a DVR is to take advantage of the new ability to create your own property node calls off of an object. Another terrific reason to use them is that if you choose this design choice, you can take advantage of some awesome design that has been developed to aid in the management and extensibility of them http://decibel.ni.co.../docs/DOC-12813 This tool gives you the ability to have Named DVR's and also adds extensibility to the first obtain and the last release. The naming of a DVR is a major reason some people would stay with SEQ (Single Element Q), but with the ESF, that is no longer a limitation for DVR's Add on top of that the ability to have 'first obtain' and 'Last Release' code seamlessly integrated into the flow w/ no additional wires needed...... you can't go wrong I look forward to seeing your thoughts on the ESF - Extensible Session Framework Norm Kirchner ~,~ The Captain was Here PS if you need a good idea of a 'Hello world' style example with it, make a basic timer. Quote Link to comment
Daklu Posted January 7, 2011 Report Share Posted January 7, 2011 Is it okay/good/bad to use a single-element-queue to contain an instance of a class object? As a programming practice I don't think there's anything wrong with it. The DVR and the SEQ are essentially equivalent. As Felix said, the DVR is usually favored over the SEQ, but there are advantages to the SEQ. For example, when you lock a DVR using the IPE, the nature of the IPE requires the DVR to be unlocked before exiting that vi. With a SEQ you can lock (dequeue) access, do whatever you want (including exiting the vi,) and unlock (enqueue) access when you're ready. There are ways to work around this by implementing lock/unlock methods in the class that uses the DVR, but it is easier to create arbitrary locking/unlocking scenarios with a SEQ than with a DVR. Which one you decide to use should depend more on the structure of your application than a desire for source code purity. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.