Stobber

That's fine; if the drag fails or is canceled, the subpanel won't load a new subVI and the picture indicator will hide itself. The user can try again if they want.

One thing to watch out for when dealing with things like this is the VI's Mouse Leave event. In your case, this is probably less of an issue because you're inside a control and you can monitor for the drag leave event as well, but you could still be bit (for instance, if another window decides to suddenly display itself under the cursor in mid-drag or if you have an ActiveX control in the middle, which I believe still triggers a Mouse Leave event). In such cases, you could be left in an unexpected state and writing code to account for such cases (at least by restoring the FP to a safe state so you can retry) can be difficult.

The LV Help defines the Drag Ended event:

I just installed this package into LV 2011, and the palettes weren't shown anywhere. VIPM couldn't find them, either. I looked around and found all the code and the .mnu files in <user.lib>\_LavaCR\UI Tools, so I just manually added functions_lava_lib_ui_tools_treeoop_addon.mnu to my palettes. It looks like this UI Tools addon needs to be coordinated with the others so each can safely install its own palettes without stomping on anyone else's.

Very nice tool, by the way!

I'm not surprised that Stobber got this working.

Just to clear the air, I never register for any events on the subpanel itself. I laid a transparent 2D Picture indicator over the panel and registered for Drag Enter and Drop on that. When Drag Started fires on the tree control, I make the transparent picture visible so it can fire events. When Drag Ended fires on the tree, I make the picture invisible again so it doesn't interfere with mouse clicks in the now-loaded subpanel VI. It works really well, and since I'm controlling the picture indicator's state in sync with the user's actions, there's no need to initialize anything before the container VI starts running.

Got it working by expanding on AQ's suggestion. Here's an incomplete example for reference.

DND Subpanel (lv11).zip

In practice, it probably doesn't save you much --- I can't think of a way to make arbitrary drag-n-drop work without having two procedures, one in the host VI that handles drag-n-drop when there is no subVI hosted and another in each of the subVIs to tell the host to change. Ug.

Yeah, I need to drag data names from a tree onto different views. The two-step handler wouldn't bother me; I just need something that works for unfilled subpanels.

I'll try the suggestions you gave and report back on what works.

Can it be done? I registered for the Drag Enter? and Drop events on my subpanel, but they don't fire when I Drag onto them. The same event cases fire when linked to a string control.

Easy there, pokey. I recall asking via PM or contact email (or something) back when I left the company. Regardless of when notice was first given to whom, thanks for handling it.

Staab: I thought of a second solution for you... you could build a Variant attribute database where the key is the name of the class and the value is the default value of the object. That does away with requirements to put the classes in a particular location in the EXE.

That's what mje was talking about with the "lookup table".

AQ's workaround for a deployed application (always my situation) is to add the .lvclass files to specific paths inside the built EXE, then provide a path to the class file using the Application Path primitive and a relative path inside the EXE. It doesn't actually pull an instance of the object from the application's memory space using the qualified name, but it's a workable approach since the EXE path can be obtained using a prim.

To specify the location of the .lvclass file inside the EXE, add it to the "Always Included" list in the build spec, then create a "Destination" for it with the full path. For XYZ.lvclass, an example Destination Path would be C:\build\MyApp.exe\XYZ\. When you want to load an object of XYZ at run time, you provide the path C:\build\MyApp.exe\XYZ\XYZ.lvclass

AQ told me that all the classes to be loaded need to be either inside the EXE or outside it; they can't be mixed. I didn't test that assertion b/c all my classes will be shipped in the built EXE.

AQ, maybe I misunderstood the question, but I think Stober needs a means of translating a qname to a value, which isn't covered in that post? Those VIs only work if you already have a value (or path)...

mje understood the question correctly. I'm storing the qualified name of the class in the string, and I want to use it to create a new object of that type when I deserialize. I looked at those Open_G VIs before posting. Maybe neither of us understands how to use them to solve this problem?

I need to get an instance of a class that I know will be loaded with my application, but "Get LV Class Default Value" seems only to work with a full on-disk path to the .lvclass file. I tried passing in a string with the fully qualified name of the class, but it gives me error 7. Is there a way to get an instance of the class on my block diagram by referencing it in memory?

