This content has been marked as final. Show 7 replies
I'm a little confused. You said, " +...small piece of code ... when the form is loaded+ ". But then you say, " +...only executed at the post-form trigger+ ". So which is it? Is the code executed when the form starts or exits? If the code is executing when the form exits, why would you be trying to change colors if the form is closing?
Generally speaking, performance issues while navigating are the result of poor network performance and/or excessively customize validation or post item triggers. Such triggers should be tuned carefully and used sparingly so as to avoid such performance issues. In some cases, depending on the application design, you can delay validation by changing the form level property "Validation Unit". By delaying validation, some of the delay seen while navigating may be reduced. But be careful. This change will alter the validation behavior of your application.
Thanks for reply Michael.
We change the color in the PRE-FORM trigger. My bad. The code is only executed there but when the form has multiple canvases with many fields, and you move between fields, you can see the mouse cursor spinning. Like if something is being done in the database. This doesn't happen with small forms with one or two canvases. We know about the validations considerations but the slowness is also present on the fields that don't have any trigger.
Based on what you have described, I find it difficult to believe that the changing of colors is causing the problem. When you say "move field to field" are you suggesting that field A is on canvas A and field B is on canvas B and therefore the moving from field to field is actually canvas to canvas?
You may find it helpful to enable tracing in the JRE and open the Java console. While navigating from field to field monitor the console and see how much, if any activity occurs. While in the same form and canvas, I would not expect more than one exchange in the console when navigating from field to field. If you are moving from a field on canvas A to a field on canvas B, likely there will be more network noise. If you are seeing excessing amounts of traffic, this is likely caused by your own code. In this case, you would need to carefully review the code and its logic.
It might also be work looking closely at the client machines. Ensure that the machine is not underpowered. For example, a Windows 7 machine with 2gig of RAM is probably not going to perform well. Also, if you are using old JRE versions I would recommend using at least Java 6U45 or newer. If you are already using Java 7, be sure that you are using 7U21 or newer.
Thanks for the tip, Michael. By turning the java trace on I'm able to see what is happening. Looks like the canvases are loaded into memory when I set the color. When I don't set the color, there is only on POST on the server like the one below when tabbing on the form. But when I set it, there are multiple ones(one per canvas, I think). Is there a way to avoid this?
network: Connecting http://server:8888/forms/lservlet;jsessionid=QhkWRqvN0CFFvtRMvBfyPvD0bLCL8pd5KQL2gdH96RlJYgk8XNGn!-859986153 with proxy=DIRECT
Be careful to not misinterpret what you are seeing. The exchanges from client to server are necessary every time (well most times) something in the gui is changed and/or when some pl/sql must be executed related to something the user has done. So, for example, if you are in a text field and you click on a button within the same canvas this will produce traffic. If clicking the button causes pl/sql to execute, this may result in more traffic, depending on the code. If this then results in a new canvas and/or window to be displayed, even more traffic will be exchanged. Remember that the client UI must always be in sync with the server and visa-versa.
The only realistic way to avoid or minimize any of this is to write your code with some careful strategy. Consider carefully what actions you are taking against the UI and whether or not they are really necessary. If they are necessary, consider how, where, and when you are executing those calls.
Thanks for join us, Tony.
No. I don't have a post-item-trigger at the form level. The problem is only when I access the canvases to change the color on the pre-form trigger. If I don't do it, the network traffic is reduced to only one post per field tabbing.
Michael, maybe I shouldn't say avoid the network traffic. What I meant was if there is a way to remove the canvases from memory so the applet doesn't have to repaint them all even if they haven't been shown on the screen. That's what I thinks it's being done. When a property is set on a canvas(or any object), doesn't it have to be loaded in memory?