Yair

The good thing is that I don't need to choose a version - I have the Hebrew version, and there's only one. Also, since the idea is basically just to convey the major plot points, as presented in the text, that's not something I would be worried about. The main concern for me is that doing this properly would take time. I might try writing a few posts in advance just to see if I have the resolve. The good thing is that coming up with the content is very easy and that there's enough content to last a while.

Well, you did basically ask me to do it and since I didn't know those verses, I even had to look it up. Your post actually gave me an idea - a blog which would basically be a recap of all the interesting stories in the bible in bite-size pieces. This should probably be cool, because I'm guessing most people either don't know the stories or remember only twisted/partial versions of them. My inspiration for this was this blog, but I was thinking of only doing the interesting stories and of making the posts much shorter (and also of not giving any commentary).

I know of no specific slowdowns. Also, I'm guessing some of the performance issues will be mitigated in future versions. Your understanding wasn't wrong. Just consider it a bug.

LV 2009 has had some significant changes made under the hood. I don't know the specific details, but my understanding was that it could cause decreased performance in some cases and that NI is expecting this to improve in future versions.

One point to make is that at least the online exam has some questions which are not just tricky, but misleading or even wrong. I've never done the actual exam, but my understanding is that you should expect the same level of questions and that NI is aware of this issue.

I believe you can only edit the text if you have more than 1000 posts. That should give you a new goal after beating SM to 10K.

No, I'm fairly sure the absolute path is kept in the VI. My reference to the project was because I remembered something (probably from Brian Tyler's blog) about the project serving as the appDomain and something else (which may not even be correct, since I'm not a .NET programmer, so it's possible I even made it up) about how the appDomain holds the references to non-GAC assemblies. That said, I didn't originally read the original question thoroughly, so here are some options: Make sure they're registered in the GAC instead of being all over the place. Use a typedef for the .NET reference (you might wish to do that anyway, since I seem remember problems from LV 7.0 where a DLL was upgraded and the reference broke, but that may have been COM). This probably won't help if I understand the problem correctly. Do a search. I seem to remember someone complaining in the NI forums about LabVIEW asking for similar saves in 8.5 or 8.6.

.NET assemblies can be used in one of two ways: They can be registered in the GAC, in which case you don't need to know exactly where they are, or They can be pointed to directly (by the appDomain, if memory serves, which in LabVIEW I believe is the project). You can do this using the browse button in the dialog.

It's certainly impressive from a technical standpoint Although I personally feel that the tabs do make sense for the IE (you go through the tabs in order) and I'm not generally a fan of how palettes work in graphics software, I do feel that the modifications you made do kind of work in the IE as well. They certainly don't seem to get in the way of accomplishing the task. The cusomizing options are a good thing.

I suggest you do neither. Read Alfa's book instead.

Did you try searching NI's site? I'm pretty sure the main LabVIEW product page would have a link for trying LabVIEW which would quickly lead you to a download. Granted, this might point to LV 2009, but you could probably find 8.6 in the same folder in the FTP server.

There are the callbacks you have when LabVIEW does certain operations (e.g. opening), which might also apply when opening a reference using VI server, but those are VIs located in a specific location in the LabVIEW folder, not the actual VI you open. Also, I'm not sure, but I think XControls also call their init ability not just when dropped, but when first loaded. If the VI loads the FP (e.g. if it has property nodes), it might call this init ability as well, but I'm not sure. This would presumably appear in the documentation and a simple test can also give the answer. Regardless, as I've already mentioned in the emails, I don't think this is a project worth spending time on, but it is your time to spend as you wish.

So you basically want the X scale to have a label (the pressure) for each point. I believe this isn't supported, but I think some of the VIs in the graphics palette allow you to build this kind of graph. I think there's an example either in the example finder or somewhere in the NI forums. Alternatively, you can try displaying some annotations on the graph. You can give them whatever text you want and use code to place them where you want.

Sequence=time. Basically, you have a problem, because you want the X scale to represent both time (sequence) and pressure. It doesn't make sense to me. How would you expect such a graph to look? You could do it as a bar graph or an intensity graph or something like that, but you need to know how you want it to look. Now I also understand better your comment about the scale marker labels. If I understand correctly, you want X to be time and Y to be deflection, but you want to show a pressure for each data point.

So what you want is basically a 3D graph - deflection over pressure over time, right?

I'm not sure what you mean by "duplicate X values", but if you don't want the line to go "back", just sort the data by the X array before putting it into the graph.

If you think it's worth spending time on, you can post an idea to NI's idea exchange and let people vote on it. Personally, I don't feel it's worth the time.

It means that most of the VIs shipping with the IE are not password protected. I don't know if 99.9% is an accurate number, but it probably drives the point through better than 97.7%.

I specifically asked about this issue during the beta and was told that the updates are done asynchronously, so they shouldn't slow down the load time. That said, I don't find them useful, so I disabled them as well. One thing which does slow me down quite a bit is the JKI RCF, which is set to auto-start with LabVIEW. If memory serves, it takes 100+ MBs of RAM and takes a while to load.

Not sure what you're refering to, Shaun. The parts of the LabVIEW environment which are written in LabVIEW are getting bigger, not smaller. Specifically, the config VIs are still written fully in LabVIEW and the code is open source. What James was complaining about, and what the other thread refers to, is that this code is marked as private, so your VI can't use it directly if it's not a member of the same library. The other thread goes into some detail about why this is so.

No. The WASD keys, surprisingly enough, are reserved for typing W, A, S and D. I can think of four options: Use an external keyboard mapper. The problem - it will be global, which is probably not what you want. Stop using tab. Switch to the auto-tool. Some people (like me) like it. Others hate it. The recommendation is to force yourself to try to use it for at least a week before giving up. There have been several threads about the various advantages and disadvantages both here and in the NI forums. Get an external keypad. I doubt this would help you, since you would probably place it on the left side of the keyboard, when you want the keys on the right side of the tab key. Use a key mapper and map one of the keys near the keypad (e.g. num lock) to the tab key. That way, you can keep your hand on the right side, but you won't have easy access to Ctrl, Shift, etc.

This may have been the same in 8.6.1, but it definitely wasn't there in 8.6. I'm surprised no one caught this in the 9 beta. This is the sort of bug I would have been vocal about had I found it in the beta (which goes to show you how much time I had to actually test the beta).

Or, if the shot you want is of your LabVIEW code, the Code Capture Tool.

Make the data type of your notifier LabVIEW Object. That's the constant you can find in the palette and is the common ancestor of all the other classes. You can now wire ANY class into that input, so you don't need to write these VIs more than once. Note - I didn't read the rest of the thread, but I'm assuming each class (data type) will also need an overriding VI which will handle the actual data and might need a constructor.

There's an annoying bug in 2009 where the dialog does not bring the VI you choose to the front. There is a solution here: http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=435591#M435591