ShaunR

It's totally safe to check at work. (just plain text, no insults)

http://translate.goo...%B8%84%E0%B8%99

Still none the wiser then...lol

The correct translation is

"Great minds discuss ideas ; Average minds discuss events ; Small minds discuss people."

No, you're not missing anything here - an array is an easy way to do this in LV. I'm just curious if the new features in LV allow it to be done neatly as a linked list, since that's how I'd do it in C. I'm building a list of chemical reactions. The list is read from a file, so I don't know in advance how large the list will need to be. Then I need to run those reactions. Sometimes the user might want to re-run a reaction before proceeding, but I'll never need to back up to a previous reaction, so a linked list is a reasonable structure. From a performance point of view there's no problem with either implementation, since the list is short and I only need to build it once when the run starts. My question is pure curiousity as to whether a LabVIEW implementation exists (or can exist) that does what I want.

Yes. There is a very easy way to do what you want. But not in the way you want to do it. Your array would be short right? (By short I'm thinking less than 2000 lines!)

Just load all lines of the file using the "ReadLinesFromFile.vi" (-1 as the lines argument will read all lines regardless of file size) or "ReadFromSpreadsheetFile.vi" (the output of this vi is already an array type and also reads all lines regardless of size) to an array and let the user index through it. If you give him a back button (decrement) then he will also be able to go backwards (never say never...users are illogical creatures) with little effort on your part.

Labview does this sort of thing much better than C/C++ since you don't have to declare array sizes before you start and arrays are self re-allocating so you don't have to manage the re-allocation (as you would have to in C). You also don't have to worry about overrunning the end of the array. GPFs are rare in LV

Should take you 2 mins (including waiting for LV to load )

KISS!

Thanks for all the comments, but I should have phrased my original question more clearly. I'm trying to learn about what can be done with recursive data structures (using a parent class as a member of a child class), without using any type of reference (DVR, queue). I'm looking for an implementation, if anyone has one, that can efficiently add items to the end of a list (without having to iterate through the entire list for each insert). The problem is that, as far as I can tell, it's not possible to keep track of both the beginning and end of the list at the same time. Adding an item to the end of the list invalidates the front, because the front can only point at the list at a specific point in time. In C I would use two pointers, one to the beginning of the list and one for the current end, and I can't see a way to duplicate that structure in LabVIEW.

I'm probably missing something huge here. But the beginning of an array is index(0) and the end is index(length-1). This is true if you add, delete or insert. The next item in the list is current index+1 and you just maintain an index to the current place in the list/array. No iteration, uses LV primitives but suffers from re-allocation penalties.

Hi Shaun

It looks like your after the “Iterator” design pattern.

(Page 257, in Design Patterns http://www.amazon.co...d/dp/0201633612).

Just google it.

E.g. http://www.cs.unb.ca...015w02/ch5d.htm

Cheers,

Mikael

I'm not after anything, except a pay rise.lol

An array is a poor replacement for a linked list. A linked list is atomic and not contiguous in memory (hence the next-node pointer refs) and therefore doesn't suffer from memory re-allocation penalties when inserting, deleting or appending. You simply allocate the node and update the appropriate next-node pointer values. (The downside to this is of course fragmented memory). The main advantage of linked lists is that the operation time for insertion, append and deletion is consistent, which is not the case when array re-allocation occurs, since the re-allocation time is variable dependent on the array size.

You can think of an array as a special (limited) case of a linked list where the list is of a fixed length and the pointer is the previous-node pointer+1. This case will perform the same as a linked list, but as soon as you insert, delete or append past the array length you will again get re-allocation penalties.

I avoid linked lists like the plague in LV since I haven't come accross an effecient way of implementing them because the whole point of labview is that you don't have to worry about pointers . Perhaps a better way might be to write a dll (API) that manipulates your list. This may yield better results although you have other overheads but at least they will be consistent.

Of course. this is only applicable if performance is the attractive quality of your linked list. If performance isn't an issue then just use a standard array and use the standard LV prototypes to insert, delete and append.

Hello,

can you please guide me how I can Append my data to a file with the date as the file name (e.g 2010-01-10.csv)?

Thanks

I've been using a parser for quite some time to create typedefs. It doesn't pars C/C++ header files since it was designed to pars excel created text files for high channel count digital and analogue IO.

The short answer is yes you can automagically create typedefs (they must not be in memory when you update them) and you don't need to use scripting.

Here is a snippet that shows updating of the typdef.

There's a very limited "skypeSDK" on the NI website HERE which will demonstrate how to interface to skype.

Hello

I wrote a program to record the output voltage from a solar panal into an Excel file continously; however this will save the data into the Excel file in one column but I want it after finishing one day, it saves the recorded data into another column or another Excel file. Please help me in this manner if possible.

< I used Create data string.vi, write characters to file.vi and multiple time delay match.vi to record the data into Excel file>

Looking forward to hearing from You,

M-H

Append your data to a file with the date as the file name (e.g 2010-01-10.csv). Then when the new day starts, a new file will be created.

Unfortunately its one I wrote for work (copyrights an' all that). But its not hard and you could probably knock up a straight forward one without bells and whistles (i.e compare vis in the project list with those in the directories) in about 1/2 an hour. Mine is quite slow, since it does a lot of checking (compares like the aforesaid and also loads up all vis and checks callers, callees, filepaths and compares duplicates etc) and gives me lists of vis on-disk but not in the project, in the project but in the wrong location, blah, blah. Oh. And I can choose to delete them

Has anybody else had trouble with the Pulse Measurements VI? See the attached VI to show that it clearly gives the wrong answer. I know I don't have a really well defined pulse, but it's not that bad. Seems like it should be able to find the rise and fall of each pulse.

Pulse measurement VI problem.vi

George

Is this more the answer your expecting?

If you don'y mind using windows API calls, you can also call "ShellExecute" which has a couple of minor advantages over systemexec.

It is now:

Touché ...lol

Ok, I caught your problem now .

We haven't found a straight solution for this problem, too. And if I remember correctly, we reported the need of getting VI menu references via VI Server mechanisms some years ago, cause we had exactly the same problem . This should be a good product suggestion for future releases of LV.

Regards,

Frank

Indeed. I also came across another problem in that the save function isn't available in the RTE. so its back to the drawing board

Or something like this:

I bet by now the OP is really sorry about posting.

Ummm. Thats not a vi though

I can work with that...

Or this?

The idea exchange is extremely new (a few months) and didn't even have time for a single version in which to implement any idea. If you'll look at the status summaries, you will see that there are some ideas are in the implementation process. These are not necessarily the most popular ideas, nor would I expect them to be. Deciding which ideas to implement should not be based only on how much users want it, but also on other considerations such as how difficult it is implement, whether it's even correct to implement, whether it will become obselete due to other features, etc.

NI had the product suggestion center before the idea exchange, and I'm sure that if they saw a good idea they didn't think of, they used it even if it wasn't already on the road map. The "black hole" nature of the PSC, however, prevents outside users from knowing how many of those ideas originated from the users. The idea exchange is considerably better (although it has its own share of serious usability issues).

As an aside, expecting your suggestion to be one of the most popular ones is a bit arrogant, for lack of a better word. I've had several good suggestions which simply didn't get that many votes (which I hope will not prevent NI from implementing them). Incidentally, there was actually someone who posted an idea along the lines of "we need better controls" without specifying and (if memory serves) didn't get that many votes. On the opposite side, Altenbach suggested flat controls (with sample images) and got the votes. As Chris said, you need to have specific suggestions for people to be able to vote on them.

Also, here are some which have already been implemented, include one which has been implemented as a direct result of the request and even released as a patch.

Well. Perhaps my comment was a bit harsh considering the newness of the site. I wasn't expecting that should I post that my suggestions being taken up though, just that I would only consider it a worthwile excercise (of effort on my behalf) if I saw a definitive criteria behind it (like the top 1, 2 or 10 are always implemented). That was the only point I was trying to make.

A different approach just to show theres more than one way to skin a cat ferret

You said that changing the background "isn't better than nothing... if you can't change the controls skin as well"

Indeed. But I didn't say there is never a valid reason not to change the background (visually impaired users is an example where you might for example). But for most applications you can change the colour and don't need images.

I'm not completely familiar with a lot of other languages, but I don't think that you can define "all". You only get access to the attributes of a control that the developer of that control exposes to you. In this case, the attributes exposed in LabVIEW are less than other languages. In other languages, you don't get absolutely everything without getting into the very low level of the control itself, in which case you might as well write your own.

I can define "All" All properties and methods that are available at design time. The big difference is that most other languages come with full source for controls so if it doesn't quite do what you want then you can modify it or expose hidden properties....unlike LV.

It'd be nice to be able to write our own Xcontrols are the poor cousin of native controls. I'd love a statusbar control with default panels for time etc.

Compare the LV1 palette with the LV 2009 palette. I'm not saying that there has been an explosion of changes in the last 20 years, but I think it's totally unfair to take the extremist view that nothing has changed. Please: credit where it's due. There's a difference between saying that not a lot has been done and insinuating that nothing has been done.

LV1 was MAC only. So it pretty much looked like Labwindows. I came in at LV2.1 (which was windows) and theres been little change since then in terms of UI but there have been huge leaps in functionality (most of) which I am thankful for.

If you've got ideas, get off your arse and suggest them over on the Ideas Exchange. And don't just say "we need newer controls" - list specific stuff that you want, and go into details of how you want it.

Perhaps if NI R&D always took the top 10 and implemented it I might. But I've seen no correlation between the Idea exchange and implementations. I'm sure they do read it, but I would imagine only those that are on the time-line are actually implemented so its probably more to do with your request just happens to coincide with a feature that was to be implemented. I hope I'm wrong though and would love to hear about requests that were taken on board. I use LV with what it has and if it doesn't have or do what I need, I use something else. And (by the way) I actually said "it would be nice" if it supported skinning.

In the NI community group 'UI interest' is a tool to replace all controls bith a specific Strict Typedef Set.

With this tool you can easily skin a complete GUI VI.

Unfortunatly the NI site is currently down, but I try to remember to add the link here.

EDIT:

Found the link (it's in the APIs group).

LabVIEW UI template Tool

Ton

Presumably that will only work at design time. Nice little tool for branding though.

So you're saying that there's never a valid reason to change the background of a FP unless you can change the appearance of all the controls and indicators?!

Don't remember saying that, but then again I've never written an app that has a bitmap background. Ours tend to be solid black. But I've written loads in other languages that do and am just aware of the pitfalls. In fact, if its visually intensive, I wouldn't do it in LV in the first place.

I think you mean that *more* control properties are exposed, not *all*, right?

Why not all? Let me decide what is appropriate for my application.

I don't want to look like I'm itching for a fight, because I'm not, but I don't seem to be able to agree with anything you've written in this thread

Nothing new there then

The controls palette underwent a pretty big change a few major versions ago - just take a look at the differences between the default and classic palettes.

I wouldn't say putting a few 3d borders was a major change. And even if you do, thats once in 20+ years and it still "looks" like LV.

Anyway, I, for one, am glad that NI's spending the time on new controls and indicators (take a look at the new graphs available in LabVIEW 2009) and not spending that time on adding skin capabilities. Sure, it's a nice to have, but it's of very little value to me.

Aha. Something we agree on. Nice to have! The new graphs I can live without and have been for ages.

So are we only considering skinning a viable exercise if it's feasible at run-time? Don't custom controls constitute skinning (or at least the capacity to)?

Well. For me yes. You can change most of the bitmaps at design time as it stands (well booleans at least). But skinning is meant to allow a user to choose a visually appealing interface so it really needs to be at run-time. As for custom controls, try changing a cluster

I don't think that's fair. Changing a background *is* close to skinning - it's a common component of skinning. Sure, it's not changing a whole theme, but it's definately better than nothing.

Actually it isn't better than nothing since you can easily end up with unreadable interfaces if you can't change the controls skin as well..

Besides, in the industries that LabVIEW is used, I think that the ability to skin is pretty limited. A nice to have maybe, but I wouldn't suggest that the LabVIEW R&D spend too much time on it.

And there was me thinking that NI was promoting LV as a "general" programming language

If you look at any other languages, skinning isn't actually a support of the language. It stems from the fact that all control properties are exposed and therfore modifyable (Think about the recent C++ poster trying to inherit from a boolean). The fact that LV R&D decide what you can and can't have access to limits this. If (for exampe) they exposed a booleans images properties (True, False, True>False, False>true) you could. LV user interface cpabilities has been pretty much unchaged since its inception. But it could be worse. Look at Labwindows....lol.

Changing a background isn't even close to skinning.

Amen

I have known about background wallpaper, although not sure at what point it was introduced. And I would add to Crelfs elegant descitipion that if you use splitters you can also have different wallpapers for each pane by right clicking on the splitters left/right pane properties.

But skninning goes way beyond that enabling choosing of control images, titlebar, borders......well anything visual thats represented by an image.

I'm staring at that trying to figure out what makes it "sarcasm"

Its more like a "I've got wind" emoticom

It'd be nice if LV supported skinning.

Speaking of which.....Anyone know what the "IsSkinned" node is for?

You went way over my head at the title