mje

The issue with base classes being modified has happened to me again, I've started a new thread as not to derail this one. -m

An issue I've been dealing with for some time is LabVIEW modifying libraries I generate when it shouldn't. This happens to me quite regularly, and was discussed recently. I'm starting a new thread not to derail the old one... Background: I have a re-use library which defines classes which are extended in other libraries or projects. Often when working on my projects, my re-use library files will be modified despite me having never explicitly done so. I just got this when I was doing a checkin: At the bottom of the list is a modified file in the LabVIEW.Messaging.2.0 library, which should not have been changed. I was working on classes extending from those defined in the messaging library, but never made explicit changes to the messaging library itself. There is a single offending line in the class file: Working copy (truncated): <Property Name="NI.LVClass.FlattenedPrivateDataCTL" Type="Bin">%!#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!%"15F.3 Base copy (also truncated): <Property Name="NI.LVClass.FlattenedPrivateDataCTL" Type="Bin">%!#!!!!!!!)!"1!&!!!-!%!!!@````]!!!!"!!%!!%!I5F.3 Both class files (just the XML, none of the supproting VIs etc) are attached, v10.0f2. Though not in this case, I've also seen dynamic dispatch VIs from the base class become modified as well. Am I the only one that sees this behavior? classdiffs.zip -m

LOL, no, just incrementally losing a bit of my sanity each day. What I meant is with previous upgrades of LabVIEW (2009, etc), I saw an issue that was traced back to a networked data directory. Making the data local solved all problems for these versions. But with 2010, the slow down does not seem to be related to that, even with my data directory being local, I still often see a short jitter each time I drop something on the diagram. I'll comment that it is not happening right now though, maybe it overheard me talking about it? I really don't want to beat a dead horse, but I think it has to do with the instability of the 2010 IDE. Maybe it gets worse with time, I don't know? Often times the jitter is a preface to a crash...

Likewise. Long live the projects. Another reason I use them is the virtual organization of my project items is usually different than their physical location on disk. As George mentioned, I'll sometimes have multiple projects open as well, which would cause problems for VIs common between the projects otherwise. I also don't think you can manage distributions without projects, though I've honestly not tried outside of a project. If the project explorer is to blame, abandoning it is not an option with my workflow habits. After upgrading once I saw similar slow down problems, and tracked it down to my LabVIEW Data directory defaulting to a network location, moving it to a local location mitigated all the issues. This doesn't seem to be the cause of the issue now though. As for system depen

Same thing happens to me, though only for a fraction of a second. I'll drop something, wire nodes, or generally do anything that affects code and the IDE will hang for maybe 100 ms. My guess it's recompiling? Irritating. Happens on all three of my development systems, both in XP and Win7.

I used to do that a lot as well, but the strictness of the event registration refnums led me to abandon that route since any change to what was being observed resulted in a hierarchy of VIs needing to be updated. What I usually do now is. Create user event refnum. Create some kind of callback object, an occurrence will do, but I usually use notifiers to return some sort of signal. Launching process will start the asynchronous VI then block on the callback. Asynchronous VI registers for the user event, then signals the callback. Launching process is signaled and continues on its way. More steps, but I swore a long time ago to never use an event registration refnum in a connector pane ever again. The code that depends on it is just too fragile. -m

