Thank you very much Theo, often "skinning" mean adjust objects on forms, but this is a nice starting point! Is there a way to centralize different color profiles, without having to change the file before the application starts? Regards Claudio

Hi Claudio In my case I implemented skins based on PNGs and background colors. 

• Every form has an operation called theme that changes its own skin (background colors and PNGs at buttons) and executing "show". Another approach I discarded was dynamically change glyphs based on nomenclature but doing so user help and manual would be more complex to maintain. 
• There is a global variable that keeps current skin. 
• And there is a point in the app from where skin can be changed. This point triggers the operation theme for all forms in execution.

Also in ini file, I defined "usystheme=project_folder\\theme\\" so every PNG can be changed with $concat("@usystheme:", $$UMO_VCTHEME, "\\button_def.png"). That is, every button has its own glyph AND a backgroud PNG. As $$UMO_VCTHEME can hold 1, 2 or 3... it is mandatory that exists these PNG at project_folder\\theme\\1, project_folder\\theme\\2 and project_folder\\theme\\3. Result:

Hi Luis, nice concept. I assume the point to change the skin is somewhere topmost in the application. Or do you have some solution for the "change skin when returning to an existing form after the change" which doesn't consume a lot of performance checking the change? Perhapts triggering a skinchange operation in all existing components or so? Greetings from 7°C Frankfurt to a hopefully warmer Spain, Uli

Thanks Uli.  It's nice. I developed for a GUI modernization demo in an User Event.  It is in start-up shell. It receives an Asynchronous message from settings form and call every $detachedinstace and $instancechildren (recursively). It's a blink. There are about 20 forms involved including tabs, non-modal forms and form containers. The images are very small 1-5KB except the biggest one that is a background of 29KB. Also, every form starts by setting properties according with current theme, so skin remains always coherent with $$UMO_VCTHEME.   Windy and sunny. Ideal for sailing with a boat, if you have any. 

luis.vila said Hi Claudio In my case I implemented skins based on PNGs and background colors. 

• Every form has an operation called theme that changes its own skin (background colors and PNGs at buttons) and executing "show". Another approach I discarded was dynamically change glyphs based on nomenclature but doing so user help and manual would be more complex to maintain. 

• There is a global variable that keeps current skin. 

• And there is a point in the app from where skin can be changed. This point triggers the operation theme for all forms in execution.

Also in ini file, I defined "usystheme=project_folder\\theme\\" so every PNG can be changed with $concat("@usystheme:", $$UMO_VCTHEME, "\\button_def.png"). That is, every button has its own glyph AND a backgroud PNG. As $$UMO_VCTHEME can hold 1, 2 or 3... it is mandatory that exists these PNG at project_folder\\theme\\1, project_folder\\theme\\2 and project_folder\\theme\\3.   

Thanks Luis, very very interesting! Unfortunately, it is impossible for me to implement, because I have 1000+ forms in my app . But the result is very nice! Bye from windy north of Italy Claudio

Hi Claudio, even with 1000+ forms:   Assuming you have followed some coding standards, all you need is some clever supporting tool to place the code into the existing forms. Once you got some basic templates to do the job, it takes only a couple of hours to adapt. I used it in my now nearly 25 years with uniface a lot to do bulk modifications (especially on migration jobs).

ulrich-merkel said Hi Claudio, even with 1000+ forms:   Assuming you have followed some coding standards, all you need is some clever supporting tool to place the code into the existing forms. Once you got some basic templates to do the job, it takes only a couple of hours to adapt. I used it in my now nearly 25 years with uniface a lot to do bulk modifications (especially on migration jobs).  

Hi Uli, you mean fiddle with Uniface's data dictionary?

Hi Claudio, I can answer your last question easily: it means to build uniface components able to programmatically change your repository. Uniface is distributing UMETA.xml containg definition of repository tables. You should learn about where and how objects like forms, services, reports (and all remaining uniface objects...) are saved and you could build a program to change them. "Fiddle with Uniface's data dictionary" means to use a program to manage your sources instead of doing it manually. Gianni

Hi Claudio, While Uniface does not has a full "skinning" functionality, there is a lot that you can do to change the look and feel of your application without changing the code. For forms, entities, area frames, and widgets you can set dozens of properties through the .ini configuration file. Especially in the Uniface 9.6 / 9.7 time frame many options have been added. You can find everything in the documentation, but for inspiration you can also have a look at the blog posts:   http://unifaceinfo.com/modern-buttons-are-flat/ http://unifaceinfo.com/styling-entities-and-area-frames-in-uniface-9-7/ http://unifaceinfo.com/modernizing-uniface-9-7-in-10-easy-steps/ http://unifaceinfo.com/modernizing-uniface-9-7-part-2/ http://unifaceinfo.com/modernizing-uniface-9-7-the-buttons/ http://unifaceinfo.com/tab-widget-extensions-9-6-04/ http://unifaceinfo.com/modernization-exercise-new-main-screen-idf/   <- This looks the most like skinning http://unifaceinfo.com/overview-of-what-is-possible-with-the-tabex-widget/ http://unifaceinfo.com/modernizing-an-existing-uniface-application/

Hi Claudio Then the only way to implement something similar to skins is changing glyphs. Assuming you are using standard deployment (no DOL). Every glyph is a file in gly folder. Assuming app resources are in local (no network drives to share these files between users).  When a user applies a skin you can programmatically replace original *.gly files by others. And put a message "New skin will take place after restarting application". Problem: if user don't restart... forms already in execution still use old skin and new forms will use the new one. Ugly and disturbing.   Another option is play with language. Assuming you are using $language=I. It can be understood 'I' as Italian with default skin. But you can define global objects for language 'I1', 'I2', 'I3', ... for Italian with skin1, 2, 3. Change skin is done by $language=I2 Problem: text objects (messages, menus are duplicated). And if your application is multi-language... it can be a mess.   Getting back to first path... change *.gly files. Another option. Let's say you have a resources section in you ASN file. Extract it to another file called resources.asn (including #file resources.asn in your original asn) resources.asn could be as:

[RESOURCES]
everything.uar
skin1.uar
skin2.uar
skin3.uar

everything.uar contains everything ;-). And skin?.uar contains only glyphs for skins. When user change to another skin, your program only need to reorder resources.asn lines. For example, to apply skin2, the file should be changed to this one:

[RESOURCES]
skin2.uar
everything.uar
skin1.uar
skin3.uar

Now, when Uniface look for a glyph, it will be found in skin2.uar first. So, it is applying skin2 (after restart) How to prepare this uars? With a different repository where you import all existing glyphs. Replace them for those belonging to skin?, create skin?.uar, export to skin?.xml and go next.   Hope [this time] it helps ;-) Luis