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

Splitter interaction with OI

I have a splitter, with the controls to the left and right being resized to fit.
If I move the splitter to the right, all OK as expected.
When I resize the form however, the splitter resets to the original OI position.
I think this is OI trying to be a bit too clever.

What is the best approach to resizing controls and making them stay put when you resize the form.

Comments

  • Colin,

    Are you seeing the splitter return to the original location, the resized controls returning to their original size, or both? I don't think your post was absolutely clear about this.

    I have never seen either behavior and I use the SRP Splitter control on several forms. I presume you are using the SIZE property to relocate the position of the SRP Splitter control and to resize the OI controls. Are any of the controls anchored?
  • Don

    Sorry for the delay in responding, I forgot about this one, and now I see it on the new forum it jogged my memory.

    None of the controls are anchored.
    There is a SRP tree control either side of the splitter, and this is set to Autoresize height only.
    The type of control on the screen is irrelevant as far as I can see.

    When moving the splitter, I position it and resize the controls, all that works fine, all using the SIZE property.
    The form only has one page as I am aware that SIZE property setting has issues if you are on page 2 etc.
    When resizing the form, I use the SIZE event and resize the control to the right of the splitter, as its not set to autosize width.

    The splitter seems to reposition itself to where it was before the last splitter move.

    I have also added a RETURN statement in the SIZE event on the form so that no code is run here at all, and the same thing happens.

    Colin

  • Colin,

    Is this on an MDI Frame or regular window?
  • Don

    This is a regular window
    Screen attached
  • Colin,

    I asked because we have had issues with MDI Frames before. But, I suspect the issue is not limited to MDI Frames. In any event, AFAIK, the problem is not related to the SRP Splitter control. If OI is resetting the SIZE property of the control (which we have seen before) then it is a problem with the presentation server. We have witnessed it doing some kind of weird caching. Do you have any reason to suspect that this is uniquely an SRP Splitter control issue?
  • Don

    I believe it is 100% an OI thing, nothing to do with SRP at all.
    I would expect that if I removed all controls from the form except the splitter that it would interact with the form in exactly the same way.

    My initial posting was not an SRP issue, but more a question as to the best approach, as I expect I am not the first to encounter this. As it was an SRP splitter, the question was perhaps relevant on this forum. I will post on the OI forum as well. Cant use an OI splitter as they are a bit useless in these situations.

    Colin

  • Colin,

    Thanks for clarifying this. Your approach is what I consider to be "best practice". However, I think Kevin has had to deal with this issue more than me for the SRP Editor (which has to do a lot of control resizing). Hopefully he can chime in with some suggestions on how to work around this.
  • edited December 2015
    Ah, yes. Sorry I didn't chime in sooner. We're still working out why notifications aren't getting out. But this is for sure an OI thing. So, every time a splitter bar moves in the SRP Editor, I call this gosub:

    //------------------------------------------------------------------------------------------------- // Saves the sizes of several controls to UDPs so we can workaround OI's size caching bug //------------------------------------------------------------------------------------------------- Save_Sizes: FrameSize = Get_Property(Frame, "CLIENTSIZE") // Non anchored with both autosizes Ctrls = MdiClientCtrl NumCtrls = Count(Ctrls, @FM) + 1 For i = 1 to NumCtrls Ctrl = Ctrls<i> Size = Get_Property(Ctrl, "SIZE") Size<3> = FrameSize<1> - (Size<1> + Size<3>) Size<4> = FrameSize<2> - (Size<2> + Size<4>) Set_Property(Ctrl, "@SIZE", Size) next i // Non anchored with auto width Ctrls = TabCtrl NumCtrls = Count(Ctrls, @FM) + 1 For i = 1 to NumCtrls Ctrl = Ctrls<i> Size = Get_Property(Ctrl, "SIZE") Size<3> = FrameSize<1> - (Size<1> + Size<3>) Set_Property(Ctrl, "@SIZE", Size) next i // Non anchored with auto height Ctrls = TreeCtrl:@FM:SplitterCtrl NumCtrls = Count(Ctrls, @FM) + 1 For i = 1 to NumCtrls Ctrl = Ctrls<i> Size = Get_Property(Ctrl, "SIZE") Size<4> = FrameSize<2> - (Size<2> + Size<4>) Set_Property(Ctrl, "@SIZE", Size) next i // Top anchored with auto width Ctrls = StatusSplitterCtrl NumCtrls = Count(Ctrls, @FM) + 1 For i = 1 to NumCtrls Ctrl = Ctrls<i> Size = Get_Property(Ctrl, "SIZE") Size<2> = FrameSize<2> - Size<2> Size<3> = FrameSize<1> - (Size<1> + Size<3>) Set_Property(Ctrl, "@SIZE", Size) next i return

    This is because OI caches control locations and tries to reset them during a SIZE event. So, during the Size event, I do this monstrous piece of code:

    //------------------------------------------------------------------------------------------------- // Handles the SIZE event for the frame // @@DEFINE_SERVICE(OnSize) //------------------------------------------------------------------------------------------------- OnSize: FrameSize = Get_Property(Frame, "CLIENTSIZE") // Non anchored with both autosizes Ctrls = MdiClientCtrl NumCtrls = Count(Ctrls, @FM) + 1 For i = 1 to NumCtrls Ctrl = Ctrls<i> Size = Get_Property(Ctrl, "@SIZE") If Size then CurrSize = Get_Property(Ctrl, "SIZE") RightAnchor = FrameSize<1> - (CurrSize<1> + CurrSize<3>) BottomAnchor = FrameSize<2> - (CurrSize<2> + CurrSize<4>) If (CurrSize<1> NE Size<1>) OR (CurrSize<2> NE Size<2>) OR (RightAnchor NE Size<3>) OR (BottomAnchor NE Size<4>) then CurrSize<1> = Size<1> CurrSize<2> = Size<2> CurrSize<3> = CurrSize<3> + (RightAnchor - Size<3>) CurrSize<4> = CurrSize<4> + (BottomAnchor - Size<4>) Set_Property(Ctrl, "SIZE", CurrSize) end end next i // Non anchored with auto width Ctrls = TabCtrl NumCtrls = Count(Ctrls, @FM) + 1 For i = 1 to NumCtrls Ctrl = Ctrls<i> Size = Get_Property(Ctrl, "@SIZE") If Size then CurrSize = Get_Property(Ctrl, "SIZE") RightAnchor = FrameSize<1> - (CurrSize<1> + CurrSize<3>) If (CurrSize<1> NE Size<1>) OR (CurrSize<2> NE Size<2>) OR (RightAnchor NE Size<3>) then CurrSize<1> = Size<1> CurrSize<2> = Size<2> CurrSize<3> = CurrSize<3> + (RightAnchor - Size<3>) Set_Property(Ctrl, "SIZE", CurrSize) end end next i // Non anchored with auto height Ctrls = TreeCtrl:@FM:SplitterCtrl NumCtrls = Count(Ctrls, @FM) + 1 For i = 1 to NumCtrls Ctrl = Ctrls<i> Size = Get_Property(Ctrl, "@SIZE") If Size then CurrSize = Get_Property(Ctrl, "SIZE") BottomAnchor = FrameSize<2> - (CurrSize<2> + CurrSize<4>) If (CurrSize<1> NE Size<1>) OR (CurrSize<2> NE Size<2>) OR (BottomAnchor NE Size<4>) then CurrSize<1> = Size<1> CurrSize<2> = Size<2> CurrSize<4> = CurrSize<4> + (BottomAnchor - Size<4>) Set_Property(Ctrl, "SIZE", CurrSize) end end next i // Top anchored with auto width Ctrls = StatusSplitterCtrl NumCtrls = Count(Ctrls, @FM) + 1 For i = 1 to NumCtrls Ctrl = Ctrls<i> Size = Get_Property(Ctrl, "@SIZE") If Size then CurrSize = Get_Property(Ctrl, "SIZE") TopAnchor = FrameSize<2> - CurrSize<2> RightAnchor = FrameSize<1> - (CurrSize<1> + CurrSize<3>) If (CurrSize<1> NE Size<1>) OR (TopAnchor NE Size<2>) OR (RightAnchor NE Size<3>) then CurrSize<1> = Size<1> CurrSize<2> = FrameSize<2> - Size<2> CurrSize<3> = CurrSize<3> + (RightAnchor - Size<3>) Set_Property(Ctrl, "SIZE", CurrSize) end end next i // Update the splitters limits Set_Property(SplitterCtrl, "OLE.RightMargin", Int(FrameSize<1> / 2)) Set_Property(StatusSplitterCtrl, "OLE.TopMargin", Int(FrameSize<2> / 2)) return

    Notice how I have to handle auto sized and anchored controls slightly differently. The above code is generic, so all you should have to do is update the CTRLS variable with the list of controls that match the category mentioned in the comment.

    This is a major pain, but it is what it is, I guess. Hope this helps.
Sign In or Register to comment.