Display of Data in a Table Control

[dlfallen]

I like to display data in a table - without scrollbars for a clean display. I want to set the table height to display all the rows without a scroll bar and without excess space at the bottom (between the last row and the bottom of the table control).

The problem is that both the header height and the row height varies according to font size and varies from IDE to QVGA to VGA devices. For example, with a font size of 9 the header heights are 24 (IDE), 21 (QVGA), or 22 (VGA). The Row heights are 18 (IDE), 19 (QVGA), or 19.5 (VGA).

It was a bit tedious, but I figured out the header and row heights for font sizes of 6, 7, 8, 9, 10, 11, and 12 for all three platforms (IDE, QVGA, and VGA). Given these values, if H is the header size for a given font, and R is the row size for that font, the optimum table height can be calculated as
Table1.Height = H + Int(Table1.RowCount * R)

The attached program provides the 36 values, and illustrates how the table height can be kept optimum when adding or subtracting rows, or when changing font sizes. Compile with autoscale for use on VGA devices.

Or am I the only one this fussy?

[Simontelescopium]

Thanks do you know the parameters for a wide screen device? 480x800 (or 240 x 400)?
Simon.

[RacingDog]

You ain't going to like this....

I was just trying things out and found everything was ok on my laptop as per your proggy. But neither of my two types of QVGA device displayed properly!

I added a cursor line for an imaginary vertical ruler to your sample proggy. And now I'm seriously baffled. I thought it might be to do with pixel/point conversions, but that doesn't fit the figures I got by measuring things Look at lines 24-26 of my version of the proggy.

There are a number of fixed things. On the device there are two lines of pixels for both top and bottom borders. But the horizontal grid lines aren't real! They are the bottom line of the row in a different colour! So the bottom row of the table appears to be one pixel taller than the other rows. On the devices the borders are one row of pixels.

The height of the heading, ignoring borders, is sometimes the same as other rows (and why not, the font is the same size in both), but for some font sizes the heading row is smaller, and for others greater! For heavens sake manufactures and/or Microsoft, give us a chance!

The last sentence applies equally well to the actual figures I found, see proggy. How are we supposed to predict these? How can you write generic code when the variations are apparently so random? And just to rub salt into the wound, these odd row heights bear no resemblence to the font size, the text for various of the smaller sizes display perfectly well, but in row heights which also work for larger font sizes, i.e. no correspondence whatsoever.

As I said, I've only got QVGA devices, so I haven't been able to check for any variations in VGA devices, perhaps someone else could do that?

I did wonder if it had anything to do with 2D/3D representation of controls, but probably not. 3D works perfectly well with that form size on the desktop, so why does the device default to 2D? I vaguely remember Windows has a setting for this somewhere, but as I never used it, I can't remember where. Is there a similar setting on the device?

Regards, confused of Fleet!

Comments from anyone welcome.

[dlfallen]

I'm not sure I follow you exactly. My original program works just fine on two different pieces of hardware and in the emulator (all modes). Your program does not work in the emulator but that's because you changed the values for TSrow(). I'm not sure why you did this. If I change your TSrow() back to my original values, then your program works just fine (in the emulator).

[RacingDog]

I am not using the emulator, I am using real devices, they do not work with your original QVGA values. I'm sorry but I thought that was obvious. An emulator is only as reliable as the real devices it claims to emulate. It clearly does not correspond to an XDA Stellar nor a Dell Axim 51 otherwise the values it gave you would work on those devices. These are not exactly rare devices. If it is relevant, the Dell is WM5 and the XDA is WM6. Both have .NET CF 2 and 3.5.

The really annoying part is that each device varies in different ways. Argh!

Is it really true that out of all the devices out there, I should have accidently acquired the only two that have variations? The chances of that happening are pretty remote, but not totally impossible.

So the question is, does anybody out there understand what causes these variations? (Which only seem to affect font sizes 6,7,8).

It also means that, thoughtful as MS have been to provide an emulator, if real devices do something different then it is giving a misleading impression of correctness. (Did I just say something nice about MS? I must be cracking up )

I haven't got the emulator, so I can't compare notes on that.

Anybody know anything about the 3D controls question?