04-10-2022 04:28 PM
I like the idea of a "Flag Icon" (which, I'm guessing, occupies the top quarter of your Custom Icon, with perhaps some other (text?) information in the remaining space to further identify it). For example, how do you distinguish one Wizard from another?
For myself, I find it much easier (and intuitive) to use 2-3 words of text than to attempt to do "art" on a 32 x 32 pixel palette.
Bob Schor
04-11-2022 10:06 AM
@Bob_Schor wrote:
I like the idea of a "Flag Icon" (which, I'm guessing, occupies the top quarter of your Custom Icon, with perhaps some other (text?) information in the remaining space to further identify it). For example, how do you distinguish one Wizard from another?
For myself, I find it much easier (and intuitive) to use 2-3 words of text than to attempt to do "art" on a 32 x 32 pixel palette.
Bob Schor
My wizards, are all on different projects, so it doesn't matter if the flags are the same. For some other libraries with similar functionality, I distinguish them with different colors, or variations of glyphs.
As for artistry in icons, the icon editor has quite a number of glyphs (sometimes I just snip a piece of a glyph). I also have a small library of glyphs. When I don't have glyph at hand for something I need, it's a simple matter to search that interweb thingy for images, pick one, then shrink it.
Here are some of my recent icons (the flag is for a DUT called a "Detection Module").
It's not difficult, if you just try.
04-11-2022 10:16 AM
@billko wrote:
@paul_cardinale wrote:
Your mistake is in using words in icons to describe VIs. I consider that a hideous practice. (But it is better that what my cow-orkers do; which it not to edit the icons at all and just use the default.)
As for a common component in a group of VIs, I don't use templates, I put the VIs in a .lvlib and then make flag icon for the library. Here are a few of my lib flags:
Test Framework
Deployer
Wizard
Upconverter
Quick Apps
Universal Dialog Box
I'm willing to wager that your opinion is in the minority (even though it is sound advice). The fact that the icon text editor seems somehow broken now has the potential to affect a lot of people.
I hope that the effect is to push people away from putting text in icons.
04-11-2022 10:50 AM
@Bob_Schor wrote:For myself, I find it much easier (and intuitive) to use 2-3 words of text than to attempt to do "art" on a 32 x 32 pixel palette.
I subscribe to, "a picture is worth a 1000 words." So I too prefer to sum up my VIs in 2-3 words instead of leaving it up to interpretation.
04-11-2022 11:14 AM
I tend to use words as well due to my audience (which is, 99% of the time, just me). I also like using words for very simple API's that would otherwise be tricky to implement in pictures. I frequently have 10-20 different very simple getters and setters that are easily labeled with "Get P Gain" or "Set I Lim" (in the context of a current limit). Though, usually I'll use the "reading glasses" instead of the word "Get" and the pencil instead of the word "Set".
It's easier than trying to come up with a bunch of pictures to describe a P gain that distinguishes it adequately from an I gain, or a current limit easily distinguished from a voltage limit. Plus, the use of this type of getter/setter is most often used in VERY specific contexts.
For more multipurpose or reuse VI's though, pictures are the way to go. It's much easier to recognize a little image than to have to read something and reinterpret it.
04-11-2022 11:28 AM
I dug into the icon generation code ages ago and one of the things I found in there was that there was a bit of code that measured the "brightness" of an area and used that to estimate what constituted a "horizontal line" and what did not.
I found that the lightest "blue" color that it considered "not dark enough to be a horizontal line" was RGB 0/50/255. The "brightness" calculation weighed green over red.
It looks like your blue is 25/0/220. I tried making an icon that was that shade and it got confused, and then when I switched to 0/50/255 with no other changes it seemed to find the active text area again. Give that a shot.
04-11-2022 02:27 PM
@Kyle97330 wrote:
I dug into the icon generation code ages ago and one of the things I found in there was that there was a bit of code that measured the "brightness" of an area and used that to estimate what constituted a "horizontal line" and what did not.
Well... that seemed to do the trick. The colors I used in my initial post were just example colors. But messing with brightness or whatever for my actual icon seemed to resolve it. You'd think the next version of LV lets you just create the actual Text Box where all the text should go. And trust us to understand that if we don't make it big enough, it's gonna look stupid.
07-20-2023 03:32 AM
Well, recently I switched from LV2019 to 2023Q3 and ran into the same issue. What I don't understand is, that the obviously working algorithm of recognizing horizontal lines was altered so that very high-contrast areas are not treated the expected way.
Since ages I use these templates and the yellow area with two color- components above 200 is not recognized as an area against a pitch black horizontal line. I don't understand that.
Is NI willing to fix that?
12-31-2024 12:23 PM
I fell down a rabbit hole investigating this issue today and found the source of the change in behavior. I'm comparing 2019 and 2024. The horizontal line search algorithm first tries to identify the bottom-most row that is no longer a "border". The rest of the logic is different methods to look for the top edge of the text area. Like Kyle said, it's looking for brightness by converting the colors to 8-bit grayscale. It calculates the average brightness of each row and checks if it is brighter than a threshold. If it is, that is the bottom edge of the non-border text region. In 2019 that threshold was 50, it's 200 in 2024. The other tricky part with this threshold is it's the average of the entire row. So if you have 2 black pixels on the sides, your selected color needs to be brighter than 215.
What that means is that icons with regions that are dimmer than the threshold, the detected horizontal lines are unexpected.
Fortunately, that means the workaround is simple. Like Bob found, you can put a brighter line at the bottom of the text region to "fake-out" the algorithm.
I've attached VIs to test this out and to pick colors that will result in the expected behavior.
12-31-2024 08:56 PM
Back in 2015, when I noticed the funky Icon that AristosQueue was using for a free-standing While Loop (think the Consumer part of a Producer/Consumer design, he used an Icon design that looked like a While Loop, with a three-line border and a stylized "arrow" in the lower right corner. Not much space "inside" to put much text or icons, but it sure suggested a terminal loop, good for illustrating the new-fangled Channel Wire concept.
I liked the idea, but wanted "more inside space", so I designed an Icon that had only a double-wide black border with the arrow in the lower right. But when I tried to use it as an Icon Template, and put text in the big open space in the middle, the text ended up squished on top of the lower line!
Some experiment (and looking at the Icon Editor code) suggested that the Editor looked at the lowest two horizontal lines of the Template, and decided "Text goes into the space between the lowest two horizontal lines". Rather than try to rewrite the Icon Editor, I changed my template to have double-thick top and side lines, and have only a single bottom line for my template. When I use this template, the Icon Editor sees a blank space that is 32 - 2 - 2 = 28 pixel wide blank space that is 32 - 2 - 1 = 29 pixels high. I add the missing horizontal line to make a double-line at the bottom, leaving me 28 x 28 pixels for text or images. I still use this template, and can easily spot the Consumer Loops in my Channel Wire-based code.
[I'd attach a picture of the template in action, but I just uninstalled all the NI software on this machine and am rebuilding it with more modern versions of LabVIEW in anticipation of Windows 11, which is not very forgiving of code developed using LabVIEW 2019 ...].
Best wishes to All for a peaceful New Year.
Bob Schor