Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
OI10 & Tab Control
I recently added an SRP Tab control to an existing form in OI9 as I have done many times before. All works as expected. As this form has been around forever, there are several OI buttons with images in the old toolbar fashion.
No real problem with that until, the form was migrated to OI10.
With the tab control added, the OI buttons no longer display the images at runtime. They do display them in the OI10 form designer but at runtime, no images.
Remove the tab control and the buttons return to displaying as they should.
Changing the buttons to SRP buttons, (which do behave correctly), is a nice idea but not a realistic endeavour.
Too many buttons on too many forms.
No real problem with that until, the form was migrated to OI10.
With the tab control added, the OI buttons no longer display the images at runtime. They do display them in the OI10 form designer but at runtime, no images.
Remove the tab control and the buttons return to displaying as they should.
Changing the buttons to SRP buttons, (which do behave correctly), is a nice idea but not a realistic endeavour.
Too many buttons on too many forms.
Comments
For now, the work around is to not set the AllowXPTheme property at all, even if you are currently setting it to 0.
Will be keen to hear of a resolution when you come up with one though.
This is how SRP Tab knows to leave a bitmap button alone. If it sees the BS_OWNERDRAW flag, it ignores the button when it subclasses other controls on the form.
OI 10 no longer uses this technique, so the SRP Tab has no way whatsoever to distinguish between bitmap buttons and regular buttons. Moreover, SRP Tab doesn't have access to the presentation server, so it cannot access OI specific settings or the button's image. Thus, we are in an all-or-nothing situation. If you want to preserve the old bitmap buttons, you'll need to avoid setting the AllowXPTheme property at all, which means other controls will look funky when place within the SRP Tab pane.
It would seem the path of least resistance would be to upgrade your buttons to OI 10 buttons or SRP Buttons.
This is one of several reasons why moving to OI 10 is a port, not an upgrade.
Thanks for looking into it Kev.
We'll change the buttons to SRP buttons wherever we've implemented the SRP tab.
Looking at it from that perspective, it's not as big a job as first perceived.
We'll just now know that moving forward, if we switch an OI "Tab" to the SRP tabcontrol, it will include the changing of the buttons as well. Switching the tabs was a relatively quick way to improve overall appearance. Will still follow that path but will likely be a little more selective as to when.
The scenario is, we're still developing in OI9 and then periodically porting to OI10 so that when we're ready, we're ready.
Changing to SRP buttons in OI9 means doing it once. Changing to OI10 buttons means redoing it everytime we recreate the OI10 environment.
Changing to SRP buttons in OI9 means doing it once. Changing to OI10 buttons means redoing it everytime we recreate the OI10 environment.
Ah, yes, that makes sense.
We always suspected the SRP Tab would be problematic in OI 10. SRP Tab was the second control ever created, back in OI 4.x, and it does a ton of hooking, clipping, subclassing, and custom drawing to make the effect work. Since OI 10 has a new composition-based presentation server, it's likely all those smoke-and-mirrors are causing havoc.
OI 10 has improved its controls a lot. We do recommend using them whenever possible. I figure the future of SRP Controls will be specialty controls.
OI 10 really is a different beast. Moving from OI 9 to OI 10 is more akin to moving from AREV to OI.
When redrawing the controls, the text justification is being lost. I assume that's because in 10, they're no longer just "left" or "right" but include vertical and horizontal in one property.
The image shows what it should be and what it becomes when the tab control is initialised
There. Fixed it for you @DonBakke :)
Maybe I am special but I can drive on either side...so Ambidriverous? Is that a word? If not, I claim it for my double sided driving proficiency!
I am 100% with @AusMarkB on the lining up. Left just looks...weird.
(even in my old Oracle days I would line right select keyword code as it just reads WAY better than any formatter I came across:
select city_code, count(*) from client_addresses where city_code is not null and country_code = 'AUSTRALIA' group by city_code having count(*) > 50)As for the coffee I grew up as a young whippersnapper on U.S. drip filtered. I discovered the joys of an Italian espresso at a young age. As a poor Uni student I made do with Instant. A previous GF liked a French press. As a gainfully employed adult I favour a quality Aussie flat white. I've worked in places that have done strong Turkish/Lebanese brew that definitely put some hairs on my chest! I am ok with them all (Ok, maybe not the instant anymore!) because you get used to it but I do think Aussies overinflate their coffee as the best ever but, in fairness, it IS far better than most out there.
@DonBakke, if you have not become enamoured with the joys of the bean then I can only assume you mainline RedBull for your fix?
All joking aside, I do see some merits in right aligned labels. I think the greatest benefit is that it associates the label with its control a little better because the eye does not have to traverse so much space. But that space has to go somewhere.
My OCD sees forms as concentric rectangles. The form itself is a rectangle, tabs, groupboxes, editboxes, and edittables are rectangles. Then someone right aligns a group of labels and...wham!...those jagged left edges just look wrong and break the paradigm.
I also find that it is hard to be consistent with right-aligned labels. For instance, you put a label on top of its associated control. How do you align it then? How about checkboxes when the label is on the right side of the box?
How would you have designed this dialog?
I'm not understanding you. What changes are you referring to?
This is a bug, likely due to the reasons that Mark proposed. Kevin is on holiday until next week. I'm certain he will look into it when he returns.
@Opto_Will I think you can claim that one as your own, so long as it's not confused with Ambidrivelous, which is those people that have a tendency to ramble on ambiguously, leaving one ambivalent as to whether you should slap them out of it with your left or right hand
Just got back to OI10 today and gave this a test.
The text alignment works thank you.
but there's always a but....
Upon closing the form, and I tried a couple, the mdiclient area redraws itself incorrectly ignoring the ribbon.
So technically I guess it's correct if there wasn't a ribbon control there which now gets lost underneath the client area.