Yair

I think I actually like the new behavior better, as I find that it makes my common usage easier. The main forums page has a link to show today's activity near the bottom, which should cover the non-common use cases. I think that link just needs to be more prominent. If you can return to the old behavior, I would prefer if this was a user setting.

The key is that you need to change the font color, not the text color. The text color property changes the color for the entire text.

You need to select the text you want to color before applying the new color. The string control has two properties for the selection start and end points. I don't remember if there's a separate property for the selected text color, but I'll leave you to work out the details.

You're kinder than I am. houtom, the issue is not passing the data, but decoding it when you have different types and I don't need a solution. Just to clarify, my concern was not really with run-time performance. I was wondering more about edit-time behavior and whether having a large number of classes in the project would be fast and reasonably easy to use.

I don't log out, but there are computers on which I'm not logged in and I sometimes did that from those computers. As I said, it's not a critical issue.

The old version kept threads you've already read in the list but removed the "new posts" icon you had next to them. The new version removes every thread you've already read (which includes your own posts, obviously) from the list since, as Michael says, it's no longer "new". I haven't decided if this is better yet, but I did already get used to it. Personally, I have no problem with it, because I always open the links in a new tab and I know where I got to. If you couple this with marking the boards as read at the end (which now hides at the bottom of the page), the list is kept clean.

Is there any way to rebuild the old links or have them redirect to the correct post? Currently we have links to threads on LAVA posted in all kinds of places which are now incorrect.

At least for me, that doesn't appear if I'm not logged in. Even if it did, that's not very obvious. A drop down is clearer. P.S. This comes together with other stuff which isn't as easy to find in the new GUI, such as the new content link or the mark all as read link.

In the old version, when you clicked the member's name in any post you got a drop-down which allowed you to either open their profile and from there get to their posts or get to their posts directly. P.S. The attachment button in the full editor is a bit problematic, as I keep wanting to push it to post. I would suggest adding an icon to it, making the Add Reply button larger and creating another copy of it above the editor, similar to what we had in the old version.

That sounds reasonable, as long as things like the list of posts or blog posts, etc. is available. I would rather not have to sign in just to be able to browse through those. This isn't a critical issue, but it wasn't needed in the old site and I sometimes used it.

When I opened the site (directly in the new content page) I saw several hundred pages. I figured that all the old content was probably marked as new and wanted to go to that forum to clear it. I accidentally clicked the LAVA 1.0 member instead of the forum and got an error page telling me I can't view member info if I'm not signed in (at which point I realized I'm not signed in). You probably want to check all the major functionality to see that it's accessible to people who are not signed in (like downloading attachments, etc.).

You can see some examples here.

'K, I guess I'm gonna have to wait. At the moment I don't have something I need which has a lot of messages, but I just wanted to check.

Consider the following issue: You want to pass messages of different types. Different messages may have parameters of different types associated with them. There are any number of ways people do this. For example: Flatten the data to a string and unflatten it on the other side based on the actual message you got (kind of similar to what the JKI state machine does). Do the same, but use a variant. Have a dynamically registered event for each message type. Then, each message is handled in a different frame of the event structures and get the specific data type it needs. Have a class for every message type, build the message as an object and send that object to the message handler. When the message handler gets a message, it dynamically dispatches to the "process message" VI. I like the last option, but I was wondering about its performance and usability. What happens if you want to have 100 message types? Do you want to have 100 classes in your project? Do you want to load the classes at run-time? Stephen, I guess this question is mainly for you and also has to do with the general performance of having many classes. What's the largest number of classes (dynamic and non-dynamic loading) you know of?

I seem to remember there was a bug around 8.0 or 8.2 in the way LabVIEW handled this, but I don't remember the specifics. If you want to work with multiple versions, you could try Dataact's version chooser. I never used it myself, so I can't comment on its functionality.

Also, how do I clear the new content list? The old version had a "mark all posts as read" link at the top of the list, but the new one does not seem to have it, meaning I'm stuck with all the NI and JKI news from the RSS feeds which I don't care about. Over time, this will pose a serious usability issue. Never mind, I saw the other thread. This should really be placed in a more prominent location, as should the new content link. P.S. I do like the in-page editor here. It appears at the END of the thread and has all the nice features.

Ah, much better. Thanks. Some points: The "View New Content" link is a bit hard to find. The items in the new content list seem to take up more room than they used to in the old version. The new content list only shows unread posts. Once you read something, it doesn't appear there anymore. This is probably not a real issue if you're aware of it (and it actually makes sense), but is different from the old version works. If you happen to want to go back to a thread by the date, you would need to open the active content link from the main page. The WYSIWYG editor is much nicer. Since you were able to import the login info, does that mean the old posts will be linked into our profiles correctly?

QUOTE (Omar Mussa @ Jun 5 2009, 06:32 AM) Yes, I forgot that I actually saw it last year. I think it's great. Incidentally, I would personally prefer having it available as a standard video on Youtube, although I seem to remember there are some issues there with video length. Maybe Vimeo? No reason you can't do both formats.

I don't have anything particular in mind, but I would agree that it would be nice if VIE brought along a camera and tripod and recorded the session (both sessions, actually) for future generations and then made it available. There are many sites for sharing video. While we're at it, it would probably be nice if the JKI presentations also did this. I've told NI people a few times that it would be nice if they did this too not just for the keynote, but there's no reason why the outside presenters shouldn't be able to do this for their presentation.

I would love to attend! Will you be presenting in Israel?

QUOTE (crelf @ Jun 1 2009, 06:21 PM) Strictly speaking, that's not scripting. It's private functionality. I haven't looked at the license NI released yet, but it definitely won't include all private properties and methods NI has. Many of them will continue to stay private. I agree with Peter that most people don't actually need scripting (defined as "code able to read, edit and create other code") most of the time. Unless you're actively working on writing a tool which will handle LabVIEW code (like JKI's RCF), you will rarely need it. I think most people are excited for one of three reasons: 1. Most people are probably excited just because of the hype. It was hidden. Then it was locked. There were many discussions. Now it's easily accessible. As people will calm down, they will understand that they don't actually need it. 2. Some people actually need it for their own tools or will now be able to use stuff based on scripting that other people release. Thus, they're happy even if there is no HUGE direct gain. This covers most of the userbase and is a very good reason to be happy. I fall into that category. 3. Others might see this as an important point in the NI-community relationship. The community pushed, NI eventually listened. This becomes another step on the road NI has been taking.

QUOTE (Phillip Brooks @ Jun 1 2009, 08:49 PM) Once JKI's RCF comes out, you should be able to easily do this (or suggest it to Jim, maybe they'll do it for you )

QUOTE (asbo @ May 28 2009, 05:37 PM) Or simply Shift+Tab. Useful when you manually change the tool and want to go back. You probably want to go over the help topic about keyboard shortcuts for the ones you don't know.

QUOTE (Minh Pham @ May 28 2009, 10:24 AM) A more interesting version of this would be if you use a LV2 style global to remember the time of the last probe and then subtract to show the difference. Just note that this will only work if you have two such probes. If you have more, you might run into race conditions. Also, using the Tick Count primitive for this is generally better because it has a higher resolution. QUOTE (Cat @ May 28 2009, 02:02 PM) I like that idea! :thumbup: So does Jim, apparently.

Sounds like a good task for JKI's right click framework - you select a block of code, choose "add timing" and it wraps it in a flat sequence with timing code.