boolean coerce to a typedef

[crossrulz]

---

@Ben wrote:

---

@crossrulz wrote:

My question is why is a single boolean a type def?  That's just another useless layer.  If you are looking for a front panel sort of thing, a normal control would do the job.

---

I can think of one reason which you can feel to free to stomp on.

As a place holder for a strict type def.

Huh?

YOu can use a strict type def to force a GUI update but not with a normal type def. So the hack goes like this;

Edit the type def on the boolean

Change its look

change it from type def to strict type def

Apply changes (since they now strict the apperence is applied to all instance)

change back to normal type def.

Save all after saving the type def.

SO you get the appearence change only when you want to apply it everywhere and you are not restricted to the rules of a strict type def.

Does any of that need translated?

Ben

---

That is one heck of a hack.  No, I don't see anything writting in Benesse.

[JW-JnJ]

---

@Ben wrote:

SO you get the appearence change only when you want to apply it everywhere and you are not restricted to the rules of a strict type def.

 

---

Ok, now I'm curious because I think I'm missing something here. What strict type def rules are prompting this hack? You already wanted to push visual changes to children controls and they now match, what does switching back to type def gain you?

(thanks in advance for the donation to my LabVIEW training)

[Ben]

---

@JW-L3CE wrote:

---

@Ben wrote:

SO you get the appearence change only when you want to apply it everywhere and you are not restricted to the rules of a strict type def.

 

---

Ok, now I'm curious because I think I'm missing something here. What strict type def rules are prompting this hack? You already wanted to push visual changes to children controls and they now match, what does switching back to type def gain you?

(thanks in advance for the donation to my LabVIEW training)

---

Strict type defs have additional restrictions on what you can do with them. I would list them here if I used the strct version often enough to have them memorized but since I rarely use the strct versions I have to encourage you to check the documentation. I only use the Strict version whn I have a GUI element I want to keep 100% consistent across all instances.

One example where this is useful is if you want to change the size of the boolean everywhere it is used but do not want you hands tied by a strict (is color in that mix?).

So the switch back gives me liberties not available with a strict..

I did introdce this as a hack to be stomped didn't I?

If there is another way of keeping a bunch of controls looking the same, I am all ears.

Take care,

Ben

[JW-JnJ]

---

Ben wrote:

One example where this is useful is if you want to change the size of the boolean everywhere it is used but do not want you hands tied by a strict (is color in that mix?).

So the switch back gives me liberties not available with a strict..

I did introdce this as a hack to be stomped didn't I?

If there is another way of keeping a bunch of controls looking the same, I am all ears.

Take care,

Ben

---

Ah-ha, that's what I was missing. I didn't realize from my first read-through of the documentation that strict stops writing to visual properties. I had assumed it only affected manual changes.

This really wasn't stomping, I didn't know how tied my hands were with a strict (don't use them much). All in the name of learning.

Thanks for the nugget.

[Ben]

---

@JW-L3CE wrote:

---

Ben wrote:

One example where this is useful is if you want to change the size of the boolean everywhere it is used but do not want you hands tied by a strict (is color in that mix?).

So the switch back gives me liberties not available with a strict..

I did introdce this as a hack to be stomped didn't I?

If there is another way of keeping a bunch of controls looking the same, I am all ears.

Take care,

Ben

---

Ah-ha, that's what I was missing. I didn't realize from my first read-through of the documentation that strict stops writing to visual properties. I had assumed it only affected manual changes.

This really wasn't stomping, I didn't know how tied my hands were with a strict (don't use them much). All in the name of learning.

Thanks for the nugget.

---

You are welcome. I was just trying to repay Jeff for his translation services earlier today.

Ben

[clint100]

As I said in an earlier post I inherited this code from someone else.  In a nut shell the Programmer ( for whatever reason) typedef'd a boolean button. ..."ABORT".  Button size???color???

So now when I use this ABORT button in a dowhile loop with another boolean button "or'd" together there is a little red dot.  After reading a few discussion grp (DG) post I was concerned that I might not always read the correct value.  I don't know if its related but some DG talked about clusters/coersion and pointers.  If I get a true or false anytime I hit the ABORT button and it happens when its suppose to then I'm...well...fat dumb and happy.  Now I'll open another can of worms.  I saw in one program the programmer used a flatten...whatever that is.  And the coersion "dot" didn't appear. Any knowledge base or help w flatten??

[johnsold · Accepted solution]

The coercion dot in the case of the typedefed button connected to an OR gate is explained this way: Because the button is a typedef, it is "more" than just a boolean, although the output works exactly like a boolean data type.  The coercion dot tells you the you have connected two different datatypes to the OR gate inputs: a standard boolean and the typedefed boolean.  Since the underlying datatypes are the same, there is no danger of the data being corrupted or misinterpretted.

This topic (coercion dots and typedefs) has been discussed in the Forums and it does not seem that there is much consensus except that when the inderlying datatypes are the same, no harm will occur.  The biggest problems occur when a datatype which requires more bytes in memory is coerced into one which requires fewer bytes.  The coercion in such cases may not preserve the value of the data.

Think of coercion dots, not as evil to always be eliminated, but as warnings to check to make sure that everything will work as you intend for it to work.

Lynn

[clint100]

Nice   thanks!

In my last post I mistakenly said the programmer used  flatten.  It was a type cast..

[johnsold]

The best way to find out about any built in function or VI in LV is to turn on the context help window while programming. When the cursor moves over any node in the diagram, the help window shows some information about that node.  In most cases it also includes a link to the detailed help files.  The detailed help file for Flatten to String is a fuul page about that function with links to the help for related functions. Start there.

I think most experienced LV programmers keep context help turned on while programming except when forced by small screen sizes to turn it off.

Lynn

[JÞB]

---

@johnsold wrote:

The best way to find out about any built in function or VI in LV is to turn on the context help window while programming. When the cursor moves over any node in the diagram, the help window shows some information about that node.  In most cases it also includes a link to the detailed help files.  The detailed help file for Flatten to String is a fuul page about that function with links to the help for related functions. Start there.

I think most experienced LV programmers keep context help turned on while programming except when forced by small screen sizes to turn it off.

Lynn

---

I do not know about anyone else but I assure you I keep the help on!  And force myself to go to the detailed help at least once a day!  Often resulting in yet another episode of saying to myself "I did not know that!"