Adding to what Chris said, here is example of what you can achieve with PowerBuilder 2022 R3: https://www.appeon.com/products/powerbuilder/ui-modernization

I'm not sure you can dynamically change the Tabpage colour using Themes depending upon data? Yes you can change the Tabpage object colour within a Window or User Object but not when data is different.



Yes, you can do a lot with Themes but retro fitting it to an application can be a big job. Having just completed a UI upgrade on a big system where the users were allowed to select 2 themes (Dark or Silver) or classic (No Theme). The work required to map existing colours used for hilighting data etc was massive. Refactoring Windows objects like Rectangles that are not supported in Themes and changing all the images to match the Theme on both Menus, buttons, treviews etc. It was a much bigger excise than just applying the Theme. The Dark theme was particulary problematic due to most text and backgrounds being reversed. This required a lot of remappig colours. Who knew that buttonface had so many different PB colour numbers over the years! Anywhere that transparrency was used just does not work.



Having said that the only option availble to you guys is to change the Text Colour or add an image to indecate different data senarios. That works quite well and users will be happy with that approach.

If you look at the OrderEntry demo app from the STD Framework, you'll see examples of the proper design & use for inherited TC & TPs in a real life scenario. HTH

I understand perfectly well HOW to do it, Chris. PB's restriction in not being able to edit a visual class when it is already in use in another painter is what makes that approach completely unworkable for me (and many others). I think the restrictions and limitations of the design/editing process makes the technique impractical and unworkable just to obtain a "better" or more well-formed object-oriented design and implementation. Just my 2 cents.

Over my career, my employers and clients never cared a hoot if I strictly adhered to so-called best OOD principles, but they cared a GREAT deal if a window took 2-3 times (or more) longer to create or modify than it should - and that's what results when you use CVUO's as tab pages.

Great in theory - Unworkable in practice.

This has been a huge weakness of PB forever, and I'm hopeful (from what I hear) that PB 2025 will FINALLY address this glaring deficiency in the product. I have no problem hugging my DataWindows, but I want to strangle CVUO's used as tab pages.

=> PB's restriction in not being able to edit a visual class when it is already in use in another painter is what makes that approach completely unworkable for me

No problem for me but, I have been used to that since PB 3.0 when that restriction came into play. PowerSoft added that restriction because too many developers were "shooting themselves in the foot" (so to speak) because they were modifying various Base, Abstract and / or Concrete level classes in the same inheritance hierarchy at the same time. Hence the PB IDE was making mistakes based on what updated class(es) were saved first and in what order.

Personally, I love this restriction because of the potential pitfalls it blocks and it ensures that the IDE always has up-to-date ancestor code to compile when an object class change(s) are saved. ;-)