[Logo] Enterprise Client Community
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
Inner StatusBar Cleared When Two Actions  XML
Forum Index -> Development
Author Message
unger

Power User

Joined: 22/07/2008 05:19:28
Messages: 261
Offline

Hello,

can it be that an inner statusbar is cleared after the first action (may be a rowExecute) when a second is followed (for example a flush) within one roundtrip?

Regards,
Joachim
CaptainCasa

Power User
[Avatar]

Joined: 21/11/2007 12:23:06
Messages: 5510
Offline

Hi,

no the clearing is only done between two roundtrips.
Please observer the CCLog (INFO level) and check how many roundtrips are executed.

Sometimes roundtrips are really fast one after the other. E.g. Grid double-click: there is a rowselect-roundtrip and just afterwards a rowexecute-roundtrip. So output of the rowselect only survives some milliseconds.

This is the reason, why the "new" (> 6 months old...) statusbar always shows a message for minimum 2 seconds, even if it is reset immediately by the logic.

Regards, Björn

Björn Müller, CaptainCasa GmbH
unger

Power User

Joined: 22/07/2008 05:19:28
Messages: 261
Offline

Hi Björn,

yes, I found two roundtrips. First rowExecute(ActionEvent) second on...Flush(EctionEvent).

After rowExecute() event my work is done. How can I suppress or avoid the flush processing? Do You think storing a state inside the session parameters is a solution?

Regards,
Joachim
unger

Power User

Joined: 22/07/2008 05:19:28
Messages: 261
Offline

But in this case the Statusbar is cleared after first roundtrip.
CaptainCasa

Power User
[Avatar]

Joined: 21/11/2007 12:23:06
Messages: 5510
Offline

Hi,
yes the statusbar is cleared after reach roundtrip!
There is a method Statusbar.reoutputLastMessages() - maybe you can call this within the second processing?
Regards, Björn

Björn Müller, CaptainCasa GmbH
unger

Power User

Joined: 22/07/2008 05:19:28
Messages: 261
Offline

Hi Björn!

What is the reason to separate onExecute from flushes in different roundTrips? And onExecute() called first?

Regards,
Joachim
CaptainCasa

Power User
[Avatar]

Joined: 21/11/2007 12:23:06
Messages: 5510
Offline

Hi Joachim,
the reason typically is that the events are also decoupled on client side - e.g. in the RISC client clicks are registered on mouse up, focus changes on mouse down.
Could you attach a mini-JSP of your scenario to this discussion? Then I could hopefully give a more detailed response.
Thanks + Regards! - Björn

Björn Müller, CaptainCasa GmbH
unger

Power User

Joined: 22/07/2008 05:19:28
Messages: 261
Offline

Hello Björn, dear readers,

in the attachment You will find source and jsp for a little test case.
You need a filter declaration in web.xml.

Scenario: When enter is pressed, the row should be executed. That means if all fields are checked as okay, then a save should be processed. No further flushes should be processed.

Regards,
Joachim
 Filename exampleRowExecuteFlush.zip [Disk] Download
 Description
 Filesize 4 Kbytes
 Downloaded:  131 time(s)

unger

Power User

Joined: 22/07/2008 05:19:28
Messages: 261
Offline

Hi,

in RISC I found an expected behaviour:
1. onFlush...
2. onRowExecute
in ONE roundtrip. That's also the expected order!

So it seams to be a Swing client problem.

@Björn: Were there changes in the processing order?

Regards, Joachim
unger

Power User

Joined: 22/07/2008 05:19:28
Messages: 261
Offline

...attached archive...
 Filename RowExecuteFlushSwing_2.zip [Disk] Download
 Description
 Filesize 86 Kbytes
 Downloaded:  63 time(s)

CaptainCasa

Power User
[Avatar]

Joined: 21/11/2007 12:23:06
Messages: 5510
Offline

Hi Joachim,

thanks for attaching the example. Executing the onRowExecute() via return-key was the information I was missing so far, now I can see your issue in the Swing client.

Yes, the event sequence is different, but there is one important issue: the value of the fields is transferred immediately. So at the point of time of processing the saving, the value are correctly transferred into the server processing.

Applying little changes in this quite central part of the Swing client is something that we do not really want to do for updating the behavior. So, we ask you to do the work around as described above (keep messages in status bar on flush actions). Thanks! ;-)

Kind regards, Björn

Björn Müller, CaptainCasa GmbH
 
Forum Index -> Development
Go to:   
Powered by JForum 2.1.6 © JForum Team