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

Tabs and clear event issue

Hi team

Thanks for the invite

We have an issue which occurs consistently on both XP and Win7 re: non-re-rendering of SRP controls following a CLEAR event, when during the clear event any control has its VISIBLE property set. This issue only occurs if there is an SRP.Tab.1 control present in the form, hence why I'm posting this message in this area - feel free to move it elsewhere if more appropriate. We are using OI 9.3.1 and SRP Control info is below also.

Steps to reproduce are:
• Create form with SRP Tab and some SRP buttons.
• Have a button fire SEND_EVENT(@window, ‘CLEAR’)
• Within the commuter routine, set another field to visible or invisible (e.g. set_property(@window:’.EDT_DESCRIPTION’, ‘VISIBLE’, false$)) during the CLEAR event

All the srp controls disappear from the screen after the CLEAR event complete. If you subsequently mouse-over these controls they do get re-rendered.

In our promoted CREATE event we set the following property for the tab control, however removing this made no difference:
set_property(@window:'.OLE_TAB', 'OLE.FlickerFree', true$)

Hope this helps, please let me know if you need anymore info.

Commuter code below:

compile function TESTING_EVENTS(focus, event, param1, param2, param3, param4, param5, param6, param7, param8, param9, param10, param11, param12, param13, param14, param15) system $insert logical declare subroutine set_property, send_event valid = true$ window = field(focus,'.',1) control = field(focus,'.',2) begin case case control = ;* form events begin case case event = 'CLEAR' set_property(window:'.EDT_TEST', 'VISIBLE', false$) end case case control = 'BTN_CLEAR' if event = 'CLICK' then send_event(window, 'CLEAR') end end case return valid eof *****

License info:

SRPControls.ocx

Version: 3.0.4

Controls

SRP Button Control, 3.0.3 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP DatePicker Control, 3.0.1 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP Editor Control, 3.0.1 RC1 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP EditTable Control, 3.0.1 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP Hyperlink Control, 3.0.3 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP Launcher Control, 3.0.0 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP Panel Control, 2.0.0 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP Picture Control, 3.0.3 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP Popup Control, 3.0.0 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP ReportTable Control, 3.0.1 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP Schedule Control, 3.0.1 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP ShortcutBar Control, 3.0.2 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP Sketch Control, 1.0.0 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP Splitter Control, 2.0.0 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP StatusBar Control, 3.0.3 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP Subclass Control, 3.0.0 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP Tab Control, 3.0.3 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx
SRP Tree Control, 2.0.1 -- License expires on 02/08/2013 -- \\dgtdevtest\devapps\revsoft\openinsight\srpcontrols.ocx

User: James Birnie

