resizing StringGrid in Win10

[rick2691]

The following is a code excerpt from a much larger application. I can only hope that I have included all of its critical elements for your review.

This code is for resizing the row heights and column widths when the main form has been dragged or otherwise resized.

It works well in WinXP, but Win10 will not modify the row and column sizes, no errors are reported. Win10 will, however, resize the columns if I manually drag them.

Can anyone tell me what to do to make it work in Win10?

Code: Pascal  [Select][+][-]

1. unit CmdDatCode;
2.  
3. {$mode objfpc}{$H+}  
4.  
5. interface
6.  
7. uses Grids;
8.  
9. type TMainFrm = class(TForm)
10.                        PostPts: TStringGrid;
11.                        
12.                        private
13.                            procedure FormatGrid;
14.                        end;
15.              
16. var ApplyResize: double;     // to apply Scaling to Grid Columns
17.      MaxP: integer;     // practical maximum for PostPts.RowCount value
18.  
19. implementation
20.  
21. {$R *.lfm}
22.  
23. procedure TmainFrm.FormatGrid; {Populate PostPts Tabbed Point List}
24. var
25.   PstPnt,Str1: string;
26.   z: integer;
27. begin
28.   PostPts.ColCount:= 5;
29.   PostPts.DefaultRowHeight:= trunc(22*ApplyResize);
30.  
31.   if MaxP>9999 then MaxP:=9999;
32.   if MaxP<10000 then PostPts.RowCount:= MaxP+1 //was MaxP+1;   {data}
33.                 else PostPts.RowCount:= MaxP;
34.  
35.   PostPts.colwidths[0]:= trunc(60*ApplyResize);   {point}
36.   PostPts.colwidths[1]:= trunc(128*ApplyResize);   {north}
37.   PostPts.colwidths[2]:= trunc(128*ApplyResize);   {east}
38.   PostPts.colwidths[3]:= trunc(90*ApplyResize);   {height}
39.   PostPts.colwidths[4]:= trunc(224*ApplyResize);  {description}
40.  
41.   PostPts.Cells[0, 0]:= ' Point';     {titles}
42.   PostPts.Cells[1, 0]:= ' Northing';
43.   PostPts.Cells[2, 0]:= ' Easting';
44.   PostPts.Cells[3, 0]:= ' Height';
45.   PostPts.Cells[4, 0]:= ' Description';
46.  
47.   for z:= 1 to MaxP do
48.       begin
49.       if z<10000 then
50.          begin
51.          Str(z, PstPnt);
52.          PostPts.Cells[0, z]:= ' '+PstPnt;  {list points}
53.          end;
54.       end;
55. end;
56.  
57. end.
58.  

Rick

[derek.john.evans]

I dont know, but this is what I'd check.

Are you running Laz v1.4.4? If so, test with 1.6.2+
Are you testing the same exe, or are you recompiling on the Win10 machine?
Both are 32bit?

To me it sounds like a missing resize event. If so, try manually calling the resize event via the TStringGrid resize event (or TForm onresize)

[tk]

Quick thoughts:
Where is ApplyResize set (and is it set correctly under Win10)?
Should not it be better an input parameter for FormatGrid?
What about some minimalistic example project first (one form, one grid etc)? Does it work?

[rick2691]

Yes, I am using Laz 1.4.4, and I am compiling in WinXP and applying compatibility in Win10. I am not using any event. I am resizing by code, and then assigning the scale factor to ApplyResize (0.85 thru 1.45). I don't use Laz 1.6.2 because it has made problems in both WinXP and Win10.

The FormatGrid is called by the FormActivate event.

Since I don't use an event I can't see why the columns and Row heights can't be changed in Win10. I have assumed that it is an internal function that shouldn't have anything to do with Win10, since everything else functions properly.

