shoneill

Indeed, not wiring the instance can have some awkward side-effects.  LaunchingLVCompare.exe from a SVN client for example will try to open it in the CURRENT context.  Running LVCompare on an FPGA target is not something I've yet managed to get working.....

I thought of something like Teamviewer before but I'm not sure if there's any way to query the mouse pointers individually from software or not (as opposed to the OS handling two different pointers transparently).

I don't think this will work.

I think Windows automatically sets all mice connected to control the same cursor.  I am unaware of a way (Aside from programming USB directly) to get the information from eachindividually into LabVIEW.  But hey, maybe (in fact, almost certainly) someone knows more than me.

I really don't think serendipity is the correct term for what we are talking about.  We're talking about people looking to learn, not stumbling across something by accident.

Regarding the situation with information communicated under NDA or anything similar I think the vast majority of us are clear about this.  Unless you happen to also be under NDA (which I am) you legally should not be a recipient of the information.  End of.  I don't think a discussion on this level is worth the effort.  The legal aspect is relatively clear.  There are at least two videos of the CLA 2015 meeting which probably fall into this category.

The easiest point to address is the idea that non-CLAs will somehow not be capable of properly understanding the messages to be communicated by such videos.  On a purely technical note, I don't think the level of the presentations is such that non-CLAs would have a hard a time identifying, following and understanding the true idea behind them at all.

Full disclosure: I detest elitism.  The argument from authority does not sit well with me.  It makes one side angry and the other side blind.  If the CLAs wish to pursue this route than I see dark times ahead for the community.  If anything the group should probably be more transparent than any other, setting the example for others to follow.  Information has no ego.

With many internationally reknowned universities offering much of their courses online for free, the approach to sharing knowledge seems to be changing.  It's now quite possible to watch a 17-video series on how the physiology of the brain affects our every day experinces and how these developments were evolved and what consequences they have for psychiatric disorders.  For free.  Do these universities worry if the people watching them can understand the information? No, they don't.  Why should we?

"I prefer that the CLA presentations not be generally posted."

AQ, you mean publically posted or posted in general (i.e. posted to a limited group vs posted at all)?

Speaking for myself (speaking for others tends to get me into trouble) I very much enjoy the CLA videos even though I'm not even CLAD any more....

Tell me about it.

I spent a few weeks last year testing different things on the 3D picture.  I have previously (in college and for no other reason than pure curiosity) read books on 3D graphics (Open GL).  Pretty high-level stuff, no function calls.

Reading up on the current state of Open GL (I was in college when Open GL was the only 3D kid on the block!  Yeah, that statement really carbon dates me!) I notice there are many many OpenGL features missing from the current LV implementation (like multipass rendering, full texturing support and so on)

I can't recall the property right now but I think it has to do with with the "blending bin" you place the text objects in.  There's Opaque, Transparent and so on.  Make sure you set the text objects to the correct blending bin and it should work.

Looks like this release includes the "Profile Buffer Allocations" tool

I can't find anything about this in the release notes..... am I blind?

Never mind, it's in the readme.txt but not in the release notes.....

Generics are maybe an solution to drjdpowell's request, but as for mine the compiler just needs to be a little smarter to guess what type of object is in my cluster. In this case it's just compile-time type determination.

Generics are also a compile time determination.  This is why the suggestion is basically asking for generics.  This "little smarter" is pretty much what generics have to offer.

This is in contrast to LVOOP which has an unknown type (but known ancestry) at compilation.  Variants (or at least their contents) are also unknown at compile time.

I sure hope not.  Have you used XNodes?  They have all the functionality of generics and a ton more.  Heck I'm sure the original question could be solved with a simple XNode.  I want type adaption that is better than polymorphics.  But I also want custom help, icons, growable nodes, custom right click menus, and edit time scripting. 

I've yet to dabble in XNodes.  While I share your desire for these advanced features, I don't want NI doing another quick hack whose negative side-effects we'll be fighting against until the end of time.  Xcontrols anyone?  That's a great example of a cool idea just implemented wrongly because they looked at the problem with far too narrow a view. (This is simply my personal opinion on XControls)

