Yair

I know that the DLL has to be in the same directory as the top level VI, so when creating a new VI, which would be in a different directory, I would expect to you have problems, but those should be run-time problems, not edit problems. Brian Tyler is the head of the LV .Net team and very active both on the NI forums and in his blog. I suggest you try searching both places for answers to this and if you can't find it, post a question to the NI LV board. Brian usually picks those up rather quickly.

Interesting. I just ran the test VI again and found an interesting "hole" - the menu bar and toolbar don't invoke the mouse leave event, nor do they respond to mouse up/down events, effectively creating an area which is "dead". Can anyone confirm whether this is still so in LV 8? Download File:post-1431-1156364911.vi

Actually, the last four seasons or so were filmed in California, but yes, it was occasionally funny to see things which are obviously canadian. I must say to the show's credit, though, that it was relatively good in creating an "American" feel. I remember one episode, for instance, where they painted a lot of rocks in a quarry in red to make it look like the NM desert. There were also quite a few other series which were filmed around Vancouver (like Macgyver or Stargate). BTW, one show which was particularly good at creating a very international feeling was Alias. I never looked around for how they did it (probably CGI), but they usually managed to convey a pretty good feeling of being all around the world (I think it was also shot in CA). If only the series was good as well... I mean, it started out relatively OK, but grew more and more ridiculous. I just hope (and believe) the Lost won't suffer the same fate.

