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

SRP Controls issues.

edited May 2023 in General
I am posting this here because I have noticed a few other issues with the new SRP Controls (x32) that fall under 3 umbrellas (Ribbon, Button, ReportTable). All tests before/after are just a simple chnange of SRPControls.ocx file.

1. I have several instances of Images not displaying as they once did. Three known examples are listed below and include both Ribbon Control and Button Contols.

These are Images we have sourced (I think) from somewhere once upon a time. I am not sure what in the new SRPControls causes only some of all these images not to render correctly.
What, if any, special requirements might there be for image formatting? Most of our images are 32x32 (or 16x16), PNG format, transparent.

Issue: Images in Ribbon 1

Status: Confirm changed in new SRP Controls

Orig (


Fix: I was able to resize the image up and then down and resaved. (I think that was the action that ended up working)
Some loss of quality is noticeable in this solution.

Issue: Images in Ribbon 2. ( Icons different color - Red not Blue)

Status: Confirm changed in new SRP Controls
Orig (


Issue: Disabled SRPButton Images are Outlines only, not greyscale images like they used to be.

Status: Confirm changed with new SRP Controls

Orig (



Issue: Report Footer does not display

Status: Confirm change in new SRP Controls

<b class="Bold"><b class="Bold"><b class="Bold">SetupFont = "" SetupFont<1, 1, 1> = "Segoe UI" SetupFont<1, 1, 2> = "8" SetupFont<1, 1, 3> = "700" Set_Property(Ctrl , "OLE.FooterVisible" , 1) Set_Property(Ctrl , "OLE.ColumnFooterText[1]" , "Total:") Set_Property(Ctrl , "OLE.ColumnFooterFont[1]" , SetupFont)</b></b></b>

Orig (



  • I'll get to work on these issues. Any chance you can send me the image files that break?
  • Sure thing @KevinFournier. Let me put that package together.
  • Thanks for the files. This helped me narrow down the issue quickly. Some of your images are 8-bit, and I wasn't converting them properly in memory.

    Version fixes all the above issues, including the ReportTable issue.
  • I can confirm all issues rectified.
    You sir, are a magician!

    The quick turnaround was much appreciated, especially for the Footer issue as it was functional rather than cosmetic.
  • @KevinFournier

    I think I have another one for you with this latest set of Controls (I haven't checked previous 4.2.x Controls but I can confirm I can't replicate it with 4.1.x)

    We open up our Child windows centered mid-screen in our Frame.

    If we minimize the whole application, when we maximise it again child windows only open in the bottom right corner, 3/4 offscreen, and have to be dragged to the center again.

    Have you seen that behavior before?
  • @Opto_Will - Why do you suspect the SRP Controls? Are you using the Ribbon control for this specific app?
  • Update.
    It seesms to be the Frame size is all out of whack when returning from a minimize. I didnt notice before because the Ribbon looks fine and our Frame background is a consistant color. I used a different background image and when returning from a minimise with the new Controls the Frame Image is 'huge' (as in it looks like it would take up 4 of my screens (if they existed). The Child window is actually opening up in what looks like the center of this new huge Frame....
  • @DonBakke.

    I don't necessarily think it is the Controls as it seems it would be more a Framework thing if anything. However, like my previous symptoms, I can toggle this on and off with the different controls so the Controls.ocx file definately has some influence here. Old ( Controls and I cannot replicate . New ( Controls and I can replicate straight away.

    Yes, we are using the Ribbon Control. The Ribbon itself appears 'normal' size in either test.

  • @Opto_Will - Thanks. I would bet that this is an SRP Ribbon control issue then. It subclasses the entire form so unusual behavior is not unexpected. Also, if you run the EXAMPLES app you'll see that it is an MDI frame based app. Near as I can tell, it does not exhibit the problem you are describing.
  • Just wanted to confirm that I can recreate this and am investigating.
  • Much appreciated Kevin.
  • Try

    It took me three and half days of trial and error to figure out how to deal with this issue. The end result should lead to better handling of child controls on a form with the Ribbon, but it does come with one potentially breaking change. It used to be the case that the ribbon control was part of the the form's client area, so if you set a control's SIZE property in code to be at y coordinate 0, it would end up behind the ribbon. From now on, y coordinate 0 is the first pixel beneath the ribbon. This change should only affect people who have been hard-coding x and y positions in their controls. Looking at the older copy of OPTO that I have, it shouldn't affect you. The being said, if controls are not exactly where they used to be, it's probably because this version is more accurate in placing controls than the previous version.

    At any rate, it definitely solves the minimizing issue. Give it a try and let me know if you run into anomalies. I'll help you sort them out.
  • @KevinFournier,

    I have only played with it in my local environment but does indeed look like it has corrected the issue I noted.
    I will release it to the wider team for a looksee.

    You are right, we aren't hard-coding X & Y (or at least as far as I am aware we never have) so the new structure shouldn't afffect us.

    That sounds like it was quite the journey. We very much apprecate your efforts!

  • Actually @KevinFournier, while I have you....

    I have an oberservation/question that is roughly in the realm of what we have been talking about here.
    I dont know if it a Ribbon Control thing or a OI9 thing. Unfortunately we are not far enough along in our OI10 conversion to really be able to test this behavior there yet.
    I want to be clear I am not saying this is related to the new controls as this behavior clearly existed previously.

    In a multi monitor setup:
    Monitor 1: 3840*2160
    Monitor 2: 2880*1920

    If I open a new Form in Monitor 1 it opens centered for us. If I then move the App to Monitor 2, the previously centered form now appears lower-left/offscreen (like it did for the issue you just fixed). The Background Frame image and Ribbon Control correcty resize for the different res.
    If I then open a new Form while on Monitor 2 it opens centered on that 'smaller' screen. If I now move the App back to Monitor 1 the form now appears Upper Right. The Background Frame image and Ribbon Control correcty resize for the different res.

    I m guessing when opeing a new Child the system finds the center point (as we have configured it) and uses hard co-ordinates that obviously dont change relatively when the App is resized on a different res monitor?
    I know OI 10 has better 'Responsive' design. Would we expect this behavior to change when we get OI10 up and running?

  • This is expected behavior. MDI child windows can't be told to "stay centered". Once you display them, there they are. This is one of the reasons MDI was deprecated many Windows versions ago. This is also why Frameworks opts to show everything in the top left corner rather than centered.
  • Understood. Top Left is always going to be Top Left but everything else is up for discussion....
  • @KevinFournier

    Yes I can duplicate he issue in oi9, and your fix works, albient slightly lower than the center.
    Also, the issue does not appear to be in OI10, can you confirm and dont break OI10 with the OI9 change if not needed.
  • >>albient slightly lower than the center.

    Chanded the calculation and all good
  • I didn't change any of the OI 10 code, but if you see something is off, let me know. OI 10 is different because all the OI controls are placed on a Client control. So, in OI 10, the ribbon just has to resize that Client control and everything else resizes accordingly.
  • I've just updated to and haven't yet tried any of the releases linked in this thread so maybe this has been addressed already but...

    This is a second monitor issue. If I open a form with a tabcontrol on my primary (laptop) monitor, then everything functions as expected, but if I move the app to my second, preferred monitor, all controls from all pages bleed through the tab.

  • Per chance is your second monitor set to a different scale (DPI) than your primary monitor? I am not asking about resolution, just scale.
  • Yes.
    125% for laptop and 100% for secondary monitor
  • Are you able to make them the same scale and test again? I'm trying to confirm a theory.
  • Same scale. Same problem.

    .... just more in my face :D
  • Okay, thanks for doing that. We discovered a problem with OLE controls on a form that are programmatically moved revert back to their original position when the form is moved to another monitor with a different scale. I was wondering if your situation had any connection. We'll have to investigate this further for you.
  • This appears to be a double-buffering issue, but I can't seem to recreate this, and I have different DPIs on my monitors as a rule. If this is still happening in, let me know. I assume this is OI 9.4 and not OI 10, but if I'm wrong on that, let me know.
  • Sorry Kev,

    Still happening and yes, OI9.4.4
  • Given the complexity of the form, I can try debugging a copy of your system if you're willing to send me one via email or something. Another thing I like to do is make sure the tab control appears earlier in the tab order than all the controls in it's pane.
  • I was hoping you were onto something re tab order so made the tab the first control.
    Alas no luck.
    I didn't really need to do anything to test it this time. I just opened the form on the second monitor and when it appeared in front of the window I already had open, guess what I could see.

    That's the schedule control from a different form bleeding right through.

    I have heard you re getting a copy of the system. I'll get to that but I'll look at creating a simple example first.
Sign In or Register to comment.