Skip to main content

[Migrated content. Thread originally posted on 10 April 2006]

Is there an internal value where the maximum NUM-ROWS of a paged grid can be acquired when the form is resized, keeping in mind that the grid can have HSCROLL TRUE/FALSE ?

I have the following situation :

A grid has the following attributes in design time : LINES 44,00 - NUM-ROWS 22.
When the form resizes, I calculate the actual quantity of records to be filled as follow : COMPUTE NUM-RECORDS ROUNDED = (GRID-LINES / 2) - 1.

In most cases, this works fine, but others it doesn't.
My laptop has a resolution of 1440 by 900 pixels.
When the form resizes, inquiring the grid in debug, it has 73,00 lines. The grid first shows like in design-time, but then the form resizes automaticly and NUM-RECORDS becomes 36 => (73 / 2) - 1

Instead of 36, the grid shows 35 records to fill... so the logic of filling the grid isn't correct anymore.

Any ideas ?

[Migrated content. Thread originally posted on 10 April 2006]

Is there an internal value where the maximum NUM-ROWS of a paged grid can be acquired when the form is resized, keeping in mind that the grid can have HSCROLL TRUE/FALSE ?

I have the following situation :

A grid has the following attributes in design time : LINES 44,00 - NUM-ROWS 22.
When the form resizes, I calculate the actual quantity of records to be filled as follow : COMPUTE NUM-RECORDS ROUNDED = (GRID-LINES / 2) - 1.

In most cases, this works fine, but others it doesn't.
My laptop has a resolution of 1440 by 900 pixels.
When the form resizes, inquiring the grid in debug, it has 73,00 lines. The grid first shows like in design-time, but then the form resizes automaticly and NUM-RECORDS becomes 36 => (73 / 2) - 1

Instead of 36, the grid shows 35 records to fill... so the logic of filling the grid isn't correct anymore.

Any ideas ?
This is probably because of the DPI of your display. Check your display properties, Settings tab, Advanced button, general tab. What is the DPI of your display, I bet it is 120...

What to do about it... Well, apparently there is room for more?

[Migrated content. Thread originally posted on 10 April 2006]

Is there an internal value where the maximum NUM-ROWS of a paged grid can be acquired when the form is resized, keeping in mind that the grid can have HSCROLL TRUE/FALSE ?

I have the following situation :

A grid has the following attributes in design time : LINES 44,00 - NUM-ROWS 22.
When the form resizes, I calculate the actual quantity of records to be filled as follow : COMPUTE NUM-RECORDS ROUNDED = (GRID-LINES / 2) - 1.

In most cases, this works fine, but others it doesn't.
My laptop has a resolution of 1440 by 900 pixels.
When the form resizes, inquiring the grid in debug, it has 73,00 lines. The grid first shows like in design-time, but then the form resizes automaticly and NUM-RECORDS becomes 36 => (73 / 2) - 1

Instead of 36, the grid shows 35 records to fill... so the logic of filling the grid isn't correct anymore.

Any ideas ?
DPI = 96

[Migrated content. Thread originally posted on 10 April 2006]

Is there an internal value where the maximum NUM-ROWS of a paged grid can be acquired when the form is resized, keeping in mind that the grid can have HSCROLL TRUE/FALSE ?

I have the following situation :

A grid has the following attributes in design time : LINES 44,00 - NUM-ROWS 22.
When the form resizes, I calculate the actual quantity of records to be filled as follow : COMPUTE NUM-RECORDS ROUNDED = (GRID-LINES / 2) - 1.

In most cases, this works fine, but others it doesn't.
My laptop has a resolution of 1440 by 900 pixels.
When the form resizes, inquiring the grid in debug, it has 73,00 lines. The grid first shows like in design-time, but then the form resizes automaticly and NUM-RECORDS becomes 36 => (73 / 2) - 1

Instead of 36, the grid shows 35 records to fill... so the logic of filling the grid isn't correct anymore.

Any ideas ?
Ok, that is the normal one. Then it is probably not the cause. Beats me.

[Migrated content. Thread originally posted on 10 April 2006]

