Rocket Uniface User Forum

 View Only

Uniface 10: What's happened since the release?

By Uniface Test posted 02-09-2017 10:57

  

(Original creator: miketaylor)

Back in September 2016 we had quite a major event, Uniface 10 was released with the ability to develop and maintain all forms of Uniface applications – Client Server, Web and batch.





Since the release, and based on lots of feedback from the early adopters, we have continued to actively enhance the IDE with constant incremental improvements. In this blog post, I would like to share with you what these improvements are as well as what we have planned for the near future. To start, it is probably a good idea to give some high-level topics we have been concentrating on.

Migration

This topic has probably been our primary focus during the continuous updating of v10. We have always had a migration path between Uniface versions automating any updates needed. In version 10 we continue with this concept and as information becomes available, from customers and our own experiences, the migration utilities have been updated to further improve the experience.


Uniface 10: Code migrated from 9 to 10

Usability and bug fixing

Performance in large repositories has proven to be an area where we have needed to pay attention and has generated some lively discussions on u.uniface.info. Although this is an ongoing theme we have already made significant enhancements. The dropdown browse dialogs for the Development Objects (cpt:, ent:, libinc:, etc) will load the information and format the data with considerably less of a delay. Incremental rendering has also been added so that the list becomes available and usable even while extra rows continue to be added. The same techniques and improvements will also be added to the resource browsers in the coming patches.


Uniface 10: Cascading browse dialogs

Embedding the GUI screen painter

Client server development is another area we are enhancing. The first enhancement we are planning and currently working on is embedding the form painter directly into the v10 IDE.


Uniface 10: Embedded form painter taken from a developer's PC

Runtime enhancements

It is now possible to specify what trigger, accept or quit, will be called when an auto close popup loses focus. The ability to undeclare a trigger, operation or local proc. This will allow model or previously defined scripts to be excluded from the compile effectively allowing default functionality for a trigger to be re-established. The ability to call up to a higher-level trigger has been added, this allows such actions as explicitly calling the entity level Detail trigger from the field level detail trigger.


Uniface 10: New popup options


As you can see, we've been very busy, and there is a lot more to come.

2 comments
1 view

Permalink

Comments

05-10-2019 08:05

Hi Knut,
We plan on building, and delivering, the painters functionality incrementally. We want to go far enough to offer developers an improved experience and then release it. Although it will be complete and tested, I am sure we will get feedback and that is a good thing, it means we have the opportunity to concentrate on what is important to you and the rest of the community.
Some features we do plan on including up front are a way of being able to visualise the component's dimensions (the discussions are currently heading in the direction of overlaying a border) and improved overflow handling for better navigation around the form.
The question of large components has been a topic we have discussed and popping out the painter is just one solution that has been talked about. Before coming to a final decision, we first want to experience what using the painter in its new location is like, early indications seem to be very favourable.
Thanks for the feedback,
Mike

05-10-2019 08:05

Hi Mike,
Great to hear / read the update.
A couple of questions though;
With the GUI Screen Painter - will there be an option to detach the screen painter to a separate window
(as we have it now)? Some of our screens are quit wide (+100) - and with all the panels around the screen painter
(as pr your image) - I'm somewhat concerned about the screen real estate...
As well, many of our 'screens' rely on the current form positions as defined / stored in the repository...
How is that going to be handled / maintained?
Regards,
Knut