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

MDICLIENT

2»

Comments

  • And I was goinf to say to @jimvaughan,

    That seems to be the code I posted in another Post. Worked well for us. We have the SRP Ribbon up the top of the Frame and a Statusbar at the bootom.

    I localised the SRP FW_MAIN code and added to the CREATE, as was noted above, and it fixed quite a number of issues for us!

    Good luck.
  • Kevin,

    Many thanks for the new ocx, that works perfectly.
  • We, as a standard, drop the SubClass Control in pretty much every form

    Out of curiosity, @Opto_Will, how often would you say that you utilise that dropped subclass control?

    And if it's a high percentage, I'm also curious as to what would be the primary use/feature that you capitalise on?
  • @AusMarkB

    I am sure there are forms where it does not get used at all.

    Predominanlty for Options stuff (most forms tbh). Some Dropdowns here and there, as well as some Balloon Tooltips ina couple of places.

    Im not convinced we needed to include it on every form instead of just our FW_MAIN (according to the documentation) but they are all there so there they shall stay!
  • I place one on the individual forms as well, just not as a standard. I only put it there if I know I'm going to use it.

    TBH, I forgot about the options. That makes sense for the right application. In the first application that I went all in with SRP controls, we used the options extensively. That app did have a lot of promoted event logic which made it much easier to implement. So I can see how that would work and why adding the control as a standard would make sense.
  • BTW, the argument for putting the SRP Subclass control on individual forms versus the parent form (i.e., the MDI Frame or some startup menu form) is so that events are routed to the individual form.

    We also put the control, as well as the SRP Popup control, on all forms whether or not we expect to use their features. We would rather it be there and not needed than need it and it not be there. Sure, we could always add it later, but it is nice to have a standard that you can rely upon.
  • Plus it helps for the fancy new Controls version that alleviates the Toolbox issue by already having a Control on every form!

    Anton must have been psychic! Either that or he listened back in the day when Don explained all the above to him. ;-)
  • I am an idiot, I had not named the ribbon control, it was using the default name. It positions correctly now.

    Another issue however, if I open the ribbon controls properties in FormDes and set its visible property to unchecked FormDes crashes. If I then reopen Fromdes and open that form, it says it is in use elsewhere.
  • I'll take a look, but truth be told, you're in uncharted waters. The Ribbon has to override the entire form in order to work, so hiding it was not part of the plan.
  • Ah OK, the OLE control was on top of the ribbon that was drawn, and was causing the ribbon to be missing the piece underneath the OLE control. I have moved it up and out of the way instead.
  • Oh, sorry. My bad. The control itself is allowed to be invisible. I've had a long day. I was thinking you were trying to disable the Ribbon temporarily.

    I'll look into it. Even when it's not visible, the Ribbon is supposed to hide itself.
Sign In or Register to comment.