At least for the type adaption  part of your request, that's exactly what generics should solve.  The others are different topics.  AFAIK, Xnodes will never be made public and I'm sure NI has their reasons for that.

I made the request for it to work for Variants, which would include the cluster support CharlesB wants, and also support mixed clusters of objects and primitive types.

Well, reading that thread I have to re-quote AQ

Thus I see this as a poor stop-gap for generics, and not a sufficient stop gap to be able to get new features any time sooner

 

That's exactly what went through my head when reading this post on LAVA.  I'm also a bit confused about generics being a thing for the far future versus his claim in this thread about it being do-able..... Surely it's one or the other or has something fundamentally changed since then?  This is the part I am most confused over.  Could it be that generics are soon to enter the LabVIEW world?

In 8 years, that's the first time I've heard the cluster/array request. It comes in sometimes for DVRs and for VI Server class refnum types, but infrequently enough that NI has never acted on it.

To be clear: it is doable, there just hasn't been pressure to do it.

Eh?

This seems like a weird construct to me.  I'm not sure what to think of this.  Makes me think of a limited set of generic datatypes.

Holler.

I downloaded from the link you provided and my LV wouldn't open it because it said it was from a newer version.....

Hrm.  Code is saved in a newer version than I currently have access to.  I'm assuming it's LV 2014, but I only have 2012 installed....  Looks like I need to power up a VM.

That won't be happening today, but I WILL look at it when I have time.  Thanks.

I'll give this a try this evening.  Are there any logs generated during install which might help track down any problems which occur?

Not having another PC to test on, I really can't say if it's specific to my PC or not...

I tried uninstalling and re-installing, it still does not show up in the tools menu.

No answers?  Bummer.

This package isn't working for me.  It doesn't show up int he Tools menu after installation and even opening the lvproj in the vi.lib folder doesn't find components it needs because it's expecting items to be in a subdirectory when they have actually been renamed.

I'm using LV 2012 SP1 (32-bit) on Win7 Pro 64-bit.

As an example, it's looking for a Class

C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\LAVA\LabVIEW Task Manager\Test VIs_LVTM\Test Class\Test Class.lvclass

but I can only find

C:\Program Files (x86)\National Instruments\LabVIEW 2012\vi.lib\LAVA\LabVIEW Task Manager\Test Class__LAVA_lib_LVTM.lvclass

I have VIPM 2014 installed.....

User Events.

Create and register for the events int he top-level VI and pass them to the parallel processes.  Then you can also scale up to 3,4 or a thousand objects and they can inter-comminucate.

No LVOOP required for this aspect.

I've looked at them and it seems really to be some bug or at least undocumented behaviour.

The FP of one VI seems to return an offset of 1pproximately 120 pixels in the vertical.  The Panel method "CvtPaneltoScreenCoordinates" suffers from the same problem (but might be an easier method to get what you want as it automatically takes into account the title bar and so on).

Ah, I found something interesting:

Click on the bottom right corner of the FP with scrollbars visible and choose Properties.  When you exit you will see that the selection box for the panel is way off.  Could it be that the origin of the pane was changed programatically and some internal state got messed up?

Here's the picture

Any routine I write to insert something into a sub-panel first checks the state of the FP and if it is in an incompatible state, I change it to "hidden" before inserting.  I also remember to remember the state so that when removing it I can reinstate the old setting.

I generally have a few sub-VIs to do this work for me.

Ps I don't close the FP because that can lead to really problematic situations where (AF aside) the VI is actually exited upon setting the FP to being closed.

I have (in the past) also taken a reference (Open VI Reference) of the VI first, set the FP to close and then inserted it.  Explicitly opening a reference to the VI (in the case it has been passed as a parameter instead of opening it within the sub-panel calling VI) prevents the VI from being stopped.

@AlexA,

no, there is no static link between the VI "hosting" the UI and the UI itself, that's the point.  The VI with the subpanel (not part of any of the classes but needing to display their UI) passes the subpanel on to the object and asks it to embed itself there (which it would then do).