Is there an internal value where the maximum NUM-ROWS of a paged grid can be acquired when the form is resized, keeping in mind that the grid can have HSCROLL TRUE/FALSE ?

I have the following situation :

A grid has the following attributes in design time : LINES 44,00 - NUM-ROWS 22.
When the form resizes, I calculate the actual quantity of records to be filled as follow : COMPUTE NUM-RECORDS ROUNDED = (GRID-LINES / 2) - 1.

In most cases, this works fine, but others it doesn't.
My laptop has a resolution of 1440 by 900 pixels.
When the form resizes, inquiring the grid in debug, it has 73,00 lines. The grid first shows like in design-time, but then the form resizes automaticly and NUM-RECORDS becomes 36 => (73 / 2) - 1

Instead of 36, the grid shows 35 records to fill... so the logic of filling the grid isn't correct anymore.

Any ideas ?
This is the answer of tech. support :
?I think we can call this expected behaviour. The point is that the number of lines needs to change when the font size changes. If you change the number of lines to correspond to the size of the font, then everything works well again.

This is one of those borderline cases, where it is really unclear what is supposed to happen. The specification (such as it is) never really talks about this case. So the best thing to do is to change the num-rows at the time you are changing the font.?

But I test the software on different resolutions on my laptop without changing the font, so I don't know what to do.

[Migrated content. Thread originally posted on 10 April 2006]

Is there an internal value where the maximum NUM-ROWS of a paged grid can be acquired when the form is resized, keeping in mind that the grid can have HSCROLL TRUE/FALSE ?

I have the following situation :

A grid has the following attributes in design time : LINES 44,00 - NUM-ROWS 22.
When the form resizes, I calculate the actual quantity of records to be filled as follow : COMPUTE NUM-RECORDS ROUNDED = (GRID-LINES / 2) - 1.

In most cases, this works fine, but others it doesn't.
My laptop has a resolution of 1440 by 900 pixels.
When the form resizes, inquiring the grid in debug, it has 73,00 lines. The grid first shows like in design-time, but then the form resizes automaticly and NUM-RECORDS becomes 36 => (73 / 2) - 1

Instead of 36, the grid shows 35 records to fill... so the logic of filling the grid isn't correct anymore.

Any ideas ?
Tech support is right.

However,

if you change the resolution, the relative pixel (device dependent size) with also changes, so, albeit you are consistently using 12 as the font size in your app. the physical character displayed will usually require a different number of pixels.

You may want to execute w$textsize under the various resolutions, watch the different values in TEXTSIZE-BASE-Y and use those as an indicator for the number of lines.

[Migrated content. Thread originally posted on 10 April 2006]

Is there an internal value where the maximum NUM-ROWS of a paged grid can be acquired when the form is resized, keeping in mind that the grid can have HSCROLL TRUE/FALSE ?

I have the following situation :

A grid has the following attributes in design time : LINES 44,00 - NUM-ROWS 22.
When the form resizes, I calculate the actual quantity of records to be filled as follow : COMPUTE NUM-RECORDS ROUNDED = (GRID-LINES / 2) - 1.

In most cases, this works fine, but others it doesn't.
My laptop has a resolution of 1440 by 900 pixels.
When the form resizes, inquiring the grid in debug, it has 73,00 lines. The grid first shows like in design-time, but then the form resizes automaticly and NUM-RECORDS becomes 36 => (73 / 2) - 1

Instead of 36, the grid shows 35 records to fill... so the logic of filling the grid isn't correct anymore.

Any ideas ?
Thanks for the info, Ghisle, but on both computers, TEXTSIZE-BASE-Y = 13.

So I tested the software on my laptop at the same resolution with 2 conditions :

1. At initial state : everything works fine - GOOD.bmp
Control-Lines = 73 Grid shows 35 records
2. Just resizing the screen a little bit - WRONG.bmp
Control-lines = 72,20 Grid shows 34 records

The calculation op the records is correct, allthough there could be 1 more line in state 2. If you click the symbols on the right of the grid, nothing works anymore.

[Migrated content. Thread originally posted on 10 April 2006]

