Yair

QUOTE(Gavin Burnell @ Jun 6 2007, 01:54 AM) If the problem is indeed as you folk described it, then I would definitely go with this solution.

VIs can be opened in newer versions, but only if they were saved with their block diagrams. If that's the case, then you will have to find the original VIs with the diagrams.

As mentioned, Windows should have no problem with that rate. I did PID with the USB-6008 or 6009 at around 20 Hz, if I remember correctly.

I like these topics. :thumbup: I would also go with the blog vote. Additional topics: Objected oriented development in LV (this wouldn't be complete without getting >=8.2 and working with the LabVOOP as well as traditional GOOP. The whole process of designing, building and testing a real-world application.

Your description is quite unclear. Can you post an example of the code you are using so that we can understand what you're actually doing? It's quite possible that there is an existing solution to your problem. Also, it would be nice if you could explain some more.

"better" is a highly relative term. You seem to be concerned about speed, so you would probably be better off with the second method, because with the first one each call would lock the VI and prevent concurrent access, but that highly depends on specific circumstances. The code you have here is actually the basis for two options - an action engine and an ad-hoc object-oriented system. In an OOP system, you would have the basic OOP infrastructure managing the instances and the locking and your code would manage the different functions (for example, you would have an "Open" function which would return a reference, a "Write" function and a read and write function for most properties). This creates a lot of overhead in the number of VIs that you will have and is usually slower, but it has it advantages the more complex your system gets. You can search for GOOP to learn about the different flavors of OOP in LabVIEW. P.S. It's a minor point, but you can set the case structure to ignore the casing of strings.

QUOTE(Michael_Aivaliotis @ Jun 4 2007, 07:35 AM) Yes, thank you.

Now it doesn't work.

Re: the interface - my experience was with smaller displays (15" which have an embedded, relatively weak PC), but it might help you. The point about the weak PC is important, because when it was time to run one of our applications (with some additional CPU-thirsty software), we found out that the processor was at 100% all the time and the application was a bit sluggish. As Dave said, make things larger. Pay special attention to enlarging controls vertically because that's the direction people tend to miss. Space things out. People tend not to be exact. Be sparse. The UI for a touch screen should be much less crowded than a standard one. Avoid tabs as they don't look that great for these kinds of applications. I prefer a cluster of buttons which you compare with its old value using a value change event and use that to switch pages in the tab control. You need property nodes to lock out the controls which can not be clicked (like the currently selected page) and you need to reset the cluster so that only one button is pressed. Definitely run your program in full-screen. You wouldn't normally want your users to interact with the OS. If you need a keyboard, you can open the Windows one by calling OSK.exe, but its buttons are relatively small and can't be modified. All of these may vary depending on the application and the type of the screen, but they've helped me.

It's actually back to working fine for me. Which browser do you use?

What is a popup menu? If you are refering to right-click context-sensitive menu, there have been several implementations posted both to the LAVA forums and to the NI forums which allow nested right click context menus., so I suggest you search for them. Some use OS calls and some do it fully in LV. What would probably be even better is using the built-in right click menus available in 8.x by right clicking a control and selecting Advanced. These can be read with the event structure.

QUOTE(Aristos Queue @ May 31 2007, 07:16 PM) :thumbup: This will probably puzzle quite a few people.

No. Not yet.

QUOTE(alfa @ May 30 2007, 10:08 AM) So, looking at it from either way, we shouldn't buy Honeywell stuff?

QUOTE(Gary Rubin @ May 30 2007, 02:01 PM) Same here. IE 6.1.

Michael, the problem described in this thread is happening again.

I don't know, I always prefered "Take this plane to Lutton!". :laugh: (or should it be "Take this bus to Cuba?).

One of the NI guys posted a series of VIs to interact with the wiimote at the NI forums. Now, if only I had one... Maybe an award for a LAVA challenge?

http://forums.lavag.org/index.php?act=attach&type=post&id=5946 Are you trying to hint something?

It does seem faster, yes. Thank you. :thumbup:

QUOTE(robijn @ May 23 2007, 07:09 PM) :laugh: QUOTE(robijn @ May 23 2007, 07:09 PM) So there's a book and when you add Freud to the query: http://www.google.com/search?q=%22I+AM+CRE...+GOD%22%20freud you'll see this books mentions Freud. AAAAAAAAAH! 13 pages???

QUOTE(Michael_Aivaliotis @ May 22 2007, 07:50 AM) What, you mean alfa's posts are not an expermintal form of a CAPTCHA?

The problem with that method is that you're relying on a control and on workarounds. A better approach is to convert the various string elements to numbers, build them into a time rec cluster and convert that cluster to a timestamp, so that you preserve data flow. There have been some implementations for this posted to the web. With the addition mentioned here of using Scan From String, it should probably be simpler.

QUOTE(Darren @ May 18 2007, 01:49 AM) Isn't the definition of an engineer "someone who doesn't read the instructions"? :headbang: http://forums.lavag.org/index.php?act=attach&type=post&id=5899''>http://forums.lavag.org/index.php?act=attach&type=post&id=5899'>http://forums.lavag.org/index.php?act=attach&type=post&id=5899

Well, that's unfortunate news (for us) . Good luck :thumbup: . QUOTE(JasonKing @ May 17 2007, 06:44 PM) It probably isn't, but you can basically use any visual IDE to do touch screen UIs if those touch screens run Windows XP. I've done those several times using LV. I haven't had any experience with the touch screen module, but if its UI is as bad as the PDA module's UI used to be, I would agree that it is not the tool (plus C and Java probably support more platforms).