Display of tables

[RacingDog]

Well, I carefully crafted my app so that the 7 out of 8 small tables which could be displayed without scroll bars fitted nice and snug and did just that. That was on the PC.

Then I tried it on the dev. All 7 tables were now obliterated by scroll bars. So I went through the tedium of manually tweaking them, not just height and width, but sometimes position for the snugger fits on the form, and sometimes even column width too. As there were only 7 I just did it till they looked right and didn't bother too much about figuring the numbers.

So then I saved it all back to the PC for compiling and had a look at the effect on the PC layout.

Hmm. I have to say some of the tables are now of considerably different dimensions in the sense of the gap between the bottom and right margins of the data and the bottom and right edges of the control.

So two questions.

1) What causes these visual discrepencies? A rectangular grid of points should just be a rectangular grid of points with a fixed meaning from one view to another. Why not?

2) Is there a fixed magic formula that covers this effect?

A subsidiary curiosity, why is there no way to change row height? Someone may want a different font size one day.

Just so you can see the extent of the effect, run this app on the PC (it needs ControlsEx.dll) and select the first five tabs in turn, starting on the left. Just look at the table's borders, don't try to understand anything, that isn't the question. See what I mean?

In the unlikely event that anyone else volunteers on a two station preserved railway, or similar, and is involved in ticket sales, this is the app for you! As if anybody would be! LOL!

 

[specci48]

Hello RacingDog,

I haven't tested your attachment but I think this thread describes the same problem with a nice workaround from klaus.


specci48

 

[RacingDog]

Amusing. He spots the row height problem but leaves it out of the code, grin.

The best solution is to refer the ColCount and RowCount properties. In simple cases it gives future proofing. In the case of my table on my first tab it is necessary as the table can be 4 X 2, 4 X 3, 5 X 2 or 5 X 3 depending on the CheckBox settings. The position of the overlaid spinner also has to change!

That still doesn't answer the basic question, why is there a difference? Anyone know?

 

[RacingDog]

No, it's not that simple. It's not exactly 1 pixel per col or row. I've only just started and a table with 10 rows only requires a difference of 8!!! But a four row column seems about right. The columns are still wrong despite adjustment and I haven't figured them yet. So that's the first half of 2 of 7 that isn't simple. OK, on with the rest.

More later. Any better guesses in the meantime?

 

[RacingDog]

The first table has 4 cols, but the overall table width only needs correcting by 3!

 

[RacingDog]

But and adjustment of 5 for a 5 col table is too much, so 4, just the same as a 4 col table works. Nope this is not simple whole numbers. I'll stop boring you and get on with fiddling. The end result is going to be messy and ad hoc, but I'll extract the final if statement into the post so you can all cogitate.

 

[RacingDog]

There is the odd number which is one pixel out, but that may be just me getting the borders wrong, but the majority of the numbers suggest that it is not the cell sizes which differ but the width of the lines between as it seems to be numbers of rows or columns minus one. Any comments?

Just in case, here is the revised app....

 

[dlfallen]

Maybe this thread could be of some help.
http://www.b4x.com/forum/code-samples-tips/5132-display-data-table-control.html

 

[RacingDog]

Well not immediately, 'cos I've just finished doing it the hard way (suck it and see), but it sure as hell will be in the future, so I've taken a copy, thanks. I might add a label and text box at the bottom so that it is easy to just read off specific heights. That will make it a calculator as well as demonstrator.

Dang, that must have been tedious!

The more I think about it, the more I become convinced that the differences are due the grid lines. The main reason is that table width needs to change as well as the height despite the fact that the column widths are set by the program as is the overall width. Therefore, the only thing not being specified by the program is the width of the grid lines and so that is the only thing that can vary in an uncontrolled manner.

As line width is effectively an aesthetic decision I'm not sure I approve of a third party foisting their taste on me as we all have different tastes. I'd rather make my own mind up.

In the big boys world, grids have a row heights property. I know the compact framework has to chop out a lot compared to normal, and we can't have everything, but that seems a strange one to have left out as it requires extra code in the framework to replace a user setting which requires no calculation, which makes the CF bigger, not smaller. I suppose they were wanting to save space on having an array of row heights, but then just simplifying to one user set value would have seemed more obvious (to me at least). Oh well, never mind.

 

[RacingDog]

I added those to your lovely proggy, but I put them to the right as they were in the way at the bottom. That's what I like about RAD environments, slap on a couple of graphics, add one trivial line of code and a great deal has been achieved for b*g**r all effort.