Yair

This site is not about Lava, but something else called LabVIEW. I would start with the Lava site - http://lavape.sourceforge.net/index.htm By the way, if you're going to be software engineers, you should definitely be able to do that much on your own.

OK, I was seeing it for some of the other threads as well (including older ones), but now it seems to be back to normal.

OK, I was seeing it for some of the other threads as well (including older ones), but now it seems to be back to normal.

I just made two posts from Firefox and both resulted in a corrupt topic. I'm trying the same from IE. http://lavag.org/topic/16571-corrupt-topic/ http://lavag.org/topic/16567-script-new-lv-class-with-private-data/

I replied to this topic and now it appears to be inaccessible: http://lavag.org/topic/16567-script-new-lv-class-with-private-data/ This is what it looks like:

I didn't look at the code, but I'm guessing that this is the only way (because LV needs the class to be saved for some reason). If you look at the UI, you will see the same thing - you can't create accessors before you save the class.

mje, just so we're clear, did you try the method I suggested in reply 10 of the other thread (get the default objects and do the casting on them)? Did it help with the memory allocations?

Without going into the details of the allocations, I will just point you to the following thread, which you may find familiar - http://lavag.org/topic/15354-testing-for-the-same-class/ And note that regardless of AQ's performance trick (which can be found at http://lavag.org/topic/15135-performance-tweak-for-lv-classes-and-to-more-specific-node/ ), using the default value of the class there was more efficient. I don't know if that changed in 2012.

You can use the Application class property All VIs in Memory to get the names of all the VIs and then use that to open a reference to each VI and call the method Lock State.Get on it. This will tell you if it's locked. You can also use the Set method to unlock, but then you will also have to handle errors and so on and save the VI.

I don't understand the question. The NI DB toolkit is simply a wrapper for various ADO calls with some added management of its own. It shouldn't matter at all which DB it's working with, because you're using a completely standard interface. That said, if you don't like it, you can always use other methods. I know that people posted implementations which call the SQLite DLL directly and it's possible that there are also some for MySQL. If not, you can find simpler wrappers around the ADO calls which should be more efficient. LabSQL is one which comes to mind, but there should also be others.

Why are you posting this here? This belongs in the LV idea exchange over at NI. Before you go posting there, be aware that it was already suggested several times. The popular one is here, so you can vote for it - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Abort-all-VIs-Button-in-Taskbar-Modal-Windows-Problem/idi-p/1472808 Also, if you read the comments, you will find links to several tools which already help you with this today.

See here too - http://forums.ni.com/t5/LabVIEW/LabVIEW-2012-SP1/m-p/2304240#M725167 Like Tim said, you should probably not expect new features. If you want new features, you can request to join the LV 2013 beta - http://www.ni.com/beta or look at the In Development ideas on the IE - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas/status-key/indevelopment

My understanding is the CDSM's diagrams are also first class citizens in LV. At the very least, they have their own special VI Server classes, both for the structure and for the diagram. My guess would be that this is not possible using XNodes, but I can't say I looked into them deeply enough to provide a sound base for that guess. It's mainly a feel for how the system works. Flarn, if you look through the structure classes and find an External Node class, don't get excited. That's the precursor to XNodes, and they were basically implemented as a flat sequence structure which held the actual code and was then minimized and hidden behind an icon. I don't think they will do what you want.

And a couple more things I didn't notice earlier: Your init VIs are in the control class, which is a no-no. The control class should not be required to know about its child classes. Instead, have a separate init VI for each class inside that class (you will still need to give it a full name to avoid having LV think it's a DD VI). You can collect these into the PolyVI I mentioned earlier. The Control class then has a set ctl ref VI, which is the VI these init VIs call to put the ref into the object data. If you want to protect it, you can make it protected scope, which should still allow the children to call it. You might wish to follow the VI Server hierarchy exactly. The Ring class actually inherits from Control>>Numeric>>Named Numeric. Likewise, implementing the actual classes yourself would mean you didn't have to rely on the LV UI, but that is really a lot of work and is probably not worth it. And regarding that last part, I only now really looked at what you're doing, and I'm not sure I understand the point. Sure, this could work for the idea in the IE, but is there anything else it's good for? In many ways, the VI server API already works like DD VIs do, so there shouldn't be a need to wrap it.

After a quick look, here are a couple of comments: I'm not sure whether or not this is a worthwhile project (particularly for learning LVOOP), but it can probably come in handy if you want to generate controls inside picture controls. LV 2010 should allow you to create property folders for accessor VIs, which will allow you to call the VIs using property nodes (easier for the user, and means the need for an icon is considerably lower). I don't remember if in 2010 you can do this automatically from the accessor creation dialog or whether you have to do it manually, but it can probably be automated through VI Server. I don't think you need to write the reference twice in the init VI. Just write it into the Control class and then have the specific class' read VI downcast the reference to the correct class. You could probably gather the init VIs into a polyVI which will allow the user to create a new "reference" simply by wiring the reference to that VI (although you should check how that behaves first, both with regular references and with strict and unknown references).

At the moment it is back to working correctly. Who knows what tomorrow will bring...

Is it weird if I prefer that look?

Hey, there's a new format which uses the same subject for all emails. That's great...

Look through the documents in the group Jack linked to. PJM should have a link there to his icon editor. In 2011 this became more of an issue because the IE is now a packed library (presumably to improve performance, but hey, at least it's not password protected), so now you have to download the source separately.

The icon editor uses a 256 color palette, which is why it won't let you select 254, but I believe 255 should be allowed inside the bounds. That said, recently I've been using LV 2009, where I'm pretty sure I'm using a modified editor, which might allow this even if the original doesn't.

You can also minimize some OS dependence by using the input VIs to poll the mouse location and button and use VI server properties to control the position of window.

Well, I don't have that much practical experience with scripting and I don't have LV in front of me, so excluding some proper method which may exist, here are a few quick ideas: Make Selection on all objects[] of the diagram, then copy and paste. I believe this won't work if the VI isn't idle. Enclose the content in a sequence structure, then move the structure and remove it. Use a VIT. This is simpler in that you have a starting point without requiring any code, but it won't work if you already have an existing VI you want to put the code into.

Scripting has a lot of these holes. The fact that it is official now does not mean it is fully debugged. In this case, I don't think the Top Level Diagram should implement the Move method, as moving a diagram doesn't seem to make too much sense.

There will always be a single click first. With a double click you will get two events - one for the first click and one for the second. If you want to ignore the first one, use the Double Click terminal to discard the event if it's false.

The main reason I don't use the OpenG panel VIs is that quite often I want only a subset of the controls and it's important not to handle some of the controls I want to avoid. Usually it's either a matter of building the refs array manually or using one or more of the Controls[] properties and then deleting the unwanted refs from that.