Unfortunately, I haven't seen that one yet, but you already know what I think about Jodie Foster. :thumbup: Anyway, this is a common mistake made by American cinema and TV, probably because of the fact the writers didn't think and assumed that American forces can go whereever they want. I think the worst offenders (less in violating jurisdiction and more in spending US tax dollars) it the X-Files. Just off the top of my head, I can remember Mulder and Scully going to Puerto Rico, Canada, Sweden, Russia, Hong Kong, the arctic circle (either in Alaska or in Canada, I don't remember) and Antarctica. When you consider that they work for the FBI, that's in charge of domestic investegations, that's quite some spending. Well, there was a whole series about this (and a rather good one, too) - Due South.

OK, I understand the structure of your sentence now. Thanks. In general, I think that ambiguity is bad. Think about this from the user's point of view. You send an email with your code and then nothing happens. Does this mean that your code is OK? Does it mean that it wasn't accepted? Maybe the server crashed and your message was simply lost? Or maybe the person in charge is just out in the field for a few days and no one saw your message? That's why I think it would be best to do something like this - when someone sends a submission they get a reply within a day or so telling them that their submission was received, that it can be opened without a problem (or not) and that it conforms to the minimum requirements. Of course, this can be split into several emails, depending on the time it takes to review such submissions, but the point is the user will know what state their submission is in and if they get no reply at all within 2 to 3 days they can assume that there was a problem in the reception of their submission.

You should note that I only brought this up as one case where a VI stays in memory, but for which there is no indication. I do not say this is necessarily a big problem.Currently, copying LV code and attempting to paste it in any other application (including other instances of LV) results in the bitmap being pasted. When you close LV, it gives you the dialog for choosing whether to save or discard the VIs and only keeps the bitmap in the clipboard. This strikes me as reasonable. I would definitely expect LV to give me the chance to save all unchanged VIs in memory before closing it. How about adding another viewing option to this dialog, where you get a list of all the VIs and you can select what to do for each. Maybe something like the VI settings window we would get when building an executable (where you can modify the options for each VI in the build) or maybe something where you can check one or more of a few columns for each VI to decide what to with it. In any case, this should probably also leave you the option of handling individual VIs (e.g. tell it "discard these VIs, save those, and let me look at that third group so that I can decide for them").

Try Tools>>Advanced>>.Net Assembly References. This should register an assembly inside LV on a permanent basis.

What I actually wanted was a confirmation that my submission was received, not that it was among the top 5. It also wouldn't hurt to know whether the entry meets the minimum requirements, so that it could be fixed.In any case, this quote is unclear. I didn't receive an email, so does that mean that my submission does not meet the requirements or that it is in the reviewing process?

How about sending confirmation emails or publishing the names and dates of the submitted entries so that we know that our submissions got through alright (or didn't)?

One subset of this which easily confuses users is if you've Ctrl-C'd some VIs. Even if you close the calling VIs they would still remain in memory (in the clipboard, also visible in the VI hierarchy window), but it would not be clear that they are. This could actually be quite a common use case. I don't know whether LV 8 with the project and the seperate application instances did something to change this.

Stephen, I believe that in this case Joe refered more to the option of being able to wire a reference into a node and having that reference determine which options are available to you. This makes it easier than having to find the right palette and VI. This is somewhat helped by the context menu options which let you see the relevant palettes when you click a wire of a certain type, but selecting a method or a property is still technically easier even if the node itself is uglier. BTW, I'm sure if you PM Michael A. he'll put you in the NI group. The more NI R&D guys (and gals) we have over here, the better, and it's nice for them to be easily recognizable.

Since this isn't a mandatory requirement, that would be up to you. The way I understand it (or at least what I thought before I read that line) is how long does the cursor have to stay in one place before you stop calculating a movement.

Not signaling, but there is the LatchValue property which is equal to the Value property. Since a latching boolean can only be read in one place anyway, you can simulate its behaviour by using a non-latching one and resetting it.

Sounds legit to me. Most people reading the NI forums don't read the LAVA forums (and vice versa, actually), so there's no reason not to repeat a piece of knowledge learned here.

This apparently has to do with a change LV made to the time handling after 1969 in LV 7.0. I don't remember (or really understand ) the details, but if you search rolfk's posts, either here or in the NI forums, you should probably find an explanation.

That is probably more of a relinking issue with reordered clusters (and more particularly typedef clusters and subclusters). When you change the order of cluster elements, LV has to relink the bundle and unbundle by name nodes to the right element. There was a bug where this linking would not always happen properly (I'm not sure whether it was fixed yet).

Since we're chastising, aren't those suggestions identical to mine?

I was refering specifically to this (constant vs. control) as being an LV 7.0 only problem. It probably had something to do with a change to the way LV did constant folding between 6.1 and 7.0. As you can see, this seems unrelated.

I know that, but...

I think that Open Office might have support for .xls, but I don't know for sure and I don't know how they implement it if they do.Another option - I know that MS has a viewer for viewing .ppt files. It's possible that they also have one for viewing .xls files and that you might be able to use it. Overall, it's probably better to define your own format using CSV and stick to that, as it's platform independent and you know it won't change.

One of the properties of signed integers is that a substraction operation will still be the opposite of an addition operation. So, if you take each number and substract the previous number from it you will get the right amount even if the number rolled over. You can use this to increment your counter. Since you don't have 64 bit integers in LV, you will either have to use your own logic or one of the floating point representations.

That sounds like an LV 7.0 problem. Do you remember seeing it on other versions?

There are several solutions for accessing LV front panels remotely, but they're basically for controlling the user interface, not the diagram. You have the built in remote front panels, which require the RTE installed to have control, and you have LabVNC and AppletVIEW, which should work without it, but aren't exactly complete products. It is possible that using a remote front panel inside LV to control the diagram will work, but I can't check at the moment. To connect to a remote front panel from LV you need to go to the Operate menu and select the Connect to Remote Panel option. Even if this would work, it would require to have LV installed on the other side. The other option, as you mentioned, is to use VNC, which would give you control of the entire computer.

It should appear in the list of events for the event structure (along with some other new events) when you use the standard supersecret... entries.

The solution I use for this is simple - whenever I have a typedef representing some data, I create a VI which has that typedef as an indicator on its FP set to be an output and use it as a stub inside the diagram. From that point on, regardless of the changes you make, the size on the diagram will remain the size of that VI's icon.