Reinatialize the arry

[spacetoon34]

Hello,

I know that i can reinatialize the array to its default values by the menu opetarte

BUT>>>

I want to reinatialize the array by clicking a button in the run mode , How Can I ???

Please help

I attached a file that explian my problem , i use labview 7.1

[Mikkel]

It's hard to know what it is you want to do by reading your post or looking at your code.

What is supposed to happen when you press the button? Should the values in the array start over from 0, or?

-Mikkel

[Michael Aivaliotis]

http://forums.lavag.org/index.php?act=attach&type=post&id=5141

[Aristos Queue]

Right click on your array control's FP terminal and select Create>>Invoke Node>>Reinitialize to Default. This will drop a node that, when executed, will reset your control to its default value.

[Michael Aivaliotis]

QUOTE(Aristos Queue @ Mar 6 2007, 07:05 PM)

Right click on your array control's FP terminal and select Create>>Invoke Node>>Reinitialize to Default. This will drop a node that, when executed, will reset your control to its default value.

Ya, I wasn't really sure what he was asking for from his question but in hindsite I would have suggested:

http://forums.lavag.org/index.php?act=attach&type=post&id=5142''>http://forums.lavag.org/index.php?act=attach&type=post&id=5142'>http://forums.lavag.org/index.php?act=attach&type=post&id=5142

In general, using the reinitialize to default node is considered bad form.

[Irene_he]

QUOTE(Michael_Aivaliotis @ Mar 7 2007, 02:04 AM)

In general, using the reinitialize to default node is considered bad form.

How much bad is using reinitialize to default node?

I just felt sometime it's hard to do things just because it may not be the best way to do. And how much differences would it make to use not the finest and most efficient way?

It's like my husband told me that garage door opener has life cycles (how many times can we open it)? It kind of puts some psycho on me that I somtimes open only half way of the garage door for saving the life cycle.

Irene

[Aristos Queue]

QUOTE(Irene_he @ Mar 7 2007, 11:09 AM)

How much bad is using reinitialize to default node?

I think using ReInit to Default is completely the correct solution for a user interface component. Using it for changing values of variables that are actually part of your program is really bad form (it means you're using variables that can be accessed outside the dataflow and all the problems therein that have been discussed to death elsewhere). As a UI component, it's very useful for a "reset to inital state", such as a Clear button for some output, or a Reset To Defaults button on an Options dialog.

My opinion.

[crelf]

QUOTE(Aristos Queue @ Mar 8 2007, 04:25 AM)

I think using ReInit to Default is completely the correct solution for a user interface component. Using it for changing values of variables that are actually part of your program is really bad form... My opinion.

I share your opinion :thumbup:

[Irene_he]

QUOTE(Aristos Queue @ Mar 7 2007, 01:25 PM)

I think using ReInit to Default is completely the correct solution for a user interface component. Using it for changing values of variables that are actually part of your program is really bad form (it means you're using variables that can be accessed outside the dataflow and all the problems therein that have been discussed to death elsewhere). As a UI component, it's very useful for a "reset to inital state", such as a Clear button for some output, or a Reset To Defaults button on an Options dialog.

My opinion.

I know losing data flow is a bad thing for programming style, that I understand. Always pull data out from a wire (a very thick wire), not from middle of nowhere I was thinking if the property node has some inefficiency by itself.

Irene

[Mikkel]

Some very simple benchmarking (for-loop with 50000 iterations, on my old T41 laptop):

1) Reset array with invoke note: 30000 ms

2) Reset array by assigning empty array constant: 44 ms

Unless I am missing something, it seems to be around 700 times slower to use the invoke note.

-Mikkel

Edit: It seems to be related to repainting. The invoke note method repaints the indicator, while the assignment does not. If I enable 'Synchronous Display' for the indicator and modify the array contents every iteration before resetting it, the array constant method takes more or less the same as the invoke note method.

[Michael Aivaliotis]

QUOTE(Aristos Queue @ Mar 7 2007, 10:25 AM)

I think using ReInit to Default is completely the correct solution for a user interface component. ... As a UI component, it's very useful for a "reset to inital state", such as a Clear button for some output, or a Reset To Defaults button on an Options dialog.

Ok, re-init to default. Putting the performance issues aside (which are also important), can you tell me what the "default" is? That's a pretty blind approach considering that anyone can right-click on the front panel and define their own "default". While writing apps for years, I've learned to always be explicit when setting values to avoid ambiguity and hair pulling.

[crelf]

QUOTE(Michael_Aivaliotis @ Mar 8 2007, 07:58 AM)

Ok, re-init to default. Putting the performance issues aside (which are also important), can you tell me what the "default" is? That's a pretty blind approach considering that anyone can right-click on the front panel and define their own "default". While writing apps for years, I've learned to always be explicit when setting values to avoid ambiguity and hair pulling.

Sure, being explicit is a good idea, but there's nothing wrong with defaults either - as long as you know what they are. User's right-lciking on FP items under and exe doesn't allow them to set a defualt for the next time the app is run, so I'm not sure what the problem is. As Aristos pointed out, setting FP items ot default programmatically is great for UI components, but that's about it. Next you'll be telling me that the "use default" option on the output tunnel of a structure is bad form...

[Jim Kring]

QUOTE(crelf @ Mar 7 2007, 06:24 PM)

