Yair

Personally, I dislike the backwards facing SR. I guess I feel that they just look wrong. We had a discussion here and here are some alternatives I posted there. Maybe you should add your thoughts there. You should note that the local variable method does actually work (although I never actually used it) and has the advantage of providing a name so you have some documentation. NI could technically build something like this which would have a name without having an extra memory allocation and a node.

If memory serves, the DLL calls (at least the basic one) is fairly simple and there should already be example VIs available. Try searching for "QPC" or "QueryPerformanceCounter".

QUOTE (Aristos Queue @ Apr 7 2009, 08:48 AM) I also started programming at a young age, so I understand the issues. I have no problem at all with taking things apart to understand how they work. I was only expressing interest since you don't exactly get a lot of teenagers around here. QUOTE (flarn2006 @ Apr 8 2009, 01:36 AM) I'm 15 (at the time of writing) and I don't know where you got 16. I wasn't looking at your profile. Your avatar has a date and I was just wondering if that was really your birthday which would make you around 16 (and 15 or 16 is the same to me for the purposes of this discussion).

I have no idea about the history, but the issue is fairly simple - Updating a control has two parts - updating the control value and updating the actual control on screen. When you use a local, LabVIEW only does the first part and does the second part when it's ready for it. When you use the Value property, you force it to do both parts (and force a switch to the UI thread). That's why using the Value property is slower - it just does more work. That said, I wouldn't say to "never" use either of them. Each of them has its uses and its pros and cons. Deciding which to use (or if to use either of them at all) should depend on the specific case. The speed issue isn't really relevant for many cases. Nothing terrible will happen in the update takes an extra X ms.