Comments

  • Hi James,

    Thank you for taking the time to post your question in the discussion forum. I tried to replicate your problem but was unsuccessful. To make this easy on me I just added an OI push button and an SRP Button control to my DBW_SAMPLE_3 form. I then added code to my commuter module accordingly:

    Trapping the Event
    Case Control EQ 'PUB_CLEAR' Begin Case Case Event EQ 'OnClick' ; Send_Event(@Window, 'CLEAR') End Case Case Control EQ 'PUB_CLEAR_2' Begin Case Case Event EQ 'CLICK' ; Send_Event(@Window, 'CLEAR') End Case
    Hiding a Control During the CLEAR Event CLEAR: Send_Message(@Window:".OLE_EDITTABLE", "OLE.Clear", 1) ; // Blank out edittable and fill up with empty rows Set_Property(@Window : '.OLE_EDITTABLE', 'VISIBLE', False$) return
    When I click on either button my SRP EditTable disappears but everything else remains as expected. Am I missing something in my attempt to replicate your situation?

    I wonder if there are other configuration differences that are making a difference here. I also noticed that the tabs disappeared even though the tab border remained. Do those render when you hover the house back over them? Is the SRP Tab control set to All pages?
  • Hi Don,

    Yep you have to login to post messages... fancy that! Embarrassing

    Here's my first message for posterity:

    Hi Don

    Hope you had a good weekend, thanks so much for the reply.

    I adjusted DBW_SAMPLE3 as you did, and saw no issue (windows 7), however the developer who raised the issue (XP) does see the same issue with the same DBW_SAMPLE3 form. I tried on 2 more XP machines and they had the same non-rendering issue - so there is something different environmentally... Maybe a C++ runtime update might help for them

    To answer your questions:
    • Yes the tab is set to “All Pages”
    • Yes the SRP controls (tab and buttons only on this particular form) that disappear do re-render during mouse-over

    We setup a few other properties around the TAB to standardize its look and feel and this looks like the problem, e.g. if I add the following code to the CREATE event of DBW_SAMPLE3 you should see the issue now I think?
    startgradient = 16777215 endgradient = 16772313 NmlBackground = 'Vertical(Gradient(':endgradient:', ':startgradient:'), Border(OfficeFrame))' ;* Border(Blue) SelectedBackground = 'Vertical(Gradient(':endgradient:', ':startgradient:'), Border(OfficeFrame, OfficeFrame, OfficeFrame, None))' ;* Border(Blue) PaneBackground = 'Vertical(Gradient(':startgradient:', ':endgradient:'), Border(OfficeFrame))' DisabledBackground = 'Vertical(Gradient(Gray L=80, Gray L=90), Border(OfficeFrame))' HotBackground = 'Orange' SelectedText = 'Blue' DisabledText = HotText = 'Blue' ColourScheme = ColourScheme<1,2> = NmlBackground ColourScheme<2,1> = HotText ColourScheme<2,2> = HotBackground ColourScheme<3,1> = SelectedText ColourScheme<3,2> = SelectedBackground ColourScheme<4,1> = DisabledText ColourScheme<4,2> = DisabledBackground ColourScheme<5> = PaneBackground set_property(@window:".OLE_TAB", 'OLE.TabColors[All]', ColourScheme)
    ** response to last email **
    That AVI you sent looked fine to me. As I mentioned this happens on all our machines now. The Win7 boxes aren't using the AERO theme, but the rather boring windows one.

    One difference was I am setting
    set_property(window:'.EDL_FIRST_CONTROL', 'VISIBLE', false$)
    in the CLEAR event, however if I change this to the report table I see the same issue.

    I am running the form from within OI not within Frameworks (but still getting promoted events of course).

    Do any of these things make a difference by any chance?

    User: James Birnie
  • James,

    I'm not sure I understand what configuration seems to replicate the problem every time. Allow me to ask some detailed questions:
    • Does the problem occur in Windows 7?
    • If so, does it occur when Aero is turned on?
    • If Aero has to be turned off what theme are you using? (e.g., Windows Standard)
    • Does the problem occur in WinXP?
    • If so, does it occur when XP theming (e.g., Luna) is turned on?
    • If Luna has to be turned off what theme are you using?
    • Does it matter which control you make invisible during the CLEAR event?
    • Do you have the AllowXPTheme property turned on, off, or do you not set it?
    For what it is worth, I turned off Aero on my Windows 7 machine (Windows Standard) and tried several ways to replicate with no success.

    Thanks,
  • Hi Don,

    Thanks again for the response. Sorry I wasn't clear, I'll go through your questions below.

    1. Does the problem occur in Windows 7? Yes - but only when I set the OLE.TabColors[All] property as per last mail, without this setting of the property it renders fine.
    2. If so, does it occur when Aero is turned on? I can't check this sorry - our PCs are locked down to 1 theme.
    3. If Aero has to be turned off what theme are you using? (e.g., Windows Standard) I think its called "Windows Classic" - its the one that looks like Windows 2000.
    4. Does the problem occur in WinXP? Yes - always (XP is running the Windows Classic theme also). As mentioned in q.1, it did not require the OLE.TabColors[All] property setting to have controls become invisible, unlike Win 7.
    5. If so, does it occur when XP theming (e.g., Luna) is turned on? As per 2
    6. If Luna has to be turned off what theme are you using? As per 2
    7. Does it matter which control you make invisible during the CLEAR event? No - either an OLE or OI control has the same effect.
    8. Do you have the AllowXPTheme property turned on, off, or do you not set it? We set this property for srp.tab controls only to false$ (0).

    Hope this helps, I wish I could have tested the other themes. I noticed your DBW_SAMPLE3 form looked slightly different so am wondering if something may have changed here - I'll email you through a deployment of this form + commuter from our side.

    Thanks for you help,
    James

    User: James Birnie
  • Hi James,

    Your answers are very clear but, unfortunately, the solution is not. I loaded the RDK you sent me (then realized I needed to create your app! ) and I also had to change the CLICK event reference to OnClick because I don't swap the event names the way you do. After that I got the window to run just fine except that everything works as expected. Here is another AVI for you to download to confirm that my system looks like yours:
    Tab2.zip 116.7K
  • Hi Don

    Thanks for the info, thats video looks exactly like mine (well except for the disppearing controls following the click..). I should have mentioned the ORYX account in the deployment sorry.

    Hmmm I'm not sure where to go from here? I noticed that the controls are at 3.0.5 but we are on 3.0.4, so would it be worth upgrading this tomorrow before the other guys get here to give it a go?

    User: James Birnie
  • Hi Don

    Actually one thing I did notice is that it looks like maybe you system isn't using OI windows colour settings? Set via Database Manager -> Database -> Environment Settings -> Windows/Form Settings [tab].

    "Set a Default background for all windows" is checked, and goes from a white to a light blue.

    I turned this off exit/re-enter and still see the issue tho, so I'm guessing this isn't it.

    User: James Birnie
  • Hi James,

    You are correct, I was not using OI window color settings. You are also correct in that it didn't change anything for me. :-)

    I doubt 3.0.5 will make a difference regarding this issue but it never hurts to upgrade. That's one of the benefits of using the Pro control...just one file to replace.

    The only other way to rule out OI or the SRP Tab control is to get a full copy of your system and test in-house. I realize that might be impracticable but I can't think of any other way to help positively eliminate OI out of the equation. A long time ago we used to have performance issues with certain features of the SRP EditTable but only on certain machines. While this was not a rendering issue, it did demonstrate that certain machines are more sensitive than others for whatever reason.
  • Hi Don

    I couldn't update the controls this morning, I'll attempt next server cycle. It looks like the Srp.Tab version hasn't changed, so I'm not too confident this is it either. But we will see. ;-)

    I am happy to give you a copy of our system and have some idea of how much of a pain this will be for both of us... thanks so much for the offer. I'll run it by Kyle and see what he thinks.

    In reality this particular issue can be worked around, but like you I'm sure it would be really good to know the real cause. We saw a similar issue under SRP 2.x controls - once again only when using SRP.Tab (I think Mark Boorman laised with your team over this one), however we haven't seen this under SRP 3.x until now.

    My PC is a relatively new one, however the others are due for replacement within 6 months. All do not have dedicated graphics cards i.e. use virtual intel graphics instead.

    User: James Birnie
  • Hi James,

    Ah yes, the old problem Mark brought to our attention last January. I forgot that there were some similarities between that issue and this one. At that time the problem was occurring when a control was made invisible during the SelChanged event of the SRP Tab control. Fortunately in that situation once we discovered the magic formula the problem occurred for everyone and all the time.

    Interestingly enough, we got to the root of that problem through several RDKs that Mark sent. it was quite the entire application, obviously, but sufficient for me to see what he was seeing.
Sign In or Register to comment.