Is there an internal value where the maximum NUM-ROWS of a paged grid can be acquired when the form is resized, keeping in mind that the grid can have HSCROLL TRUE/FALSE ?

I have the following situation :

A grid has the following attributes in design time : LINES 44,00 - NUM-ROWS 22.
When the form resizes, I calculate the actual quantity of records to be filled as follow : COMPUTE NUM-RECORDS ROUNDED = (GRID-LINES / 2) - 1.

In most cases, this works fine, but others it doesn't.
My laptop has a resolution of 1440 by 900 pixels.
When the form resizes, inquiring the grid in debug, it has 73,00 lines. The grid first shows like in design-time, but then the form resizes automaticly and NUM-RECORDS becomes 36 => (73 / 2) - 1

Instead of 36, the grid shows 35 records to fill... so the logic of filling the grid isn't correct anymore.

Any ideas ?
And here's the WRONG.bmp

[Migrated content. Thread originally posted on 10 April 2006]

Is there an internal value where the maximum NUM-ROWS of a paged grid can be acquired when the form is resized, keeping in mind that the grid can have HSCROLL TRUE/FALSE ?

I have the following situation :

A grid has the following attributes in design time : LINES 44,00 - NUM-ROWS 22.
When the form resizes, I calculate the actual quantity of records to be filled as follow : COMPUTE NUM-RECORDS ROUNDED = (GRID-LINES / 2) - 1.

In most cases, this works fine, but others it doesn't.
My laptop has a resolution of 1440 by 900 pixels.
When the form resizes, inquiring the grid in debug, it has 73,00 lines. The grid first shows like in design-time, but then the form resizes automaticly and NUM-RECORDS becomes 36 => (73 / 2) - 1

Instead of 36, the grid shows 35 records to fill... so the logic of filling the grid isn't correct anymore.

Any ideas ?
Bitmaps haven't been sent .. I'll try again

[Migrated content. Thread originally posted on 10 April 2006]

Is there an internal value where the maximum NUM-ROWS of a paged grid can be acquired when the form is resized, keeping in mind that the grid can have HSCROLL TRUE/FALSE ?

I have the following situation :

A grid has the following attributes in design time : LINES 44,00 - NUM-ROWS 22.
When the form resizes, I calculate the actual quantity of records to be filled as follow : COMPUTE NUM-RECORDS ROUNDED = (GRID-LINES / 2) - 1.

In most cases, this works fine, but others it doesn't.
My laptop has a resolution of 1440 by 900 pixels.
When the form resizes, inquiring the grid in debug, it has 73,00 lines. The grid first shows like in design-time, but then the form resizes automaticly and NUM-RECORDS becomes 36 => (73 / 2) - 1

Instead of 36, the grid shows 35 records to fill... so the logic of filling the grid isn't correct anymore.

Any ideas ?
Maybe the files are to big... Last try

[Migrated content. Thread originally posted on 10 April 2006]

Is there an internal value where the maximum NUM-ROWS of a paged grid can be acquired when the form is resized, keeping in mind that the grid can have HSCROLL TRUE/FALSE ?

I have the following situation :

A grid has the following attributes in design time : LINES 44,00 - NUM-ROWS 22.
When the form resizes, I calculate the actual quantity of records to be filled as follow : COMPUTE NUM-RECORDS ROUNDED = (GRID-LINES / 2) - 1.

In most cases, this works fine, but others it doesn't.
My laptop has a resolution of 1440 by 900 pixels.
When the form resizes, inquiring the grid in debug, it has 73,00 lines. The grid first shows like in design-time, but then the form resizes automaticly and NUM-RECORDS becomes 36 => (73 / 2) - 1

Instead of 36, the grid shows 35 records to fill... so the logic of filling the grid isn't correct anymore.

Any ideas ?
Sounds like the differences are at small numbers then. Out of suggestions then, figures you will have to make a small example and post it with Tech Supp. But I am not confident this will be considered a bug though, as it might as well be a rounding problem with the Win API. However difficutl to state at present.
Terms & ConditionsAccessibility statement