Skip to main content
Solved

Universal GUI Editable Grid Performance

S
Rookie
Forum|alt.badge.img

Universal GUI Editable Grid Performance Issues

Installed software:

Software Version
Universal GUI 2025.1.14.0
Indicium 2025.1.14.0

 

Problem Statement

The Universal GUI seems to be less performant in various cases, when compared to the same functionality in (older) WebGUI / WindowsGUI.

Specifically, the editable grid has significant performance implications, which makes the user interface unreliable. Upon pressing the downward arrow-key 3 times in succession in the editable grid. The UGUI registers only 2 button presses.

The problem is not necessarily the delay, it is the discarding user-inputs that makes the UGUI unreliable in use.

Possible Causes

  • Universal GUI version: we are on the latest version.
  • Indicium version: we are on the latest version.
  • Resource capacity: we host UGUI & Indicium on a server dedicated to this environment.
  • Data quantity: this test was performed on an editable grid with 6 columns and 7 rows, without expression fields, nor triggers.

This list does not spark a possible explanation to discarding user-inputs.

The goal of this report is to resolve this performance issue present in the UGUI, which makes it unusable for our clients to perform their processes.

Suggestions

This is just speculation from my side, but a couple of interesting directions for investigation of this flagship User-Interface of Thinkwise could be:

  • The inter-working of Indicium and Universal GUI, in the config.json of Universal GUI, the documentation specifies to declare the public url to the Indicium endpoint. This could also be connected with for example a local address, to keep the communication between the two local, except for over the internet.
  • Investigate UGUI’s processing of user-inputs. Perhaps the processing of the next row action and the loading of data is blocking the thread from accepting new user keyboard inputs.
  • The stage_edit & commit transactions that are happening in the editable grid in the UGUI, could be slowing down, blocking the application for accepting new inputs. These actions seem to not be happening in the WindowsGUI, WebGUI.

Additional Remarks

There are other instances in which the UniversalGUI performs significantly poorer, when compared to the older WindowsGUI/WebGUI. However, the skipping of inputs is what makes the UGUI unreliable in use and therefore not suitable for usage at the end-clients.

In the case of an incorrect setup, I’d like to see a demo of the UGUI not skipping the inputs when pressing the navigation keys in an editable grid.

 

 

Best answer by Arie V

​@Stijn Schuurman That's quite a long post, let me pick out a few things:

Upon pressing the downward arrow-key 3 times in succession in the editable grid. The UGUI registers only 2 button presses.

The problem is not necessarily the delay, it is the discarding user-inputs that makes the UGUI unreliable in use.

Please raise a ticket in TCP for this piece. We know this can occur and do have some ideas for improvement. However if your infrastructure, your internet connection, and your Layout/Context procedure performance are all fine, this is for me only reproducible if you navigate very fast without making changes to records. In such cases I would expect you either use a mouse or Filter/Search to get to the desired row. Could you specify in the ticket what Use Case is hindered by the current performance and on what Controls you are navigating? It would help if you include a video and a HAR file related to that video.

 

The Universal GUI seems to be less performant in various cases, when compared to the same functionality in (older) WebGUI / WindowsGUI.

The fact that we are working with a 3-tier Architecture does indeed cause a bit more overhead by the Web server that is in between the Database and the UI. For a lot of scenarios this disadvantage is mitigated by the advantages of lazy loading, which is applied a lot in the Universal UI. For Editable grid we have made enormous progress compared to a year ago, but there are still a couple of ideas on our backlog that further improves the current performance.

 

View original
S
1 person likes this
  • S
    Stijn Schuurman
Did this topic help you find an answer to your question?

5 replies

S
Rookie
Forum|alt.badge.img

This could be the potential setup for the local connection between Indicium & Universal GUI. Connecting them directly on the server, except for over the internet on a public hosted domain. They could both still be accessible on the public URL as well, but the direct communication between them goes through the local network of the server hosting it.

Arie V
Community Manager
Forum|alt.badge.img+12
  • Arie V
  • Community Manager
  • 1060 replies
  • Answer
  • July 4, 2025

​@Stijn Schuurman That's quite a long post, let me pick out a few things:

Upon pressing the downward arrow-key 3 times in succession in the editable grid. The UGUI registers only 2 button presses.

The problem is not necessarily the delay, it is the discarding user-inputs that makes the UGUI unreliable in use.

Please raise a ticket in TCP for this piece. We know this can occur and do have some ideas for improvement. However if your infrastructure, your internet connection, and your Layout/Context procedure performance are all fine, this is for me only reproducible if you navigate very fast without making changes to records. In such cases I would expect you either use a mouse or Filter/Search to get to the desired row. Could you specify in the ticket what Use Case is hindered by the current performance and on what Controls you are navigating? It would help if you include a video and a HAR file related to that video.

 

The Universal GUI seems to be less performant in various cases, when compared to the same functionality in (older) WebGUI / WindowsGUI.

The fact that we are working with a 3-tier Architecture does indeed cause a bit more overhead by the Web server that is in between the Database and the UI. For a lot of scenarios this disadvantage is mitigated by the advantages of lazy loading, which is applied a lot in the Universal UI. For Editable grid we have made enormous progress compared to a year ago, but there are still a couple of ideas on our backlog that further improves the current performance.

 

S
1 person likes this
  • S
    Stijn Schuurman
S
Rookie
Forum|alt.badge.img

​@Arie V Indeed quite a long post, did so to be inclusive about all the circumstances. Thankyou for your swift response.

 

Please raise a ticket in TCP for this piece. We know this can occur and do have some ideas for improvement.

I will raise a ticket in TCP for this.

 

However if your infrastructure, your internet connection, and your Layout/Context procedure performance are all fine, this is for me only reproducible if you navigate very fast without making changes to records.

This is indeed the case. These elements are all fine and the problem is only reproducible upon navigating very fast without changing records. I will clarify further in the TCP ticket what the use case is with a video and a HAR file. However, it is as you describe, when navigating fast. The use case of checking many order entries swiftly and making manual changes where needed is what is hindered by the Universal GUI, when compared to the WebGUI.

 

The fact that we are working with a 3-tier Architecture does indeed cause a bit more overhead by the Web server that is in between the Database and the UI. For a lot of scenarios this disadvantage is mitigated by the advantages of lazy loading, which is applied a lot in the Universal UI. For Editable grid we have made enormous progress compared to a year ago, but there are still a couple of ideas on our backlog that further improves the current performance.

I must say, the lazy loading coupled with pagination works well! I will see about those further improvements in the TCP ticket. Do you pick it up right there?

S
Rookie
Forum|alt.badge.img

​@Arie V 
It seems that my submission to the TCP platform that you mentioned is not being taken up internally. Could you refer the right person to my request?

Arie V
Community Manager
Forum|alt.badge.img+12
  • Arie V
  • Community Manager
  • 1060 replies
  • July 9, 2025

​@Stijn Schuurman It is going through the proper channels, don’t worry. Let’s continue the conversation via the ticket.

S
1 person likes this
  • S
    Stijn Schuurman

Reply


Terms & ConditionsCookie settingsAccessibility statement

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings