"uniface has got the ""RTL""-option within the asn-File. It doesn't work for a couple of elements in a correct way: Menus, Trees, Grid-Widget, Radio Groups, Tab-Pages and lots of other elements. Nearly every widget has not the expected effect in an RTL environment. These restrictions needs to be solved. Problem opened since: 10/27/2008 Commitments of uniface: none. Even no plannings, which we can promise our customers!!! Compuware/uniface may identify this as a wish (to be solved somewhen unspecified). In my eyes it is an urgent need or Misfeature, where the only workaround is: don't use uniface. For Engineers with an international background it is often enough a KO-Criteria. We are reliant on uniface."

Use Case

"uniface needs full supported RTL: - Menus are not RTL (They start from left) - Trees are not RTL (Tree content is still LTR, The Icons are still left side) - Grid-Widget is not RTL (Fields are not mirrored, Attachements to the right/left doesn't work as expected) - Radio Groups are not correctly RTL (The allignment is wrong) - Tab-Pages are not RTL (Tab-Pages starts left) For a more detailed use case, please refer to call Nbr.: 01 00000 02644 There are possibly lots of other elements, we even did not test detailled. Expectations: I did not find ""THE"" detailed rules of being RTL. If so, I would refer to this. We did at least compare the uniface behave with a hebrew OS behaviour on each of the used element, widgets, Attachments, Grids, Text, Alignments etc. If this is identical (regardless of wrong or correct), we can argue also against our customer."


(1) Since applications are not necessarily written special for the arabic/hebrew market, we need to port applications for the country specific situation (here: RTL). This process currently fails, if we have uniface applications. (2) Since lots of applications ar not stand-alone-systems, but running with other (non-uniface) components together, the result of this misfeature ends up in a non-functional system, where the non-uniface components work correct and the uniface-components disturb everything. The developer of the non-uniface-components can at least solve all country-specific problems (maybe in a longer time, but he CAN solve it!) This is definitly not possible with uniface, There are no useful workarounds, no cheats, hidden switches or whatever, no entry points where we can catch it. We are highly reliant on uniface. If there is no solution, uniface is no option. This is definitly a KO-Crtieria for our Key-User. Solutions, operating on international market are very often measured in those criteria: - Language independency : YES, we can (excpet Menus, but: workaround) - Country specific sorting: YES, we will. - UNICODE or codepage : YES, we can - Country specific date and Money-Formats : YES, we will (possibly with workarounds) - RTL : Sorry, we can't, because uniface can't. NO Workaround available. In other programming languages RTL seemes to be the smallest problem in this list, since they are all refering to window-classes (or whatever), which inherits the functionality of the OS. This is not TRUE for a uniface-application.


Proc Code

Operating System

Not Applicable



Leave a Reply