#1152 resizingAdmin class Fullscreen

ooDialog.4.2.2
invalid
none
1
2013-01-08
2013-01-07
hex
No

Mark
I have tested your resizingAdmin class I found in oodialog 4.2.2.
Works very well when one get used to it, I found 1 strange thing.
Using the attached sample dialog pgm the following is observed.
1.On win xp (oorexx32bit) and win 8 (oorexx 32bit) and screen resolution 1920x1200,
a. start the racfcert.rexx, it should look like attached file 1.First_start.jpg screenshot
b. doubleclick on titlebar to get a fullscreen of dialog, it should look like attached file 2.First_fullscreen.jpg
I have marked with an red arrow where the screen is not redrawn totally, you may have to look close as it's hard to see, but you can hopefully see that the border around the listview is missing at the red arrow and that the dialog color at that point continue into the listview

On the other hand this does not occur on my laptop with screen resolution 1366x768 and win 8 (oorexx 64bit), maybe because the dialog almost fill the screen initially,
who knows.
/hex

1 Attachments

Discussion

  • Mark Miesfeld

    Mark Miesfeld - 2013-01-07
    • labels: resizingAdmin --> resizingAdmin, ooDialog
    • assigned_to: Mark Miesfeld
     
  • Mark Miesfeld

    Mark Miesfeld - 2013-01-07

    Thanks /hex

    I was going to try and get the doc done for this and then ask on the user list if people would help me test it. You're out ahead of me. ;-)

     
  • hex

    hex - 2013-01-07

    Did some more testing.
    I shrunk the initial dialogsize in the .rc file and the previous behaviour disappered when maximazing the dialog.
    If that can give you some hint about what happens.

    Attached is new .rc file for above and oodialog pgm for the below mentioned

    I also changed the resizeadmin dependency for the CANCEL (OK) button in the oodialog pgm, but that is not part of the disappering of previous behaviour, it was to get the button to align better to the treeview when resizing, only.
    But I can't get the CANCEL button to maintain even spacing between the treeview (bottom) and the dialog border (bottom), for now, dependent on how the resizing parameters are set for CANCEL, when expanding the window vertically the space between the treeview (bottom) and CANCELbutton (top) is maintained but the space to the dialog border (bottom) increase.
    /hex

     
  • Mark Miesfeld

    Mark Miesfeld - 2013-01-07

    Hi /hex

    This is in relation to the bugv2 files and your problem with the Cancel button.

    First as a general comment. There is no guarantee with the ResizingAdmin that you can just produce any resizing appearance you arbitrarily want. Some things just might not be possible and you would have to use a different base layout for the dialog.

    Having said that in general, I've reattached your program files that do what you want. At least to my eye the Cancel button maintains even spacing between the bottom of the tree-view and the bottom of the dialog.

    I did it by adding a hidden static text box and then pinning the Cancel button top to the YCENTER of the hidden static text:

    self~controlSizing(IDOK,                                                 -
                       .array~of('STATIONARY', 'RIGHT',IDC_TREE1),                     -
                       .array~of('STATIONARY', 'YCENTER',IDC_ST_CENTER),                    -
                       .array~of('MYLEFT',     'LEFT'),                      -
                       .array~of('MYTOP',      'TOP')                        -
                      )
    

    Take a look at the changes in the .rc file also. I tried to get the height of the IDC_ST_CENTER static text exactly the height of the space between the bottom of the tree-view and the bottom of the dialog.

    For the YCENTER, (or XCENTER) to work correctly, the control has to be centered in that area when the dialog is very first created. In other words, the Cancel button has to start off centered in the space between the bottom of the tree-view and the bottom of the dialog.

     
  • Mark Miesfeld

    Mark Miesfeld - 2013-01-08

    Hi /hex

    I just posted a long comment about your original bug, and it seems to have disappeared.

    In it I had basically said that I can not reproduce the problem you describe on Windows 7. But on an XP system I saw something similar. The bottom border of the list-view was not drawn. I fixed that by changing the height of the list-view from 285 to 284. I changed the tree-view to the same height. This produces a dialog that looks virtually the same to my eye.

    Because the math doing the calculations will produce fractional numbers that must be rounded or truncated to whole numbers, I would not consider having to adjust a control's width or height by 1 to be a bug.

    As I hinted at in my previous post, it may be that for some dialogs you will need to adjust the base layout of a dialog to get perfect results.

     
  • Mark Miesfeld

    Mark Miesfeld - 2013-01-08
    • status: open --> invalid
     
  • Mark Miesfeld

    Mark Miesfeld - 2013-01-08

    I set the screen resolution on my XP system to its max and was able to see the problem. You have a static text control with no text in the *.rc file. The IDC_MSG control. For that you were using what you had set as the default sizing, which pinned the top of that control to the top of the dialog using STATIONARY.

    That kept that control the same distance from the top of the dialog as it was initially. As the dialog got taller, the bottom of the list-view stretched towards the bottom of the dialog, until eventually the IDC_MSG control overlaid the bottom of the list-view.

    This is one way to fix it:

    -- Keep the invisible IDC_MSG static from moving up over the list-view as the
    -- height of the dialog gets bigger. We pin it stationary to the bottom of the
    -- list-view.
    self~controlSizing(IDC_MSG, -
    .array~of('STATIONARY', 'LEFT'), -
    .array~of('STATIONARY', 'BOTTOM', IDC_LIST1), -
    .array~of('MYLEFT', 'LEFT'), -
    .array~of('MYTOP', 'TOP') -
    )

    There are probably a number of different ways to fix this.

    I'm going to close this one as invalid, or not a bug. But, I hope you continue using / testing the ResizingAdmin for resizable dialogs. I think the basic principle it uses will work well, just take a little getting used to. ;-)

     
  • hex

    hex - 2013-01-08

    Mark
    I have read what you write and understand/accept that.
    Thanks for the hint of positioning CANCEL button.
    As already said, it will take some time getting used to resizingadmin.
    I will continue testing
    /hex

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks