Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

MDIClient resizing issie

OI 10.2.2 beta2 rel 20623 (Beta 1 rel 20605 is OK)

Can anyone confirm that they are also having this in in Beta2:

Open form then close it and the MDIClint window resize to top of ribbon.

then close

Comments

  • Are you using the MDISize property to set the client's size during the CREATE event?
  • We've recreated this on our end. I'll keep you posted.
  • Great, Thanks.
    Not using the MDISize property.
  • Have changed to use the OLE.MDISIZE for OI10 as per your recommendation.
  • @KevinFournier maybe Rev accidently put something from 10.3 into 10.2.2 again (RevProfileLog)
  • I've got an inquiry in with Rev to see if this is something I have to work around or unintended behavior on their end.
  • FYI: Issue still in 10.2.2 RC
  • I have a fix that comes with caveats. You have to use MDISize to set the size of the MDICLIENT and you have to subclass the MDICLIENT using the SRP Subclass Control. Those combined should prevent the resizing and flickering.
  • >>subclass the MDICLIENT

    Can you give me a hint as to what the command line should look like.
  • CtrlId = @Window:".MDICLIENT" Handle = Get_Property(CtrlId, "HANDLE") Send_Message(@Window:".OLE_SUBCLASS", "OLE.Subclass", Handle, CtrlId)
  • edited July 2024
    Thanks.
    Should this go before or after the MDISize?
  • >>subclass the MDICLIENT

    That worked, I did not have to use the MDISize.
  • Glad it's working. You can get away without using MDISize if you don't ever set the MDICLIENT SIZE property after the frame is created.
  • I' l l t y p e s l o w l y a t f i r s t t o g i v e t h i s p o s t t i m e t o w a k e b a c k u p.

    There, that should do it.
    We've stumbled over a consequence of subclassing the mdiclient. After subclassing, we cannot modify the backcolor property of the mdiclient.

    It's not something we do regularly but it is something we do in some very specific circumstances. If the client is subclassed, then setting the backcolor property doesn't do anything.

    Set the backcolor property first, then subclass the client retains the backcolor, until that is, you set the visibility of the form and then the subclassed mdiclient reverts back to default colours.

    I have found a work around that seems to work for us and that is to subclass the mdiclient after both of those things have occurred.
    So, set the backcolor property of the mdiclient.
    Make the mdiform visible.
    Subclass the mdiclient.

    Subclassing in and of itself isn't the problem but (I'm guessing based on this thread), resizing the form/client area after subclassing resets the backcolor property and prevents it from being modified.

    The working sequence seems to uphold the solution to the problem this thread was started for so I think we're all good now but figured it was worth mentioning
  • Ok was worth mentioning. It only holds ok providing I don't move the mdi.
    Like to my second monitor.
    Like I do every single time.

    Obviously, the move resizes the window and that in turn resets the mdiclient colour to default settings.
  • Crap. Closing an opened form also resets the mdiclient to default colour settings. That one I can't explain away.
    Is there a way we can prevent a subclassed mdiclient from resetting its colours at least?
  • edited July 29
    The best I can do is give you a new property. First, grab version 4.2.7.8 (32-bit or 64-bit).

    After you subclass the MDI client, set the Subclass Control's MDI Background property like so:

    Set_Property(@Window:".OLE_SUBCLASS", "OLE.MdiBackground[":@Window:";MDICLIENT]", MyBackColor)

    The background can be any Color Fill value.
Sign In or Register to comment.