New "Background" property

MARTINDRENOVAC

After upgrading from SRP Controls 3.0.6 to 3.0.9, Status Bars in my application are now white (blank). See screen prints below taken from the FrameWorks MDI frame.

I suspect it has something to do with the new Background property. I do not yet use this new property, but when I tried setting it, it had no effect. Any thoughts?

I am using OI 9.3.2.

StatusBar rendered under V3.0.6


StatusBar rendered under V3.0.9


Code to render StatusBar

KevinFournier

You might want to try re-registering SRPControls.ocx. That screenshot looks like the control is not loading correctly at all.

MARTINDRENOVAC

Hi Kevin,

I did re-register the control. It had no effect. OLE Info shows my controls as Evaluation versions. Can this be causing it?

Don

KevinFournier

If you are using SRP OLE Info.exe, you will always see that for SRPControls.ocx. You should be using SRP_ActiveX_Info.exe instead, which ships with the SRP Editor.

This really should be resolved by a re-registration. Perhaps you can try commenting out lines of code that setup the status bar and see if returns to normal. If it remains white, then that tells me the registration didn't take for some reason.

MARTINDRENOVAC

Well, commenting out code doesn't seem to work. I can unregister and register SRPControls.ocx version 3.0.6 successfully. It works fine, just not the new version. Also, I did use SRP_ActiveX_Info.exe and it showed all controls as evaluation versions. But it's been this way a long time and hasn't been a problem so far.

One thing confuses me. Doesn't registering SRPControls.ocx register all the controls. That is, if it didn't register, wouldn't all the controls look like the Status Bar? Is there a specific place in the registry I need to check?

DonBakke

Does the status bar look like this on all your forms? Does it look like this in the SRP Editor? Can you verify that the ProgID is correct on your form? I know I'm resorting to shooting in the dark, but this is pretty strange behavior. I have been using 3.0.9 since it's release and I have dozens of forms with SRP StatusBars and haven't experienced this.

Have you tried turning your machine off and on again? :-)

SRP_ActiveX_Info will usually show everything as evaluation if it can't find the SRPLicense.dll, which needs to either be in the same directory as SRP_ActiveX_Info or in C:\Windows\System32 (SysWOW64 in x64 systems). Can you post a screenshot of SRP_ActiveX_Info?

MARTINDRENOVAC

1) Yes, the status bar looks like that on all forms in the application (there's only two).
2) Until now, I hadn't thought to look at the Status Bar in the editor. It's so small, I didn't notice it. But now that I Look, it does work properly in the Editor (version 2.5).
3) All forms show SRP.StatusBar.1 as ProgID.
4) I haven't tried turning the PC on and off. I'll try as soon as I post this message. If it works, I'll let you know.
5) Screen print:

DonBakke

Don,

I think Kevin is probably working with you directly to test the v3.1.0 release candidate of the Pro control. However, I did want you to know that I confirmed your license as being valid. The "Evaluation Version" messages you are getting is very unusual. I have to assume something went horribly wrong with the 3.0.9 version of the control (but no one else is saying anything) or somehow your version got corrupted in some way.

Please let us know how you make out.

Thanks.

MARTINDRENOVAC

Don,

The v3.1.0 release candidate did not work. Some more information that might help:

1) SRP_ActiveX_Info has always shown evaluation versions. This is not something new. In fact, before that SRP OLE Info also had shown evaluation versions. It has never caused any problems and I have never got a nag screen. I mentioned it because it was out of the ordinary and that maybe now for some reason it might be related to the problem I'm experiencing.

2) I tested version 3.0.8. This also causes the problem. As I said 3.0.6 works fine, so I'm guessing that something is different starting with version 3.0.8.

Hope this helps.

DonBakke

Don,

Would you be willing to send the following to me in a private email?

1. Your OENGINE.dll
   
2. Your SRPLicense.dll
   
3. The 3.0.9 SRPControls.ocx that you are using?
   

I would like to see if I can replicate this on my end in hopes of narrowing this down further.

MARTINDRENOVAC

They're on the way.

KevinFournier

So, Don was the one that tested the files you sent, and he could not recreate the issue. We're quickly running out of options, but I do have a couple more ideas to try:

