LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

table issues : row height <-> table height

Solved!
Go to solution

Hello,

 

1) I am setting the height of a table using the attribute ATTR_NUM_VISIBLE_ROWS. A typical result is shown in the attached image

 

tableheight.jpg

 

As can be seen, there is an extra height between the lowest row and the table frame, or, phrased differently, there is the visual appearance of a double line. In my opinion, this appearance is inconsistent (there are no left or right double lines...) and should be changed: draw no lower line for the lowest row and accordingly reduce the table height.

 

Or is there a possibility to avoid this behavior?

 

2) Another optical bug: the lower line of rows and row labels is drawn inconsistently, too, see the figure from the NI sample gridview:

 

table.jpg

 

As one can see the black line of the rows is below the gray lines of the row labels

 

Thanks, Wolfgang

0 Kudos
Message 1 of 11
(4,796 Views)

I have to partially correct myself: there is a right double line; the last column also shows a right line in addition to the table border.

 

Still I think that this double line is faulty (at least in my case it is undesired).

 

Let's assume a table with seven columns, each using explicit sizes; I sum up these numbers and add 6 pixels for the (7-1) vertical column separator lines; setting the table to this width still shows a double line although there should be no space left for the rightmost column separator... So one of my column widths is not honored... If I reduce table width by say two more pixels trying to get rid of the double border, the first column is cannibalized not showing its full context anymore.

0 Kudos
Message 2 of 11
(4,789 Views)

I also observed that double line on the table border, but based on my observations I tend to think that the column/row border line actually is included in column width / row height; in effect when autosizing the table and then hiding cell borders table dimensions do not change even if you try to autosize the table again.

It's true that that double line may be misleading: I don't like it too so I usually hide it at least when using tables with a fixed number of rows/columns.



Proud to use LW/CVI from 3.1 on.

My contributions to the Developer Community
________________________________________
If I have helped you, why not giving me a kudos?
0 Kudos
Message 3 of 11
(4,786 Views)

Wolfgang - FYI, the second issue is a known issue.  I'm surprised your careful eye didn't notice it 😉

 

NickB

National Instruments

0 Kudos
Message 4 of 11
(4,771 Views)

Hi Nick,

 

this was because my eyes were distracted by the double lines Smiley Very Happy Actually I was one of the guys reporting this issue... but formerly I only noticed the vertical mismatch.

 

So are you going to fix the first issue, too? 

0 Kudos
Message 5 of 11
(4,763 Views)
Solution
Accepted by Wolfgang

Yup - we'll fix the first issue as well.  I've reported it with bug ID 310781.

 

NickB

National Instruments

0 Kudos
Message 6 of 11
(4,749 Views)

Thanks!

0 Kudos
Message 7 of 11
(4,747 Views)

Hi guys,

 

I've looked into the double-line issue and this isn't really a bug, after all. That gap isn't really a gap. The table has a 3-pixel frame around its entire perimeter. In order to create a 3d effect for this frame, most frame styles make the topmost pixel of all its segments (leftmost for the vertical segments) lighter than the other pixels, in order to simulate a light source above and to the left of the control. This depends on the frame style that you're actually using, of course (Win7 theme, XP theme, lab-style or classic), but this is generally the case for most styles. The "gap" is really the visual effect of seeing this light-colored pixel between the last cell's grid line and the other, darker pixels of the frame below it.


If you paint the table background of a different color from bottom row of cells (or rightmost column of cells) you'll notice that no portion of this cell grid area is really visible when you size the table to an exact number of rows or columns (pic2.png). You'll then see the cell grid background becoming visible if you gradually increase the table size one pixel at a time (pic1.png)

One thing you can do for now, if you really want to avoid this effect, is to change the frame style by disabling windows theming for the control, and allow the lab-style frame to be drawn, which doesn't have this effect. Going forward, I'm adding the ability to hide the table frame (ATTR_FRAME_VISIBLE) , so that you can see just the flat grid, if that's what you prefer.

 

Luis

Download All
0 Kudos
Message 8 of 11
(4,680 Views)

Hi Luis,

 

thanks for coming back... I might agree with you that this is a 3D framing effect. It would be OK to optionally turn this effect off to have a symmetric table appearance. As you can see in your edited example, the top and left table frame lines have an adjacent one-pixel wide white line that covers the respective cell lines, while the right and lower table frame lines also have a white line; this however does not cover the cell lines. In result, not all cell lines are plotted/treated equally...

 

I admit that the effect is more important when viewed with a magnifier Smiley Wink

 

pic2_mod.png

 

 

I wish you a Happy New Year,

 

Wolfgang

 

 

0 Kudos
Message 9 of 11
(4,666 Views)

Are you saying that your green & white line covers the table cells, whereas the red & white line does not? I don't see either the green or the red lines covering the table cells.

 

I'm attaching another picture (with two different frame styles) that shows the single-pixel white outline around the entire table, but no portion of it should cover up any of the cell area.

 

Luis

Download All
0 Kudos
Message 10 of 11
(4,650 Views)