shoneill

That's really cool, I did not know that removing a loaded class was possible.... Must remember this.

@mje Virtual machine - VPN - Remote desktop. That's exactly what I've been doing for a while due to this extremely annoying behavior. It's all good if Darren can show how fast he can program with quickdrop and all but out here in the real world (home office days or remote debugging) all that is worth very little. The lag over this connection (not to mention the less than 100% fidelity of mouse integration over Remote desktop) makes programming really chore.

I have started compositing my classes. You could include a "Protection" class in your different file formats which offloads the protection functionality into a seperate class. That was inheritance is no longer an issue. You then have a file class with a bunch of sub-classes which you can access one by one and query whether they're implemented or not.

I'm currently slogging through both season 6 of mad men (with the wife) and season 3 of Boardwalk empire. It took me a while to get "into" boardwalk empire but once you get to know the characters just a little it became quite compelling to me. A lot of good actors in there and fantastic production quality.

This seems to be a bit of a recurring problem. We've seen the exact same problem. I've recently also seen that a lot of the time on my machine the "Acquire Input" VI which uses DirectX (apparently) calls to get the mouse information loses all mouse clicks. It reports mouse coordinates fine, but the clicks seem to vanish. The thought that these issues could be interrelated only occurred to me today. Could it all be related to a problem somewhere in the mouse input routines in LabVIEW?

The thread seems to have gone very quiet. I personally think that the server actually needs to do the managing here. The client is a client not only for the messages received but also for the CODE to process those messages. We're actually sending code to execute over the network. How to deal with different OSes, I dunno. How to deal with some serious security issues this could raise I also dunno. Going this route also allows changes in Alice's software AT RUN TIME to be mirrored on Bob's client. Seems to me at least like the solution is a way to piggyback code onto the messages themselves. Kind of sounds like a virus to be honest......

There's a proposal for "sparse enums" on the Idea Exchange on the NI site. Vote for that if you really want this functionality. You're certainly not alone.

I've gone through this though process a few times int he past looking at properly scalable architectures. Given point 4 (That Alice cannot herself know the full scope of the possible classes involved) then we essentially have a range of undefined classes on the server side. This makes it essentially impossible to configure Bob's software pre-compile in isolation because we can only link to a given state of Alice's software which seems flaky. You would almost need to be able to link to the build spec for a given version of Alice's software (impractical) or link to an actually running version of the software where we could actually retrieve the entire source code for ALL included classes within Alice's software after which Bob can then build against that and include all of these classes. This of course requires Alice's compilation to be made with a feature to make the class source (preferable password protected) available on request. A method to NOT expose the classes outside of the build process would of course be a big addition to the security of such a system. I have thought it would be really nice to have the ability to send the object code WITH the object over the interface (perhaps only on request from Bob's software) and then instantiate the object dynamically on Bob's computer. Of course this raises a lot of questions such as OS differences between Alice's and Bob's software and such but it seems to be the ultimate solution to the problem at hand. PS My considerations were actually between Host and RT Systems, but the problems are exactly the same. Shane. PS A mini-compiler for Alice's software where the classes can be custom compiled for Bob's machine before making them available for Bob's software would solve the problem if and only if it had the ability to compile classes for any given target (RT, Win, Mac, Linux etc.)

^^^^ This a million times.

Well they say that admitting it is the first step towards healing.

You can pin the axis display to the bottom right by using a viewport. See HERE for a very simple example on using viewports to view duplicate copies of a single model. Prohibiting the scales to be panned and scaled by the camera controller is still awkward but at least this way you can limit the draw region of the axis indicator to where you really want it.

Oh ,yeah, I've seen this before. Haven't seen it since a few LV Versions any more but I have DEFINITELY come across it before. I even had it happen in built applications which was nice.

I believe in the upper of your two pictures there's a buffer allocation on the wire junction. LabVIEW sees that you're doing something with the second wire and creates a copy of the array element. The resulting DVR is NOT pointing to the actual element in your array if my assumptions are correct but is rather pointing to a separate copy of that array element in memory. In order to do what I think you're trying to do you would need to create an array of DVRs and make a copy of the existing DVR from the array to have the DVR pointing tot he array element. Does that line up with your experiences of the code behaviour? I believe the only way to create concurrent DVRs to a single memory location is to branch the DVR wire. You can't call the "Data to DVR" several times because this (AFAIK) creates several DVR pointing each to different memory locations.

I have the feeling some times that this is what takes up about 40% of my time programming LabVIEW...... Ctrl-Mousewheel is your friend here though.....

Cool, now that I got someone else to actually try it out, I know it works.....

I've heard that if you name the property folders akin to polymorphic Menu items then you'll have a property node hierarchy. I've never actually tried it though. Read:Data Read:Status Read:Otherstuff Write:Data Write:Status should give you a hierarchy when choosing the property node with Read and Write sub-menus.

Well we recently ported a Version 8.5 project to 2012 SP1 and had very little trouble. A couple of toolkits were no longer automatically installed (Internet toolkit for example) but these problems were quickly fixed. The inability to have a time critical VI in a Timed loop caused errors, but again was quickly remedied. All in all the code worked as it should with the exception of a Waveform chart bug which (If I'm informed correctly) will be patched soon. So whether 2012SP1 turns out to be a worthwhile change over 8.5 (I think it will) time will tell. The ability to port relatively painlessly between versions is a testament to the work NI has done in this area. Kudos for that. (wrong forum ) One thing which will keep us going for a while are undocumented bug workarounds in our code (from 8.5) which are essentially no longer required in 2012..... I foresee some future Rubes.

Wait. 8.2 stable? Maybe if you don't use LVOOP, otherwise is sucked hard. 2012 has been a real mixed bag for me. Having a lot of crashes and other problems with drivers (FPGA etc.) 6.1 was stable. I used it for years.

I ran into a crappy behaviour of 5-3-3-5 the other day. I thought I'd be smart (You just know how that's going to end up really) and wanted to connect up two VIs with the same conpane pattern (5-3-3-5) but have them vertically staggered so that the top two connectors of one VI lined up with the bottom two of the next one. Lo and behold, even LabVIEW can't make 32 divided by 5 equal an integer and there was an extremely annoying 1-pixel bend. This may be also the background to some of NI's own 1-pixel benders.

This bug needs to be squashed in LV 2012 also, it's mucking up UIs for existing applications.....

I've had this problem, cool to hear there's a solution for it.

I can think of a few use cases also. Aside from thi following being probably a bad implementation.... I have a process which transfers a relatively large data set between a background process and y UI via User events. These data packets can be several megabytes in size and the ability to ENSURE that only a limited number of these events can be stored in the queue helps me keep a cap on my RAM requirements without having to implement a handshake protocol. Bot mouse move and resize events are the clear winners with the new implementation. I wonder if it also works with XControls, limiting the "backlog" which can sometimes cause a very disjointed XControl update experience with the XControl sometimes still updating after the host VI has stopped running.....

I've recently switched to always working on my office PC via remote desktop instead of taking data with me and maintaining multiple VMs (Home and work). Less headaches with forgetting my USB Disk (This way I just leave it at work). Less re-compiles based on RT and FPGA files "changing" becuase they're suddenly on a different computer. Re-connecting to running RT systems is a lot easier int he IDE when always working from a single PC.

Using a Powerpoint file to communicate a bunch of URLs.....

Favourite LV2013 addition? Fixing waveform chart bug which should be also fixed in LV 2012 but probably won't be........ Aside from that, the ability to limit the depth of any given event queue is really huge. If you've ever thought of combining events with a notifier to get around some messy "Mouse move" events, this is the answer to your prayers. Shane