(This is for a generic object deserializer, so I can't simply drop a constant of the class on the block diagram.)

(No, I'm not trying to reproduce AQ's work in the other thread on serialization. Although the VI I'm writing is generic, the serializer is mostly special-purpose.)

DIAdem is quite strict about the allowed characters for property names, '.' (period) is not allowed. Upon resaving the TDMS file the period will be replaced by an underscore '_'. (the list is quite long).

Ton

Here's a post on the NI forums detailing which characters aren't allowed in property names: http://forums.ni.com/t5/DIAdem/Properties-in-TDMS-file-not-visible-in-Diadem/m-p/1747404/highlight/true#M14082

HDF5 seems conspicuously absent from the discussions and comparison charts.

I'm surprised nobody else noticed this. NI used to have an API for a subset of HDF5 that shipped with their Modular Instruments (Scope, FGEN, HSDIO) drivers called NI-HWS. It was pretty solid but needed some bug fixes that never got attention. The HWS format, and all HDF5 support along with it, was ultimately canned in favor of promoting TDMS as the platform-supported file format for waveform data storage. You won't hear anyone from NI marketing talking about HDF5 again.

Most of the stuff I readed @ http://zone.ni.com/d...a/tut/p/id/3727 (sorry had to read first before asking ), it then made me more curious about the disadvantages... because how NI describes it, it is the best format available which I doubt.

Again, I'm surprised nobody else has mentioned the data types that TDMS doesn't support. One I can immediately think of is multi-dimensional (>3 dims) arrays: TDMS doesn't support them, while HDF5 does.

Oh, another is that you can't put array or cluster types into TDMS properties. That can lead to some unfortunately creative restructuring of your metadata in order to facilitate the format.

Is anybody using LVOOP in LVRT? I don't see any mention of it on the NI site or here in a cursory perusal. I'd like to bring modern programming methods to my LVRT development, but I'm nervous about uncited claims of slow execution and memory leaks.

If you're using LVOOP in LVRT, what's it like? Any issues with performance? Any special considerations you have to follow to optimize memory utilization? Any weird bugs you keep running into?

If you're deliberately not using them together, why? I haven't started yet simply because nobody else I know has, and being the first adopter usually means being the first to get burned!

--------------------

Edit: I'm not NI anymore. I wish the mods would fix that for me...

Bug report: BitMan creates several empty folders in the User Controls palette. It looks like this is because it installs a tree of several non-underscored folders under user.lib, which causes LV to auto-populate a Controls palette.

James, any chance of you sharing the source for your custom tool or contributing it to a new community project to develop an "Actor Manager" we can all use?

I live here. I'm in.

In general, I think the usefulness of the Format/Scan functions are overlooked when working across data types.

I have to be honest: I've never used them that way. I appreciate the tip, Phillip!

I think that's pretty much the whole problem: you're using panel elements for diagram information.

In my defense, LV is structured in such a way that panel elements become diagram elements via the requirement that every subroutine have a panel. I want to design a good API that limits the potential for bad values passed in by the client, but I don't want to create a clunky coding scheme in order to do so. Using a ring is natural here.

I only verbalized the XControl possibility to hopefully spur conversation about alternative approaches.

I ended up just adding a utility VI to the API class that uses a case structure to translate ring values into the integer values that correspond with the ring strings. Future devs working on this class will have to know that it needs to be updated whenever the typedef is modified.

I am using a ring, and it does have the baud rate as the strings. The ring values are fixed by the driver API I'm communicating with.

Hi all -

I'm drafting up a simple LV API for a serial-based pressure transducer. The driver interface lets me select the baud rate for communication from a list of values, and the value that I send to the transducer is an index into this list. (e.g. if I want to communicate at 9600 bps, I send the sensor '2', which corresponds to the rate of 9600. If I want 19200 bps, I send '3'.) After sending the desired rate to the device, I have to reconfigure my serial port before talking to it again. Unfortunately, I need the rate for the serial port configuration, not the index corresponding to that rate in the driver API.

To solve this problem, I did the usual maneuver of creating a ring typedef for the selectable rates in the driver, then grabbing the string off the typedef and converting it back to a number to be used as an argument to the Configure Serial Port VI. I don't like this on principle, because it depends on the format of the typedef strings never changing in the future -- if they stop being legally formatted decimal numbers, this code will break -- but it worked for my proof-of-concept. Here's the VI:

The string formatting dependency notwithstanding, this is also a bad idea for a hardware driver API because calling into the property node forces a thread swap to the UI execution system. This isn't a high-performance driver, but I still don't like the idea of waiting in the UI threadpool to execute a hardware call.

What's a better approach to this problem? The ring seems like it's definitely the right choice for the API interface, but I need its strings as numeric values alongside the list indices that are sent off to the device. I considered creating a second typedef that holds numeric values of both things in a lookup table, but then I'd have two diagram constants (or a typedef and a lookup VI) that would have to be kept in sync every time the software is updated. I'd prefer to encapsulate all this information in a single diagram element. An X-Control seems like overkill here, though.

Ideas?

The description makes sense; haven't opened the attachment. It's common in C to check for a null pointer, and this seems analagous.

Yep, it is analogous, but many things common in C make no sense in a by-value dataflow language, so I want to make sure the rest of the LV expert community agrees that this is a good way to do it.

I've noticed a budding trend in my LV development that I want to stop and consider. When I have a class that aggregates other classes -- meaning that the owning object has a different lifetime than the owned object(s) -- I've started putting the owned object into a DVR and holding the DVR in the owning object. The reasoning for this is that I can check for a null refnum on the DVR when I want to see whether an owned object indeed exists as a member of the owning object. It leads to extra work every time I access an owned object, but I can make merge VIs and templates for most of that.

I've attached an example of this. Is this stupid, or does it make sense?

Alternatives I can think of are:

• Store the owned object directly in the owning class. When I unbundle the owned object, compare against its default value to see whether it's actually there. There are problems with this, though. If I change defaults in the class definition, they aren't reflected in any constants I've placed on the block diagrams of calling methods. I may also need to use the defaults as a valid configuration for the owned object.
  
• Add a Boolean data member to the owning class that indicates whether an owned object has been loaded. I hate this approach though, because it's a configuration parameter, not a data member. I don't like that I have to lug a bunch of meta-information about the object around with its real data.
  
• Make every owner hold an array of owned objects, but know that the array size is limited to 1. Then I can check for an empty array when looking for the owned object. Of course, there's a memory allocation every time I add an owned object to an owner, and there are extra array operations every time I access or modify the owned object.
  

Aggregation Discussion.zip

Hey Ed. Double slashes are good; as you said, they're part of the INI syntax. Triple, quadruple, etc. slashes are bad, and that's what's showing up in the VI's output right now.