QUOTE (Michael Aivaliotis @ Apr 6 2009, 08:21 PM) But you still have to write the code behind the template which will fit your specific use case (assuming you don't already have a suitable template) and then customize it once you start with the actual code. There is little point in doing this work if its benefits don't overweigh its disadvantages, right? I'm not saying state machines are bad. I'm just saying that there are cases where SSS are legitimate.

QUOTE (Mark Yedinak @ Apr 6 2009, 07:24 PM) Because it's easier to write and easier to read. You're not talking about "states", just a lot of code. And if I really wanted to change the order, it's much easier to do by using the rearranging dialog that the SSS has. This won't be dynamic, but I really don't need it to be. And yes, things can change, but ultimately you have to draw a line and say "here I'm actually going to do some work instead of building a framework". The location of that line obviously depends on the specific project. P.S. Some of the other options I mentioned are also perfectly valid solutions. I just happened to choose that as one which is suited. P.P.S. Having SRs on the SSS would have made life somewhat easier, so I can understand why Stephen and co. don't want to do this.

QUOTE (crelf @ Apr 5 2009, 09:12 PM) It's actually several very real applications, all sharing some similar design requirements. And yes, I do believe that in those cases the SSS was the right call even though there were other alternatives. The point is that even if a tool calls out to be abused, it doesn't make it automatically evil. It certainly is a valid argument for getting rid of it, but it doesn't mean that it's entirely useless.

QUOTE (crelf @ Apr 5 2009, 08:36 PM) Maybe. Never used it, so I can't tell. The application needs to have a custom UI and run 24/7, as well as run custom code in parallel loops and communicate with various kinds of hardware.

QUOTE (crelf @ Apr 5 2009, 08:18 PM) Your code has 10 frames (like I said, a long list of rules). Welcome to the 12,000 pixels long VI.

Here's a challenge. You have an application with a long listing of rules, that will probably not change and if they will change, will require some planning anyway. Do you: Use C, which has no stacked sequences? Write a state machine to go sequentially through many states that have be performed every single time? Create a subVI for each section of the code (with additional internal subVIs) and string them together using error clusters? Write a plugin archiecture and build the various sections as plugins? Write a special script language and parser to handle the logic? Write a framework which will handle the common parts and then build all the logic in configuration files and simply iterate over them? Use a stacked sequence which clearly shows the order of the code (remember, fixed order) and allows reasonably easy debugging for specific points in the code?

Your example is missing the translate subVI. Also, you probably want to specify the format of the file better. I haven't done something like this myself, but I would try a tab delimeted text file for each language with the following columns: Label,Class ID, Caption, Strings... The key here is that the strings section changes based on the control class, as you've shown in your example. There is also a need to decide how much you keep (e.g. do you keep the strings in trees, listboxes and combo boxes?) as that may require a more complex architecture for saving. Also, note that I suggested using the label (for a lookup). This is safer than just using the order as you did, but can still break if the user changes the control label. Then, you need to decide how to translate the captions. If you have a tab delimited text file, you can simply let the user edit it manually, but that has potential for errors. You could write a GUI for this which would basically have a listbox and a subpanel with the list of controls. Then, selecting a control loads an appropriate VI into the subpanel for editing the strings for that control. If you want, you can use LVOOP for this which would simplify some of the saving and loading issues.

QUOTE (Darren @ Apr 3 2009, 06:13 AM) My version of QD already does this (with Shift+Enter), both in the original version I posted to LAVA and in the limited release one based on the QD code. Norm, if you want to save some time, you can probably use it the way I did in the private version (as I remember, it did require some effort, so you would probably want to leverage that).

QUOTE (Aristos Queue @ Apr 1 2009, 04:20 PM) Maybe, but the OpenG/MGI method (loading elements by name) is a lot more intuitive and seems to be somewhat safer (e.g. I hate that renaming a class causes it to lose all its history. I was cleaning up code for release and decided to rename one of the UUT classes from the development name it had to the production name the customer finally decided on. Big mistake, since that meant I couldn't load old configurations anymore, because the config class had an array of UUTs. Luckily, it didn't matter in that case, so I didn't need to revert. If I was using one of the other methods, I would get default data for that and the rest would load fine). I'm guessing that the LVOOP method is faster, but in most cases I don't think that loading and saving things like this is critical.

I don't have LV in front of me, but it's fairly easy to open a reference to the control (use Open VI Ref) and recurse through all the typedefs it calls using the Callees property and then calling the Disconnect method on each of them. Make sure the control isn't open in a VI which is in a non-idle state. Also, make sure to limit the scope of which typedefs you're disconnecting (e.g. you probably don't want to disconnect vi.lib typedefs). Jim Kring had a post on his blog once about doing this and may have even uploaded some code. The better advice I can offer, however, is to use another method. Some options include LVOOP, the OpenG variant config VIs and MGI's read-write anything VIs. They allow you to open older versions, newer versions, etc. without having to write any additional code and work very well.

I would say that it highly depends. LabVIEW isn't used as diversly as C, for example, but it's used differently in different places. Some places might expect a very good knowledge of electronics or other domain specific knowledge while other places might prefer a good understanding of LabVIEW and place less emphasis on domain knowledge. You can read this recent thread for more input.

You can download LabVIEW from NI's website and run it in a fully functional evaluation mode for 30 days. If you do that and go through some of these tutorials, you should have a better idea of how it fits you. My advice would be not to try to take it all in at once. Try building a hobby project which will be related to something you know about. There are some relatively cheap hardware modules which you can use to control things with by having digital and analog I/O and this should probably fit your current skills. P.S. The fact that you capitalized LabVIEW corretly is already a good step in the right direction. :thumbup:

QUOTE (Michael Aivaliotis @ Mar 25 2009, 07:40 PM) I have no problem at all with him hacking away, but it seems to me that post was asking if someone else has already done this work (or worse, asking someone else to do it for him, if he's just a script kiddie) and I pointed out that it's relatively unlikely.

I don't have an official documentation for this, but a queue will hang onto its unused memory until it's destroyed OR until it's needed elsewhere. Calling the Request Deallocation primitive will probably also release it. In any case, I think you should regard this as an implementation detail, not something to be relied upon. P.S. A dequeue does use a pointer to the enqueued data to move the data without creating a copy. It can do this because every enqueue is will always have only one dequeue. An "exception" to this is if you split the wire before enqueuing, which will force LV to create a copy for the queue (it's not really an exception when you think about it, since you still have a pointer to the enqueued data).

Since you work for a university, you should probably not have a problem with uploading the code, right? You could also submit it to NI's site.

QUOTE (hooovahh @ Mar 23 2009, 11:03 PM) Yeah, but most 16 year olds are still in high school. I'm just wondering about his involvement. We work with a local school where we do let some of the high schoolers use proper LabVIEW (as opposed to Mindstorms which the younger kids use), but I don't think any of them is really interested in it.

QUOTE (flarn2006 @ Mar 23 2009, 09:36 PM) Most people use LabVIEW professionally and in production environments. They rarely have the time, inclination or ability to dig up stuff like this. Personally, I feel it would be a huge waste of time for me to try to reverse engineer it (even if I did know something about the original format), as there is other stuff to do and this, while nice to have, is never something that I really needed.

The format LabVIEW uses is called PICC. It's undocumented and has no public editing tool. You can use EMF to partly achieve the effect that you want, but it won't always work as you wish. You can see some example in this thread.

QUOTE (PJM_labview @ Mar 22 2009, 02:33 AM) So much for being able to claim I have the password to the VI and using that as proof. :laugh: BTW, flarn, are you really 16 years old? What's your involvement with LabVIEW?

QUOTE (shoneill @ Mar 20 2009, 01:32 PM) Technically, I'm not a proper software developer (and definitely not engineer, since I don't have a degree). At most I can be considered someone with open ears, an adaquate disposition and a reasonably good memory for certain things. I think you also qualify for that category.

LabVIEW can read the diagram of a password protected VI (e.g. it would recompile it if a typedef it calls was changed, etc.), but that doesn't mean that anyone knows how to work around that. Even if someone did, do you think they would just expose that knowledge on a public forum? I don't think that the majority of the LabVIEW community has the type of people which would take advantage of this. I think that people who stumbled onto something like this are more likely to quietly alert NI to the issue. There were various conversations about this in the past, so you could try a search, but I wouldn't count on getting an actual answer.