First, I will be emailing you a new SRPLicense file that licenses all the individual OCXs in addition to the SRPControls.ocx. As a test, I'd be curious to see what would happen if you unregistered SRPControls.ocx and registered SRPCore.ocx only. Of course, your other controls won't work, but it's only a temporary test to see what happens to the StatusBar control specifically.

Second, I would be interested to see if this is a promoted events issue. If you use SRP Frameworks, I know that it intentionally bypasses all promoted event logic for the SRP Editor, which might explain why you are not seeing an issue with the SRP Editor when you see it everywhere else in your application. If you can recreate the issue in a clean copy of OI, then you could package it into an RDK and send it to us.

Hopefully we can solve this mystery soon. Thanks for bearing with us.

MARTINDRENOVAC

Kevin,

I tried your first suggestion. All the core controls work, except the Status Bar. So I guess we're sort of back to where we started.

I'll try your second suggestion and let you know what I find.

While I'm doing second one, is it possible that there is some spurious registry entry related to the 2.0 controls that were used previously? Would it help to email you a screen capture of all the SRP registry entries?

Don

KevinFournier

The registry entries that really matter are the ones created when you use REGSVR32, so I don't think it will help. I do create custom registry entries for each control, but it's only for convenience (just the location of the OCX file really). It would not affect the functionality of the controls at all.

MARTINDRENOVAC

Well, I think we're starting to narrow the problem down. I created a test form with just a status bar that does not use promoted events and the Status Bar displays ok, except that it's unsuccessfully trying to display a gripper by default. See below:



So far I have removed all the code for the Promoted Create and Activated events, but the Status Bar still will not display on the Frame.

KevinFournier

That is how the gripper is drawn now. If you want the gripper to appear on the "inside," you should use the new Background property instead.

While it still appears to be a mystery, I think we've confirmed that more investigation needs to be done in your application. The best help I can offer at this point is to acquire a copy of your app that I can debug from within Visual Studio.

MARTINDRENOVAC

Thanks for the offer. Before I do that, I'd like to spend some more time looking into this.

For example, I have a progress dialog that does not use promoted events, but has the same display problem as the MDI Frame. So, it may not be related to promoted events after all.

I have removed virtually all promoted code and the Frame's status bar still will not display.

Well, I'll let you know what else I find, or if I finally cry "Uncle!". : )

DonBakke

Don,

I always like to recommend that testing be done in SYSPROG or the EXAMPLES application to remove any interference from additional processes. Of course, this assumes you have not messed with SYSPROG. ;-)

Don B.

MARTINDRENOVAC

Well, I can only say, Uncle!

I've sent Kevin a copy of the application. I'm not sure it helps, but here are more observations:

I had forgot to mention that the Status Bar on the Test Form run in Form Designer that I showed earlier only displays properly if I click on the form after the window displays.

Noticing the above behavior, I ran a program that forces the Progress Dialog to appear and I clicked on the dialog window. The Status Bar then displayed properly, and for some reason has worked ok ever since. Go figure.

Neither of the above forms use promoted events.

Thanks.

Don

DonBakke

It would appear that we never closed this discussion properly.

For those who were monitoring this thread, we have solved the issue. The fix is to simply change the Prog ID in the Form Designer to something else (like another SRP control) and then back.

The cause of the problem is OpenInsight's approach toward storing OLE control property information within the form template. If an OLE control is modified (as was the SRP StatusBar), then this can cause an incompatibility with the information that OpenInsight stores in the form template and the current control. Thus, in order to refresh the information that OpenInsight stores the Prog ID needs to be changed. Alternatively, the control could be deleted and then created again.

AusMarkB

Don,

Thanks for posting the solution to this one. I just had the same issue and resetting the Prog ID did indeed resolve it.
Have there been any other controls that you're aware of that have had similar issues where this is the resolution?

Thanks.

DonBakke

Mark,

The only consistent problem has been with the SRP StatusBar control. However, any control with new properties should, in theory, be problematic. I have a vague recollection of one other control exhibiting a similar behavior. Unfortunately I cannot recall which one it was. I do know, however, that it only happened in one situation whereas the SRP StatusBar seemed to be rather universal.

AusMarkB

Thanks Don