The only think I can think is the dynamic event registration terminal forces a valid refnum when it operates (despite the fact that you've supplied a constant which should not be valid). Hence when your event frame runs, you have a valid refnum, and once the register for events primitive operates, everything works as expected. In fact I believe this might be the case with most/all of the dynamic event primitives, though obviously I'm just guessing. As for the rest, weird stuff. I don't have time to download and play, but: I never expect to have to wire through the event reg refnum explicitly to the right side because it is a refnum. Once operated on all your left with is the numeric reference which should not change and doesn't need to be written back (except the aforementioned bit of voodoo).

I'm aware I "owe" you an example, I have not been able to narrow it down to a concise list of steps to reproduce. I work with a re-use library in which I extend its classes in multiple projects, all I can say at this point is it's at least a weekly occurrence where a base class member in the library will get modified for some reason and I revert. It's always a dynamic dispatch method and occasionally the lvclass itself, beyond that I have not been able to pin it down. I suspect it's related to property nodes, but again, that's just a guess, and I don't want to send this topic off on a tangent...

I'm a little confused as to why you can't just leave the "Plugin Interface.lvclass" in two or more projects. Projects don't claim ownership of items, the lvclass should not be modified by inclusion into the project*. By using a source code distribution, can't you just place your base class external to your executable, and have all your built-in interfaces inherit from the external class, as will any interfaces built outside the context of your project? *There are definite bugs that cause class attributes or methods to be modified when working on descendant classes, I can't deny that...I just always revert those with source code control.

This looks awesome. Can't wait to play with it.

That and preparation. Most people there probably have summer tires, which are terrible in cold weather with or without snow. Add in even a fraction of an inch of the white stuff and you might as well have ice skates for wheels. I ruined a rim, wheel, and joint one year because I got caught in the first snow fall with my summer rubber on (Boston area), and I have twenty years of snow driving under my belt. All wheel drive, ABS, TCS, ETC don't matter if your tires are frozen with no grip...

Meh, I hate LabVIEW as well. C/C++/C# too. Also hate PHP, VB, Perl and most every other language I've used. Hate databases too! While we're at it CSV files suck as well. Point is while I have reasons for disliking all of the above, I also have as many reasons to like each of them as well. Each has their place. LabVIEW, like any other language, has its strengths and weaknesses. I find myself paying little attention to the text-based zealots who refuse to acknowledge there might be another way of going about doing things, and similarly I don't pay attention to the all-out LabVIEW supporters who refused to acknowledge its limitations and weaknesses.

I'll point out this discussion reminds me of a common practice I do while coding in LabVIEW: close VIs after editing them. More than once have I worked on a VI which is called in a tight loop only to watch the performance of the calling VI get destroyed by leaving the front panel open. As a habit, I close all but the top level VI whenever I'm testing execution of something (except if I need to probe values).

Most likely it's as jg mentioned, for the Web Builder UI. Which looks pretty slick I might add. I'd welcome an overhaul of the UI components, but when they do do it, I'd expect it to still be cross-platform owing to NI's long history of doing as much. This is part of the reason I'm not holding my breath for a set of native feeling controls.

I'd put that percentage even heavier on the UI side. I honestly can't quantify the effort I put into writing obscure hierarchies of VIs to deal with the oddities features of the LabVIEW controls in an effort to make the UI behave at least somewhat consistent with anything else the user interacts with elsewhere. For anything other than the basic scalar controls, I find it takes all of a few seconds for a user to realize they're not dealing with a "normal" control. Don't get me going on trees or multi-column list boxes... I develop 100% Windows platform locked applications, and I swear, next time my UI is going to be 100% .NET or WPF based controls, except for the graph objects. The graphs I think are the strongest UI components NI has, and even they are showing their age.

For the life of me I can't manage to reproduce a situation anymore which the box sticks around again, but I can reproduce a side effect: after getting focus, navigation of the tree resumes from the last item to receive a mouse click, not a "valued" item or an active item. This is interfering with my key navigation. MysteryFocus.vi In the attached VI, once it it running: Select a cell in the "1-X" row. Press the tab key multiple times until you navigate to one of the cells in the "3-X" row. Press enter to exit edit mode of the tree. Press tab such that the tree control regains focus. * Press up or down. Notice how the navigation goes to the "0-X" row (if you pressed up) or the "2-X" row (if you pressed down). The navigation continues from the row which was originally clicked on with the mouse (the "1-X" row), regardless of which row is currently "valued" or active (the "3-X" row). * Also: where does the focus go when one finishes editing the tree control (which forces step 4)?

Wondering if someone can clue me into what I'm looking at here: I'm trying to enable key navigation when editing contents of my tree control (tab, up, down, etc). When I do so, I also move the value of the tree, the active item and what not, but there's this dashed box that remains anchored to the zeroth column of the last item that was selected with the mouse. What is this? Can I move it programmatically? Or even just plain get rid of it? -m

If you have a Windows server, it doesn't get much easier than VisualSVN Server. If you're going Linux, I'd be surprised if any of the major distributions didn't have some pre-canned option that can be installed easily with whatever flavor of package manager they have. -m

Makes sense, especially on the control side. As for the "something", I wholeheartedly agree. I realize XControls are ideal from a functional stand point, but the labor barrier to creating them has kept me from ever creating one in any context.

I have wished the same thing many times, but I don't think it's possible. I'd love to find out why... The only idea that came to mind for me was parsing the flat data and generating a table of property values. Seemed like a lot of work though so I never really explored it much.

I hereby resurrect thee... Was looking for this today myself. This is what I came up with: Added benefit is if you supply a variant, the VI will make sure that the returned GUID has not already been defined as an attribute key. It of course generates an entirely random number which doesn't conform to any specification that places significance on certain bits etc...but it suits my needs just fine (creating positively unique keys).

Yes, but the caveat is I won't always need 2 ranges. It can be 1, 2, 5, or 3, for three is the holy number... Well in reality, it can be 4 as well. And maybe occasionally 6. Well you get the idea. Can you do this? And still have the axes show on the plots such that the ranges are editable?

Something that has always stumped me in LabVIEW is displaying discontinuous ranges in XY Graphs. Is there a way to do this? For example, the top plot shows a single graph with two plots. Displaying them as-is results in a whole bunch of empty space. Not only is it ugly, it makes the graph next to useless because you can't see any fine detail in each range. Now for the bottom graph I cheated a little and actually made two graphs, placing them next to one another. This works fine if you can know at design time how many graphs you'll need (which I don't). The other way I've handled this is by normalizing, scaling and offsetting each range such that they do display continuously, then hiding the axis from the user so they don't see the transformed coordinates. However this time I sort of need the axis in the original coordinate space to appear. Is this even possible using the stock XY Graphs?

Ok Yair, you had me worried so I whipped this one up: The snipped returns an array {1, 2, 3, 4}, which is what I would expect. The registration queue appears to be preserved. So really, it's my question #2 which stands.

Yes, unregistering does flush the queue. You bring up a very good point though that I never considered, does the queue for A indeed get flushed if it was registered before the call or is it preserved if A is still a subject? I'll write a test case for that, eventually... Yes, they are distinct objects, however they are both involved when an event signal is generated. I'm under the impression it is the event refnum itself that keeps track of which registration refnums are subscribed to the event, in which case signaling an event must operate on any registrations for that event so the signal can be queued in each registration queue. That's my fundamental understanding of events-- in any language. The example I posted was trying to boil it down to a simple one-VI example to illustrate what I'm doing. Now that you've brought up the point of flusing, I suppose my general concern is I don't know exactly what's happening in the registration primitive. If A is already a subject before the registration call and the call is made such that it is again a subject: Is the existing event queue for A preserved? Easily tested. Is the registration process atomic? If an event is generated elsewhere which the registration observes during the call to the registration primitive, does the event generation block until the registration is complete? That is is there a possibility of missing event signals? Again, the only case where this matters is when an event is a subject of registration before and after the call. If the answer to the first question proves to be the queue is flushed, then this whole idea is not implementable using LabVIEW events. I'll have to check this as soon as I can, but if it proves to be preserved, the second question (which is my original one) still remains unanswered and I can't think of a test-case to evaluate as much.