Problem deleting an indicator ....

[marc france]

Thanks to all of you for answering so quickly... I got rid of it too by changing it to constant.

GerdW, thanks for ur advises ! I have 2 questions (just if you have time.. the "urgent" pb is solved now) : 

- Concerning the local variable in the loop you specified, there are 2 useless ones. However to stop all my loops I need the "STOP" one. Were you telling me I could just put the control icon in the small loop without wiring it to anything?

- Concerning the " equal " sign I shouldn't use, in this specific situation : I should use a greater or a less comparator, is that right?

Thanks again,

Marc 

[marc france]

Hi Ben,

I am sorry, but I don't know how this happened, but I have also already experienced it ...     Could it be a" rest" of deleted "grouped" icons?

Marc 

[GerdW]

Hi Marc,

concerning the equal sign:
In your vi you can force the input of the while loop back to U32 right after the divide operation (or use a quotient&remainder instead). Then you can use 'equal' again.
When testing floatingpoints you should use '>=' or '<=' when possible (or your own checking like 'equal ± epsilon').

Concerning the stop button:
Dataflow programming: LabView checks the state of the button whenever a terminal/local variable is read!
Whenever the 'stop' local is read LabView checks the actual state of the button! So you don't need to copy the value from the terminal to the local...

[Norbert_B]

Ben (and all others 🙂 ),

the issue is created because the position of your element on the frontpanel AND the blockdiagram is outside of the presentable area (range from -32768 to 32767 for Left and Top).
You can easily check that with the navigation window (Ctrl+Shift+N). It will show you nothing on FP and BD. Furthermore, you will not see any scrollbars on either of them.
Now rightclick on the indicator and disable the Label. Immediatly, you will see the whole BD on the navigation window as well as the scrollbars. FP does not change.
Same happens to FP if you use VI server to reposition the control. But since the appropriate element in the BD is still in a wrong position, you wont see the element in the FP.
Why this things occur, i do not know (maybe corruption during a save?).

Marc,

nevertheless, removing the element should be sufficient for a working vi. On the other hand, a rework of the VI like Gerd suggested could increase performance as well, so this is a valid suggestion.

Norbert B.
NI Germany

Message Edited by Norbert B on 01-04-2007 09:06 AM

[johnsold]

I wonder if the indicator (or the label) got moved outside the limits on the size of the panel? I seem to recall that it is possible to do so. The Position property node is a cluster of I32 but the limit on panel size (possibly an OS or video limit) is smaller than the maximum values that can be represented by an I32. I copied the indicator to a blank VI and read the Position property: Left = 433, Top = -32768. The sliders on the scrollbars disappear. Place a few controls/indicators on a panel. Use Position property nodes to move them to positions more than 32000+ pixels apart and watch the scrollbar sliders disappear.

Lynn

[Ben]

Norbert,

Try doing a ctrl-h and float over the icon.

NO INFO!

This ain't right.

Ben

[Norbert_B]

Ben,

i am not too sure how this issue is really created, but attached you can find a small vi showing some interesting issues with these boundaries.
Changing the coordinates will "replace" the Return-Button. Pressing it (the button) enables you to get back to the settings. So you can jump around quite decently 🙂
Well, if you get near the named boundaries, the button will get deformed and WILL NOT get back to its old shape even if it is returned somewhere within the boundaries.
Now, i asume the same happened somehow to (at least) the label of the element or the element itself in the BD. But do not forget, this is only an asumption from my side!
Nevertheless, most likely the issue occurred because of a memory corruption or saving mistake......

Things which point out an issue like i asume is e.g. the height of the label on the FP: it is 0!

Norbert B.

Message Edited by Norbert B on 01-04-2007 10:20 AM

[Ben]

"Nevertheless, most likely the issue occurred because of a memory corruption or saving mistake......"

So this warrents a CAR does it not?

Ben

[Norbert_B]

---

@Ben wrote:

So this warrents a CAR does it not?

Ben

---

Well, this is true if we can somehow make sure that the error was produced by LV itself. And this "proof" could be done if we can reproduce the course of events leading to this rather odd issue. Another reason to file CAR could be that more than one person is seeing exact the same issue with different VIs (e.g. created by incompatibilities of LV with some other SW/HW). Since both things are not given here (at least in my point of view), filing a CAR doesnt make sense (sorry).
The major problem is that corruption of files could occur nearly "everywhere". Since files are streams of bits (like they are viewed nowadays in many ADEs and OS), a change/addition/deletion of only some bits can lead to strange behaviour at least up to unreadable files (bits could not be asociated anymore).
Remember that this is just a guess from my side in this matter. I wanted to point out that i know "similar" issues caused by the "boundary-fact" (alas, the element is still deletable everytime....). The boundaries are known and, as far as i know, "working as intended".

Norbert