I have about a dozen applications that worked fine. This is the only one that uses Tstrings. I have also compiled it in Win10 (with both Laz 1.4.4 and 1.6.2, and it had the same problem with both of them.

Since this is my first attempt to work with Win10, and I am still learning about compatibility and permissions, I am going to repeat the process. I am also going to try setting the call to FormatGrid before the actual resizing of the form... but again, WinXP handles it fine as it is.

Rick

[rick2691]

I relocated the call to FormatGrid to where it preceded the Form resizing, and it had no effect.

I compiled the app in Win10 with fpc 1.4.4, and it could not compile it.

I compiled in Win10 with fpc 1.6.2 @ 64 bit, and it could not compile it.

I compiled in Win10 with fpc 1.6.2 @ 32 bit, and it did compile, but had no effect on resizing the Tstring grid.

I am assuming that it is a Tstring bug... unless there is a conditional parameter that has to be set for Win10. Perhaps something that is similar to:

{$IFDEF FPC}
  {$MODE Delphi}
{$ENDIF}

Rick

[rick2691]

I have found a conditional windows code from another thread...

{$IFDEF WINDOWS}
  uses win32proc;
{$ENDIF}
// ...
{$IFDEF WINDOWS}
  if WindowsVersion >= wv10 then
     Showmessage('OS is Windows 10 or later');
{$ENDIF}

If you think that this is the right approach, and if any of you can help me on deducing what should be added to the wv10 portion I would be most grateful.

Rick

[tk]

Did you also try recent trunks (Lazarus + FPC, you can comfortably setup them with fpcupdeluxe now)?

I don't see any such problems in Win10, tried now with some older demo project comparing StringGrid vs. KGrid (I only use KGrid now).

So I am pretty sure the cause is somewhere else, not in the StringGrid component. Without complete project, hard to say what is the problem.

[wp]

I can't give specific advice because you don't show enough code. But here's how I would do a stringgrid which resizes column widths and row heights and font size along with the size of the grid. And it works perfectly in Win10, Win 7 and Win2000, with Laz trunk and Laz 1.4.0.

Did you provide a handler for the grid's OnResize?

[rick2691]

wp,

Thanks for your example. I will look in to it. But trust me, that is all of the resizing code for stringgrid. I resize the from with uScaleDPI, but it cannot adjust the stringgrid, so I take its scaling factor and apply it to stringgrid with FormatGrid. Nothing else happens.

I will look into your example.

Rick

[rick2691]

I tested your project in Win10. It performed without a fault.

The only immediate difference that I can notice is that you are resizing in runtime and dynamically. I am doing a one-time resize at FormActivate, and that I am doing custom widths for each column.

I am sure that a closer examination will reveal where my flaw is... it just befuddles me at this point is that it works in WinXP.

Rick

[rick2691]

WP,

I tried to translate your code into my own, and again it worked in XP and not 10. So I decided to ditch my code, and then adjust yours to my needs... it worked in both perfectly.

 I still can't see why, unless it is your use of "FOrigColWidths, FOrigRowHeights: Array of Integer;" I think that it is all that I had tried to omit when translating to my own code.

But the bottom line is... I am happy to have gotten past it all.

There is one tweak that I added... multiplying "factor" by 1.012. It's only an approximate adjustment, but it helps with the vertical scroll bar not being scaled. It stays the same size, and of course, that isn't applicable to your application (only mine).

Much thanks, Rick

[wp]

If I understand you correctly you want to scale the grid along with the screen resolution? In this case you should give Lazarus trunk a try. Recently, form scaling has been completely rewritten - see http://wiki.lazarus.freepascal.org/High_DPI#High_DPI_in_Lazarus_1.7_and_above. I know that you are still using version 1.4.4, but with fpcupdeluxe you can easily install any Lazarus version without interfering with your primary install (seek for fpcupdeluxe here in the forum).

[rick2691]

Thanks for the information. I will give 1.7 a try. It looks like it has some good features.

I have stayed with 1.4 because it is solid. 1.6 has given me troubles... mostly just small annoyances, but in Win10 (I had tried it because I thought it was designed for it) it hadn't been able to compile anything until I installed the 32 bit version.

My issues with form size have not been on account of DPI problems. My software was built with a 1024x820 screen. The forms were too big on smaller screens, so I made them as small as was workable for the larger. Now I have even larger screens to deal with (1920x1024) and all the forms are too tiny (yet it uses 96 DPI).

So using the uScaleDPI unit has resolved the problem. I just contrive a smaller base DPI and it expands all of the forms, but it could'nt expand the String Grid. Your code has resolved the issue.

With it I provide a percentage scale for shrinking or expanding the forms (85% to 145% in 5% increments). It allows the user deal with screen sizes for both large and small screen situations. I was able to adapt your code to the same method.

Happy New Year to you. Thanks again for the assistance.

Rick

[rick2691]

There is one tweak that I added... multiplying "factor" by 1.012. It's only an approximate adjustment, but it helps with the vertical scroll bar not being scaled. It stays the same size, and of course, that isn't applicable to your application (only mine).

For those who wonder where I came up with the above multiplier, I had taken a ruler and scaled the form as it appears on the screen. As such, it is only useful with my current system configuration.

An exact method (that also incorporates the system parameters) would be as follows:

factor:= (PostPts.Width - VertScrollbar.Size) / (FOrigWidth - VertScrollbar.Size);

The above is only applicable when a vertical scroll bar is present in all conditions.

Rick

[rick2691]

I am posting the following because I found a different behavior between WinXP and Win10 for dealing with vertical scroll bars.

WinXP needs the scroll bar width to be handled by the code.
Win10 internally compensates for the scroll bar.

The code below reports the active Windows version and uses different methods.

I also found that if you are using compatibility to WinXP, it reports that Windows XP is your operating system, but it still compensates for the scroll bar itself. So your own handling of the scroll bar is counter productive. I removed compatibility, and everything operated properly.

Code: Pascal  [Select][+][-]

1. procedure TMainFrm.GridOnCreate(Sender: TObject);    // called by FormCreate
2. var
3.   i,j: Integer;
4. begin
5.   PostPts.RowCount:= 101;
6.   PostPts.ColCount:= 6;
7.   PostPts.colwidths[0]:= 60;   {point}
8.   PostPts.colwidths[1]:= 128;   {north}
9.   PostPts.colwidths[2]:= 128;   {east}
10.   PostPts.colwidths[3]:= 90;   {grade}
11.   PostPts.colwidths[4]:= 220;  {text}
12.  
13.   for i:=0 to PostPts.ColCount-1 do
14.       begin
15.       // alternatively to... PostPts.Cells[i, 0]:= 'Col'+IntToStr(i);
16.       // with the below the title cells are posted, and the cell data is populated later
17.       case i of
18.            0: PostPts.Cells[i,0]:= ' Point';
19.            1: PostPts.Cells[i,0]:= ' North';
20.            2: PostPts.Cells[i,0]:= ' East';
21.            3: PostPts.Cells[i,0]:= ' Grade';
22.            4: PostPts.Cells[i,0]:= ' Text';
23.            end;
24.       for j:=1 to PostPts.RowCount-1 do
25.           PostPts.Cells[i,j] := ' ';
26.       end;
27.  
28.   FOrigWidth:= PostPts.Width;
29.   //FOrigFontHeight := GetFontData(PostPts.Font.Handle).Height;   // handled by ScaleDPI in FormActivate
30.   SetLength(FOrigColWidths, PostPts.ColCount);
31.   SetLength(FOrigRowHeights, PostPts.RowCount);
32.  
33.   for i:= 0 to High(FOrigColWidths) do
34.       FOrigColWidths[i]:= PostPts.ColWidths[i];
35.   for i:= 0 to High(FOrigRowHeights) do
36.       FOrigRowHeights[i]:= PostPts.RowHeights[i];
37. end;
38.  
39. procedure TMainFrm.GridOnActivate(Sender: TObject);   // called by FormActivate
40. var
41.   factor: Double;
42.   i: Integer;
43.   s: string;
44. begin
45.   {$IFDEF WINDOWS}
46.   if WindowsVersion = wvLater   // Win10   // uses win32proc ... wvXP wvVista wv7 wv8 wvLater
47.      then begin
48.           factor:= PostPts.Width / FOrigWidth;
49.           //str(VertScrollbar.Size,s);
50.           //showmessage('Win10 bar='+s);
51.           end;
52.   if WindowsVersion = wv8       // Win8    // uses win32proc ... wvXP wvVista wv7 wv8 wvLater
53.      then begin
54.           factor:= PostPts.Width / FOrigWidth;
55.           //str(VertScrollbar.Size,s);
56.           //showmessage('Win8 bar='+s);
57.           end;
58.   if WindowsVersion = wv7       // Win7    // uses win32proc ... wvXP wvVista wv7 wv8 wvLater
59.      then begin
60.           factor:= PostPts.Width / FOrigWidth;
61.           //showmessage('Win7');
62.           end;
63.   if WindowsVersion = wvVista   // Vista   // uses win32proc ... wvXP wvVista wv7 wv8 wvLater
64.      then begin
65.           factor:= PostPts.Width / FOrigWidth;
66.           //showmessage('WinVista');
67.           end;
68.   if WindowsVersion = wvXP      // WinXP   // uses win32proc ... wvXP wvVista wv7 wv8 wvLater
69.      then begin
70.           factor:= (PostPts.Width - VertScrollbar.Size) / (FOrigWidth - VertScrollbar.Size);
71.           //str(VertScrollbar.Size,s);
72.           //showmessage('WinXP bar='+s);
73.           end;
74.   {$ELSE}
75.   begin
76.   factor:= (PostPts.Width - VertScrollbar.Size) / (FOrigWidth - VertScrollbar.Size);
77.   //showmessage('Other');
78.   end;
79.   {$ENDIF}
80.  
81.   for i:= 0 to PostPts.ColCount-1 do
82.       PostPts.ColWidths[i]:= round(factor * FOrigColWidths[i]);
83.  
84.   for i:= 0 to PostPts.RowCount-1 do
85.       PostPts.RowHeights[i]:= round(factor * FOrigRowHeights[i]);
86.  
87.   //PostPts.Font.Height := round(factor * FOrigFontHeight);   // handled by ScaleDPI in FormActivate
88. end;
89.  

Rick