Home » Eclipse Projects » Remote Application Platform (RAP) » synchronous dialog handling
| synchronous dialog handling [message #36879] |
Thu, 05 July 2007 07:04  |
Eclipse User |
|
|
|
Originally posted by: gschmoe.salomon.at
Hello!
I have a question regarding the methods readAndDispatch() and sleep() of
Display class:
In my application I have a lot of small, modal windows that require input
of a couple of values. In SWT, I was using the syncExec() command together
with the loop
while (!s.isDisposed()) {
if (!d.readAndDispatch()) {
d.sleep();
}
}
Thus, the main control flow opens a modal window (or shell) and is waiting
until the window is closed (and the data input is finished). Then, the
main control flow continuous synchronously (without the need of
callbacks)...
The same behavior is with MessageDialog.openError(...), etc. The usage of
IWindowCallback complicates the dialog logic dramatically, if you have
many message boxes...
Now, since the above methods readAndDispatch() and sleep() of class
Display do not exist in RWT, I have the question: Will they be provided
later or what should be used instead of them?
Thanks,
Gernot
|
|
|
| Re: synchronous dialog handling [message #36949 is a reply to message #36879] |
Fri, 06 July 2007 14:22  |
 Tiago
Messages: 55
Registered: July 2009 |
Member |
|
|
Hi, I have the same issue. It would be very nice if someone could provide a
solution for this.
Thanks
Tiago
"Gernot Sch." <gschmoe@salomon.at> wrote in message
news:1897a83ce4b017a399faa03c424e3a09$1@www.eclipse.org...
> Hello!
>
> I have a question regarding the methods readAndDispatch() and sleep() of
> Display class:
>
> In my application I have a lot of small, modal windows that require input
> of a couple of values. In SWT, I was using the syncExec() command together
> with the loop
>
> while (!s.isDisposed()) {
> if (!d.readAndDispatch()) {
> d.sleep();
> }
> }
>
> Thus, the main control flow opens a modal window (or shell) and is waiting
> until the window is closed (and the data input is finished). Then, the
> main control flow continuous synchronously (without the need of
> callbacks)...
>
> The same behavior is with MessageDialog.openError(...), etc. The usage of
> IWindowCallback complicates the dialog logic dramatically, if you have
> many message boxes...
>
> Now, since the above methods readAndDispatch() and sleep() of class
> Display do not exist in RWT, I have the question: Will they be provided
> later or what should be used instead of them?
>
>
> Thanks,
> Gernot
>
|
|
|
| Re: synchronous dialog handling [message #36984 is a reply to message #36949] |
Mon, 09 July 2007 05:42 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
this is a difficult topic. We try to be as near to the programming model of
RCP as possible, but there are restrictions due to the distributed nature of
the server environment RAP runs in. As we do not have a single UI-thread
running a loop (servlet containers use usually a thread pool) and each
request has to provide a response to the server, we can not simply provide
readAndDispatch(), sleep() or block when a dialog is opened. We have had a
lot of dissussions about the problem, but we still did not find a reasonable
alternative to the callback approach. Any input would be appreciated.
Ciao
Frank
"Tiago" <tiago.bugzilla@gmail.com> schrieb im Newsbeitrag
news:f6lja6$d8a$1@build.eclipse.org...
> Hi, I have the same issue. It would be very nice if someone could provide
> a solution for this.
>
> Thanks
> Tiago
>
> "Gernot Sch." <gschmoe@salomon.at> wrote in message
> news:1897a83ce4b017a399faa03c424e3a09$1@www.eclipse.org...
>> Hello!
>>
>> I have a question regarding the methods readAndDispatch() and sleep() of
>> Display class:
>>
>> In my application I have a lot of small, modal windows that require input
>> of a couple of values. In SWT, I was using the syncExec() command
>> together with the loop
>>
>> while (!s.isDisposed()) {
>> if (!d.readAndDispatch()) {
>> d.sleep();
>> }
>> }
>>
>> Thus, the main control flow opens a modal window (or shell) and is
>> waiting until the window is closed (and the data input is finished).
>> Then, the main control flow continuous synchronously (without the need of
>> callbacks)...
>>
>> The same behavior is with MessageDialog.openError(...), etc. The usage of
>> IWindowCallback complicates the dialog logic dramatically, if you have
>> many message boxes...
>>
>> Now, since the above methods readAndDispatch() and sleep() of class
>> Display do not exist in RWT, I have the question: Will they be provided
>> later or what should be used instead of them?
>>
>>
>> Thanks,
>> Gernot
>>
>
>
|
|
|
| Re: synchronous dialog handling [message #37048 is a reply to message #36984] |
Tue, 10 July 2007 07:13 |
| Eclipse User |
|
|
|
Originally posted by: gschmoe.salomon.at
Hi Frank,
Well, I don't know the details of internal RAP thread handling and thus
I'm not sure whether I understood the problem correctly.
As I understand the situation is the following: There is a pool of n
threads serving m clients. Each thread must respond to a request in order
to be available for the next request by any other client and thus it
cannot be blocked (if m > n this would eventually cause clients to get no
response).
I'm not sure if this is correct? If so, could there not be a 1:1
relationship between client and server thread? For each client, a separate
thread is started serving this session - which could then also be blocked?
Our situation is that we would like to use RAP for a very large
application (several hundred dialogs) to provide it as rich client and
browser application. We have a framework on top of SWT, where we can
handle some details of RWT vs. SWT, but this particular problem affects
all dialogs and their programming nature. Using callbacks is completely
different logic and I don't know how to encapsulate this in the framework
without changing all the dialog's logic...
Is there any plan to solve this issue? Any ideas how and what we could do?
Ciao,
Gernot
Frank Appel wrote:
> Hi,
> this is a difficult topic. We try to be as near to the programming model of
> RCP as possible, but there are restrictions due to the distributed nature of
> the server environment RAP runs in. As we do not have a single UI-thread
> running a loop (servlet containers use usually a thread pool) and each
> request has to provide a response to the server, we can not simply provide
> readAndDispatch(), sleep() or block when a dialog is opened. We have had a
> lot of dissussions about the problem, but we still did not find a reasonable
> alternative to the callback approach. Any input would be appreciated.
> Ciao
> Frank
|
|
|
| Re: synchronous dialog handling [message #41885 is a reply to message #37048] |
Thu, 16 August 2007 00:11 |
| Eclipse User |
|
|
|
Originally posted by: fappel.innoopract.com
Hi,
I just want to let you know, that there is a new Window#open() mechanism in
place that blocks on open like RCP. For more details see:
http://wiki.eclipse.org/Rap10M6_News (Blocking Window)
Ciao
Frank
"Gernot Sch." <gschmoe@salomon.at> schrieb im Newsbeitrag
news:e166ff81e56c41beb57d36a743ce089e$1@www.eclipse.org...
> Hi Frank,
>
> Well, I don't know the details of internal RAP thread handling and thus
> I'm not sure whether I understood the problem correctly.
> As I understand the situation is the following: There is a pool of n
> threads serving m clients. Each thread must respond to a request in order
> to be available for the next request by any other client and thus it
> cannot be blocked (if m > n this would eventually cause clients to get no
> response).
>
> I'm not sure if this is correct? If so, could there not be a 1:1
> relationship between client and server thread? For each client, a separate
> thread is started serving this session - which could then also be blocked?
>
> Our situation is that we would like to use RAP for a very large
> application (several hundred dialogs) to provide it as rich client and
> browser application. We have a framework on top of SWT, where we can
> handle some details of RWT vs. SWT, but this particular problem affects
> all dialogs and their programming nature. Using callbacks is completely
> different logic and I don't know how to encapsulate this in the framework
> without changing all the dialog's logic...
>
> Is there any plan to solve this issue? Any ideas how and what we could do?
>
> Ciao,
> Gernot
>
>
> Frank Appel wrote:
>
>> Hi,
>
>> this is a difficult topic. We try to be as near to the programming model
>> of RCP as possible, but there are restrictions due to the distributed
>> nature of the server environment RAP runs in. As we do not have a single
>> UI-thread running a loop (servlet containers use usually a thread pool)
>> and each request has to provide a response to the server, we can not
>> simply provide readAndDispatch(), sleep() or block when a dialog is
>> opened. We have had a lot of dissussions about the problem, but we still
>> did not find a reasonable alternative to the callback approach. Any input
>> would be appreciated.
>
>> Ciao
>> Frank
>
>
|
|
|
Goto Forum:
Current Time: Sat Nov 09 01:35:07 GMT 2024
Powered by FUDForum. Page generated in 0.03614 seconds |
] 
Search
Help
Register
Login
Home
