Yair

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

Yes, and isn't it interesting to see (in the X-Files) how much the US looks like British Columbia? The series was was filmed primarily in Vancouver and the surrounding areas.

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.

I'm sure it would seem just as odd for an american to see the RCMP on US soil.

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.

:!: [About an hour later...] I was working with a graphics program. I closed the program. It asked me if I wanted to keep the data on the clipboard when exiting. Maybe that would be a good idea for LV if you close a VI and that VI is still on the clipboard. ???

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.

...I can state that - if you did not get email yet, that your submission does not meet the minimum requirements - your submission is in the reviewing process...

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)?

There are fundamentally three reasons why a user VI cannot leave memory:

1) It is a subVI of another VI and that other VI is not leaving memory

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.

Why is there no emoticon for sobbing?

The Invoke Node would make you "feel more like I'm using an object"?! This makes me really wish that we'd had OO before VI Server. VI Server has conditioned everyone all wrong. The Invoke Node is identical to a subVI call... only it doesn't have an icon so it isn't understandable across human languages, and it doesn't have a conpane, so inputs and outputs are just stacked arbitrarily. The Property Node actually adds some useful syntax (stacking multiple function calls together). The Inovke Node just puts a big ugly text block on your diagram instead of an elegant subVI node. Please don't ask for support for the Invoke Node... I'm not sure I could write code through the tears.

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.

what do you mean by "Timeout when mouse is idle" :question:

the timeout will stop the mouse tracking by starting the application VI or it will clear it and restart the registration :question:

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.

OK. This was posted on the 12th, then Darren says he was speaking with someone last week and learned this little nugget...

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.

but sometimes it happens (the last time with LV 7.0.x) that e.g. a bundle by name changes the cluster element which is overwritten.

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).

Looks like Guillaume Lessard's suggestions are going to be your best way out.

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

No, the problem does not go away by changing to a control.

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.

C'mon yen - get with the times! (LabVIEW 8 at least)

I know that, but...

or get LV to open a .xls file in its native format.

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.

If you change the constant to a control...

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.

Someone please tell me how I can access the VI activation event...

Is there some SuperSecretIniEntry I don't know of yet?

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.

I guess I'm bugged that there is no BD layout capability for a typdef'd control.

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.

The code looks OK to me, but I don't work with files much this way.

It seems that I can get it to throw an error, though. By placing probes I could see where the error is and by reading the description I could get a general concept of the error.

Try reading the help for the Read File function. You should wire something into the Count input and not into the type input.