Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Background Color.
Where does the SRP Editor get its background color from?
I have always thought it was from the DB Manager Env settings .
I have changed that in many OI instances and have had a color coded environment indicator (great for our DevBox multi-environments but also onsite where clients have Test areas, etc)!
The reason I ask is I just created a new OI environment as a copy from an old one (which had a light blue background as you can see below)
I changed the DB setting to be a purplish and almost everything else has changed except the SRP background. DB Manager, Table Builder and even within the Editor the Tools-Options and Find are all the expected color! Just not the main Editor Frame!
I deleted the SRP EDitor HKCU registry entry for that location and it didnt seem to make a difference
What am I missing?
Side note: Interestingly Table Search does not seem to pick up that background color
I have always thought it was from the DB Manager Env settings .
I have changed that in many OI instances and have had a color coded environment indicator (great for our DevBox multi-environments but also onsite where clients have Test areas, etc)!
The reason I ask is I just created a new OI environment as a copy from an old one (which had a light blue background as you can see below)
I changed the DB setting to be a purplish and almost everything else has changed except the SRP background. DB Manager, Table Builder and even within the Editor the Tools-Options and Find are all the expected color! Just not the main Editor Frame!
I deleted the SRP EDitor HKCU registry entry for that location and it didnt seem to make a difference
What am I missing?
Side note: Interestingly Table Search does not seem to pick up that background color
Comments
I even just resinstalled the latest Editor.
I know its something on my end because this is the first 'fail' of maybe 50 times I have done this.
I just cant for the life of me work out what is blocking the change for that one thing.
I figured it as a very 'pushy' setting considering everything else it changes.
Interesting that Subclassing has some OI Kyptonite! Begone foul color villain!!!!
@KevinFournier
When you say 'set to System', is that different to the DB settings I noted?
I can see in the SYSREPOSWINEXES where the COLOR ID is stored for the Editor.
On the system I noted it has the 'LIGHT BLUE" ID <1,17>, even thought the DB ENV is set otherwise. On other systems I have changed the DB ENv setting, those records show the correct color match. Is there another setting that might be set for that one environment I am missing?
As an aside , I took this information and modded the Table Search form for my 4 Main Development areas. They now match colors correctly :) Good tip Kevin.
I dont know what it found but it is only in that that source environment and I cant seem to unset it.
I know how to workaround it now but honestly, I thinK I will just rebuild the affected environment new from the normal deployable environment rather than the one it is currently created from (our Production Master system) that clearly has a 'feature'. It will only take a short time to do that.
Thanks for your help.
Problem solvered!
Once they were ready to go live, I copied that app, changed the same settings as you, to something more appealing. It all looked nice again.... except.
Any OI message boxes and maybe popups retained the pink colour. I couldn't find any reference to that colour scheme anywhere and no amount of restarting anything rectified it.
It annoyed me for a while because I hadn't set the colours to pink anywhere other than that one place, and I had definitely reset that same setting, yet some stubborn instances just wanted to be an ugly bright pink.
Eventually I just consoled myself with the idea that they only saw pink when it was a really important message. :)
I actually dont mind the color, I just need it to be differnt to all the other dev environments on that server.
I find it really helpful when you have multiple OI instances running that, at a glance of color, you know which Editor/Table builder/DB Manager etc you are in. Having at production ennvironment Editor the same color as a Development environment is a surefire way of me doing something in the wrong window!
I was able to manually adjust the various SRP Editor form/dialog/popup colors in the repository but I suspect an install of a new version will revert that so when that happens I will just build a new environment from a instance without the problem. Seems easier than trying to track down the offender from the setting of the System default.
I modify the caption on the application manager and just check that with a scroll over the taskbar whenever I'm in doubt.
I also use Custom login and FW_MAIN background images where I can for our Test areas.
Every little bit helps...
Mind you, after taking this screenshot, I just opened the screen on the right in form designer and resaved it and voila, it is now consistent with the desired scheme.
So simple fix this time but a nuisance that it had to be done.
I can see why Rev would do it this way, as it's reliable in making all windows the same. The problem is in the wording on the dialog, "Set a Default Background color for all windows." It should read, "Replace the background color for all windows."
I also note that not everything would get updated. For example, while the SRP Editor would take the color immediately, not every single called form / dialog from it does. I can veryify this by interrogating the SRP_EDITOR SYSREPOSWINEXES records after the toggle...
I want to understand this better. Are you saying that you have seen SYSREPOSWINEXES records modified when updating the default background settings in the Database Manager?
I never looked at the SYSREPOSWINEXES until a couple of weeks ago for the noted issue here. When I did, I saw that the entries had the value of the color I wanted in other systems whereas the system I had an issue with did not.
So I just expermiented with a test in a old, untouched by color, system
(I restarted OI and the Editor after every step to make sur enothing was cached)
Changing the color from default 'No Override' WhiteID did NOT immediately change the SYSREPOSWINEXES entries. They still kept the default White ID (16777215). The Editor DID show the new color as expected. Diff tool showed no change to the record.
Upgrading the Editor in that environment DID save the new color ID in SYSREPOSWINEXES.
This replaced the singular default White ID value, as well as setting a new SubValue to the new color ID as well (there are are now 2 SubValues in that Value in the record and now the first is set, while the last is 0. See below.)
Changing the Color ID now no longer worked (basically my issue). It stayed at the color as it was at the last install. Re-Installing the Editor updated the values to the new color ID and the color was now as expected.
Diff tool after Editor installs showed 2 changes to the record, which is what I am guessing is 'locking in' the color....
Default:
Changed Color.
So my conclusion is the first changed value is the toggle (to override color or not) while the second value set are the actual values (From Color / To Color). These, for the Editor, are now hardcoded into the form executable and will not change until a new install happens.
I can only guess that I have been lucky not to stumble across this before. Basically any system copy must have been from a non color override environment which has subsequently allowed me to change the color. This is probable.
Also, changing the color in a non-overide system will happen automatically and can be done multiple times as the Editor form is compiled to use whatever color the System says. This is probably where all my confusion stemmed from because I have definately done this plenty of times.
However, once the Editor is installed in a system with an override color then thats how it will stay until next install...
Am I to infer that you believe the override color gets applied when the SRP Editor is installed?
Pretty much.
For the Editor, yes.
The rest of the system tools (DB Manager, Table Builder , etc.) change color immediately with the DB environment setting change everytime. At least that has been my experience.
1. The SRP Editor seemingly compiles the current system status in at install time. If there is no color override at that time then the Editor stores that fact (as well as the White ID but I dont actually think that is important here) and will use whatever the system color is set to be (which is, in this state, is actually reflective of the the DB Enironment setting!!). This I assume is most cases.
2. If at Editor install time there is a color override, then that fact, as well as the new color, gets compiled into the runtime and that is the color that the Editor will foreever appear as since the Runtime form knows there is an override and has the color embedded, regardless of what the DB environment is now set to.
3. The next install of the Editor embeds the current state again, which may be:
- the same color as previous if no DB change
- a new color alltogether (what I needed for my issue)
- potentially no color if the DB override had subsequently been removed after the previous Editor install
I assumed (1) always happened.My probelm existed because of (2).
Thanks to the testing for this post, I understand why (3) fixes my problem!
Clear as mud in my head now :)
Edit: I should also be clear, I don't believe the DB Manager updates the WINEXES. I think the System tools must be compiled with the 'no-override' so ask the System what color to use and that is whatever is currently in the DB encironment.
Therefore, I think it all comes down to that '0X8100' instead of '0X100' being embedded into the runtime. If the Editor install kept the '0X100' I think it would display whatever color the DB was set to be, regardless of the embedded colors.
(This is a guess and I have not tested it)
To be clear, I'm not disputing your findings. If you are physically observing changes taking place as you described, then I will accept your reporting at face value. I am disputing what is perceived as the normal way this works. My tests were done with a clean OI 9.4.6 and the latest version of the SRP Editor.
I am definately NOT disputing your findings. It makes total sense you are deploying an already compiled runtime.
I think we can very quickly agree that the systems I inherited are anything BUT 'clean'!
Try again on another System.
Default
(changing color in this state displays the color selected while maintaining the SYSREPOSWINEXES values)
Change Color and install Editor:
Mind you, all the systems I have access to are taken from only a couple of different sources so any issue will be pretty much everywhere. So I wonder what it is that makes our setup so special?
I am thinking of going to OI so I can get an Auth Code for 9.4 Full that I can then upgrade to 9.4.6 for a clean copy on hand (unless I was mistaken that 9.4 was the last 'Full' installer?). I have had a need for one a few times as of late.....
I did however, just stumble over a more direct example of what I was referring to in my original post.
Here, the application and the one it inherits from both have the same bluish background colour settings in sysenv, yet check out the colours of the rev windows.
There's no doubt that at some point in time, somebody added those orange colours to the settings but I don't see any trace of them now. Sysprog itself doesn't have any background colours set. Well, the blue colours are in the fields but the flag to use them is off.
I guess that means that somewhere, sysprog thinks its default colours are an orange gradient.
Maybe that's the key to the mystery...