How the rest is done depends a lot on your requirements.  If the call to the UI is blocking, then it can all be handled within the single VI which also embeds the FP in the subpanel with the entered values simply contained within the object returned from the VI call.  This really is the super simplest approach.  The VI to place the UI int he subpanel does so and waits for the stop button to be pressed after which it retrieves the current parameter set and updates the object accordingly.  You have a single VI call with an object input and output (along with a subpanel input) and the new values are simply part of the output object.

If you need an asynchronous approach, then your UI will most likely need to expose a user event where each changed set of object parameters gets sent back to the host until the UI is closed.  But again all communications are done on the API of the parent since we no longer have any need (for this functionality at least) to know which child we0re currently working with.  It's enough that the child knows what kind of object it is and acts accordingly).

The "Host" VI only ever sees a parent object since this is the interface we've programmed to.  There's absolutely no knowledge of how the UI looks except for the fact that at some stage it's embedded in the subpanel.  Each object has it's own UI handler.  There is no showing or hiding of controls, no dynamic parsing.  Each object operates in its own world and the UI can be appropriately designed and encapsulated for that specific object's requirements.

Shane.

PS The TCP part is a red herring, it makes no difference whatsoever.  How would you send the parameters anyway?  That's a problem for your object model but is not affected by the UI aspect at all.

This dilemma has at least 3 resolutions that are correct:

• Use dynamic typing rather that static typing for input/output arguments. JSON is a good choice in 2014 that provides both strong typing and dynamic typing (as opposed to weak typing and static typing). XML is your second choice. INI is a suboptimal choice. Your Own Clever Protocol (YOCP) is a significantly suboptimal choice. LvVariant... exists as a choice (with editorial value judgement reserved at this time).
• Use dependency injection (DI) and/or constructor injection (constructor is sometimes abbreviated ctor). But! If the constructed object you are injecting can have purely by-val semantics with no by-ref or active object requirements, this could be a code smell. Specifically, since it represents an "OO purist" idiom of circumventing dynamic typing, which represents far less syntax and bloat. (Plus, joke's still on you! You've just deferred and complicated the exact same problem, abstracting the problem of concrete input parameters to the Configuration class constructors rather than implementation methods. Said another way -- object configuration is probably not best solved with DI in LabVIEW.)
• Acknowledge that "Configure Signal Generator.vi" is an inappropriate abstract method of the supertype, but should instead be reserved as concrete methods of subclasses that "look and feel like they ought to conform to an inheritance relationship but just don't because they don't really IRL and i accept this".

I'll offer my 2c here.

• As a general solution to the problem, point 1 is simply not going to cut the mustard.  As I understand it, part of the problem here is the presentation of the values on the UI and how to handle the different modes of user entered data.  Try telling a user to enter data via String/variant and you might as well just quit on the spot.  This also pushes a LOT of errors from compile time to run-time which is not good.
• The option of dependency injection works absolutely fine IF you are using the objects own methods to interface with the stored configuration data.  By implementing a simple UI for each (type of) class, you can keep the UI interfaces for user data entry completely seperate from each other with zero JSON, XML or the like in sight (unless that's actually your underlying data of course ).  Granted the problem of programatically setting the values of the sub-objects remains but simply pushing the UI work into the objects themselves DOES significantly improve the ability to decouple the various input methods for users at least without creating any new burdens.
• This is simply the same as hard-coding each and every subclass functionality into your code and has almost zero expandability in the future.

As a rule, you should be asking your objects to do things for you instead of telling them what to do.  As such, I find the implementation of the UI interface (for this specific example) into the subobjects themselves the most logical, most flexible and safest method.  Even the required knowledge of JSON formatting or Variants so that the object of choice will understand it is, for me, not a definition of an interface, it's broken encapsulation.  Wiring up a strictly-typed terminal is always better.  If and only if it is impossible to get what you want with strict typing then consider going down the dynamic typing road.

Personally?

Option 3: Define each signal generation method into a separate class, several of which (corresponding to each type of measurement the device supports) are contained in the parent.  Then move the UI (it can be a simple FP with controls on it) into the object in question and tell the appropriate object from the parent to place their UI in a subpanel of your choice (This can be a much simpler approach than it sounds).

That was each and every object only exposes the parameters which are important for it's operation and extensibility is much easier in future.

Shane