Next you'll be telling me that the "use default" option on the output tunnel of a structure is bad form...

I'll beat Michael to the punch...

At JKI, we have a general policy to avoid default values on output tunnels of structures. They are just bugs waiting to happen, much like the default frames of case structures.

[crelf]

QUOTE(Jim Kring @ Mar 8 2007, 12:36 PM)

At JKI, we have a general policy to avoid default values on output tunnels of structures. They are just bugs waiting to happen, much like the default frames of case structures.

You bit more quickly than I expected

I, also, agree that, as a general policy, default tunnels aren't the best practise, but I certainly don't have a complete aversion to them. I don't have a huge problem with default frames in case structures either, as long as they are used properly - for example, in a string-based state machine (yes, there are occasions when they are a good idea - not many, but they do exist) I like to include a "Syntax Error" dialog to the user for testing. IMHO just about every function on the BD can be abused if the programmer doesn't know what they're doing, so there isn't much I think is off limits (things do exist that I won't do, but default values and default cases aren't two of them). I know that several people will disagree with me on this, and I didn't like the default tunnels when they were introduced, but I've grown to overcome my fear of new things to embrace them when it's appropriate. OOP is another great (more esoteric) example: a wonderful tool when used properly, a complete mess in the hands of those who don't know how, or sometimes more importantly, when to use it.

[Jim Kring]

QUOTE(crelf @ Mar 7 2007, 07:42 PM)

You bit more quickly than I expected

I, also, agree that, as a general policy, default tunnels aren't the best practise, but I certainly don't have a complete aversion to them. I don't have a huge problem with default frames in case structures either, as long as they are used properly - for example, in a string-based state machine (yes, there are occasions when they are a good idea - not many, but they do exist) I like to include a "Syntax Error" dialog to the user for testing. IMHO just about every function on the BD can be abused if the programmer doesn't know what they're doing, so there isn't much I think is off limits (things do exist that I won't do, but default values and default cases aren't two of them). I know that several people will disagree with me on this, and I didn't like the default tunnels when they were introduced, but I've grown to overcome my fear of new things to embrace them when it's appropriate. OOP is another great (more esoteric) example: a wonderful tool when used properly, a complete mess in the hands of those who don't know how, or sometimes more importantly, when to use it.

A string-typed Case Structure must have a default frame, so the only sensible thing to do is to make it a run-time error, since the compiler can't possibly catch this. So you win that argument... by default

[Michael Aivaliotis]

I love that we can spin a whole discussion out of "set to default".

QUOTE

there's nothing wrong with defaults either - as long as you know what they are

Well, again, that's my point. Do I have to check every front panel Item to prove to myself that it has the right value?

QUOTE

User's right-lciking on FP items under and exe doesn't allow them to set a defualt for the next time the app is run, so I'm not sure what the problem is

I wasn't referring to end users. I was referring to other programmers. They are more dangerous. End users should always be forgiven when it comes to software. It's programmers that know better, but decide deliberately to behave badly.

QUOTE

Next you'll be telling me that the "use default" option on the output tunnel of a structure is bad form...

I'm 50/50 on that one. One thing I like about it is that no-one can override what the default is by right-clicking on it or anything. The default is defined by LabVIEW and stays that way... until NI decides to "fix it".

[crelf]

QUOTE(Michael_Aivaliotis @ Mar 8 2007, 03:30 PM)

I love that we can spin a whole discussion out of "set to default".

Yeah - we're skating awfully close to being OT, but I'm lovin' it!

QUOTE(Michael_Aivaliotis @ Mar 8 2007, 03:30 PM)

Well, again, that's my point. Do I have to check every front panel Item to prove to myself that it has the right value?

I do agree - my frame of reference was different: I was thinking end user, not other programmer.

QUOTE(Michael_Aivaliotis @ Mar 8 2007, 03:30 PM)

[other programmers] are more dangerous. End users should always be forgiven when it comes to software. It's programmers that know better, but decide deliberately to behave badly.

Yes - that's true. Although I do remember an end user mashing the keyboard with his hands trying to make my software fail (I mean like repeatedly pressing 20 keys at once in a quasi-random pattern) - when I asked him what-the-hell he was doing, he said he was testing my software cause a user might do this. I explained to him that, after some system training we give to all users, I don't expect my end users to act like gorillas.

QUOTE(Michael_Aivaliotis @ Mar 8 2007, 03:30 PM)

I'm 50/50 on that one. One thing I like about it is that no-one can override what the default is by right-clicking on it or anything. The default is defined by LabVIEW and stays that way... until NI decides to "fix it".

I must admit that it took me a looong time to come around to using them - in principle I didn't like them when they came out, but I figured, after a while, they're just like any other function in LabVIEW - powerful when used properly, dagerous when not.

QUOTE(Jim Kring @ Mar 8 2007, 02:16 PM)

A string-typed Case Structure

must

have a default frame, so the only sensible thing to do is to make it a run-time error, since the compiler can't possibly catch this. So you win that argument... by default

*sigh* very punny Jim All case structures (except for enums, where there must be one case for each enum value possible, and on case only) must have cases to cover the entire input range of the selector, so one needs to be carfeul with all of them. There may not be an explicit "default" case (eg: an integer selector could have "...1", "2...5", "6...") but it's really the same thing, and needs appropriate error trappping, if appropriate.