Uniface wishlist
Version : 1.0
Date : 2003-04-04
Written by : Alex LEGUEVAQUES
Contents
1 UDE__________________________________________________________________ 4
1.1 Pixel coordinates based Paint tableau__________________________________________ 4
1.2 Widget alignment tools______________________________________________________ 4
1.3 Global header and trailer____________________________________________________ 4
1.4 Standard widgets look should be more customizable_____________________________ 4
1.5 A new « Graph widget »_____________________________________________________ 4
1.6 A new « progress bar widget »________________________________________________ 5
1.7 UDE should display a progress bar for lengthy operations________________________ 5
1.8 A graphical business object model editor_______________________________________ 5
1.9 Disable compilation warning 1074 if needed____________________________________ 5
1.10 Use central messages as menu items titles_______________________________________ 5
1.11 Central messages ids should be 32 of length_____________________________________ 5
1.12 Glyphs ids should be 32 of length_____________________________________________ 5
1.13 Color palette should consist of 256 colors______________________________________ 6
1.14 UDE should be available in several languages___________________________________ 6
2 Proc language functions_________________________________________________ 7
2.1 $entinfo function should include a topic « MODEL «____________________________ 7
2.2 $componentinfo should be extended___________________________________________ 7
2.3 A function returning the number of elements in an indexed or associative list________ 7
2.4 A function returning the current operation or proc name_________________________ 7
2.5 A « random » function would be useful________________________________________ 7
2.6 A $char-like function to interrupt Proc code____________________________________ 7
3 Proc language instructions_______________________________________________ 8
3.1 Set management____________________________________________________________ 8
3.2 Dynamic labels_____________________________________________________________ 8
3.3 Dynamic layout____________________________________________________________ 8
3.4 Add /init option to xmlload instruction________________________________________ 9
3.5 Sort an associative list by value_______________________________________________ 9
3.6 Putitem option for insert or overstrike mode____________________________________ 9
3.7 sound instruction should be documented and enhanced__________________________ 9
3.8 « round » extraction parameter could include « > » option________________________ 9
3.9 More options in selectdb_____________________________________________________ 9
4 Triggers______________________________________________________________ 10
4.1 Entity level <Start Mod. Occ.> trigger________________________________________ 10
4.2 Entity level <Occ. Loses focus> or <Leave Occ.> trigger_________________________ 10
4.3 Application level <Appl. Quit> trigger________________________________________ 10
5 Debugger_____________________________________________________________ 10
5.1 An option to watch all fields of an entity would be useful________________________ 10
6 Runtime______________________________________________________________ 10
6.1 Message frame should be displayed in rich editor_______________________________ 10
Paint tableau in Uniface has always been a character-cell matrix .
That was OK for character applications, but now with graphic deployment, it shows its limits . There is a contradiction in using fonts whose size is defined in pixels and widgets whose size is defined in character cells. Sometimes, the result is really ugly, or you have to make hard choices. For example, a font size can have a height just superior to a character cell, and you must choose between a two lines widget and an ugly white zone around your data.
Major drawback is that it would prevent ChUI deployment compatibility.
I suggest to add a « Pixel coordinates » checkbox when creating a Form or Report to give the user freedom to enforce or not ChUI compatibility.
This checkbox should also exist in component properties, but it would be impossible to check it off when Paint Tableau is not empty.
Widgets painted in a pixel-based component would be able to change size by one-pixel increment , and they would be positioned with a one pixel precision.
This is a logical consequence of previous wish. If widgets can be positioned with pixel precision, we need tools to align a group of widgets to left, right, or justify it.
In a report, it should be possible to define a global header printed as first page of report, and a global trailer printed as last page of report.
A few more options to customize the look of standard widgets would be very welcome. For example :
« rounded » option
for command buttons :
« checkmark » for checkboxes : ü
This entity-level widget would display a line, bar or pie chart representing data in the entity.
A progress bar like form would appear giving a visual clue of the progress of the current operation to the user.
Example of desired behaviour :
Ctr =1
While (ctr < 20000)
Message/bar « Loading data … »,ctr,20000
Ctr = ctr + 1
EndWhile
it is absolutely no problem to create a progress-bar form by Uli
When importing, exporting, converting data…
Uniface Six used to include a graphical model editor, which at some time disappeared.
All other CASE include one, and Uniface look old by comparison.
In component editor preferences, a check box to disable compilation warning 1074 (- Entity %%$sub missing for integrity control on del/upd of %%$sub(1)%%%) would be very useful as we have tenths of this warning by component, making compilation results hard to read.
Like labels, we should be able to use $text(…) in menu item title.
Having to define multiple menu bars,menus and items by language is really a pain
and make the application difficult to maintain. We have a trilingual (french,german,italian) application and hate this behaviour.
Current length is limited to 16, and this prevents some standardizations (for example, a message ID could be entity name + suffix).
Current length is limited to 16, and it is sometimes an annoying limit .
Current limitation of 64 colors is not consistent with a classic Web palette and make it difficult to have an elegant user interface .
UDE should be a multilingual application. Language choice should be available in assignment file and preferences .
At least French, German and Spanish user interfaces should be available.
This topic should return the name of the business object model of the entity.
the model of an entity is held in the constant $SCHEMA by Uli.
An « OUTER » topic should return an indexed list of all outer entities in the component.
This can actually be done by a loop on the list or by adding a dummy element, subtracting 1 of $status, and deleting the dummy element.
Such a function would greatly simplify this.
This can actually be done by activating a non-existent component and getting item("PROCNAME",$procerrorcontext) but this trick is not very satisfactory.
This one is self explanatory.
There is a random number generator available on $UUU
There is currently no mean to interrupt Proc code based on user input.
The desired behaviour would be :
While ($input != 88) ; end loop if user presses « X » key
… some code ….
EndWhile
We should be able to manage multiple hitlists of one entity and use set operators (union,intersection,difference) to create a new histlist.
Example :
Mnt_debt.customer/init = « >10000 »
Retrieve/e « customer »
New_set « customer », »DEBT » ; Creates a set named « DEBT » (bit array of occurrences in the hitlist)
Clear/e « customer »
Sex.customer/init=0
Retrieve/e « Customer »
New_set « customer », »Men »
Intersection « Debt », »Men », »Mendebt » ; Creates a set named « Mendebt » whose elements pertained simultaneously to « debt » and « Men » sets.
Use_set « mendebt » ; replaces current hitslist with occurrences corresponding to elements in set « mendebt »
Delete_set « Men »
Delete_set « Mendebt »
It should be possible to know if a given occurrence pertains to a givent set, and the number of elements in a set, with the appropriate Uniface function.
Part of this can be done by using subtypes and associative lists, but complexity and bad performance prevent this to be done.
this is only a matter of using retrieve and/or retrieve/a to achieve required sets by Uli
Content of a label should be modifiable at run time.
For example :
$fieldlabel(field) = $text(good)
For dynamic labels, there is an option abusing drag/dropsources
Layout of a field should be modifiable at run time, more easily than by using « Format » and « Deformat » triggers .
For example :
If ($language = « F »)
then
Field_layout « field », »dd/mm/yyyy »
Else
Field_layout « field », »mm/dd/yyyy »
Endif
it is only a matter of procs defined to be used in the format/deformat trigger
When data is loaded in a Form in an n-tier application, all fields are considered modified. This is not true, and it does not happen in a C/S application.
A /init option to xmlload instruction would be a solution.
Sort/list instruction sorts an associative list based on the representation part.
It lacks an option to sort items by value.
just getlistitems to a dummy-entity with 1 field and sort this entity then putlistitems
Putitem list,n,source currently replaces the nth item in the list with source.
It lacks an option (putitem/insert ?) to insert source at nth position and shift to the right all subsequent items.
Sound can be used to give a feedback to user for its actions in the application.
Therefore, the « sound » instruction should be documented and enhanced to support other sound formats than « .wav » .
We encountered the need for a special rounding algorithm.
With this option, number would be rounded, not to the nearest value, but to the upper value. For example :
$1 = 2
$2 = 2.1
$3 = $1[rounded] ; $3 = 2
$3 = $2[rounded,1, »> »] ; $3 = 3
This can be done by adding 0.5 before rounding but such an option would be more practical.
For statistic reports, a few statistic options would be very useful :
- stddev
- variance
- sum squares
Actually, the only way to detect that the user is trying to modify an occurrence is by putting code in all editable painted fields <start mod. > triggers.
A <Start Mod. Occ.> trigger, activated before <start mod. > triggers, would be a welcome enhancement.
just design a proper way and update the defaultproc
If a user leaves an occurrence without modifying anything, no event is triggered now.
This trigger would be both logical and practical.
The documented way of intercepting the application exit is by receiving a message in the component-level or application-level <Async. Interrupt> trigger .
But if you deal with messages in a lot of components, it can be a pain to deal with application exit in each component.
An <Appl. Quit> trigger in the startup shell would do the job painlessly.
It is a painless activity, because of the ASYNC fallback mechanism.
There are times when you need to examine all or a great number of fields of the current occurrence of an entity. A menu option to add all fields of current entity to quick watch window would save a lot of time.
Now that Proc listings and code (triggers and procs) are handled by the new Rich Editor, it would make sense to have it take care of message frame too.
It would make possible to search, select without any pain and would enforce interface consistency .