Hi Rafal,
The only time you need to use "ApplicationContext.queueCallback" is if
you want to modify something from a background thread. If, for instance, you
have a PushButton that needs to change another component. In your
ButtonPressListener you can directly change that other component because the
listener is running within the EDT (Event Dispatch Thread) the same as the rest
of the application. If you were to start another thread to do some
long-running process and that background task wanted to modify a GUI component,
then you would use the "queueCallback" method to run the code that modifies the
UI (in the EDT and not your background thread).
Does that help?
~Roger Whitcomb
On Feb 15, 2012, at 6:28 AM, Rafał Gierusz wrote:
> Hi Roger,
>
> thank you very much for your explanation, now almost everything seems to be
> clear for me. I have one more question, "startup" method is not enough for
> me, I need to modify component's behaviour and properties from the code after
> everything is set up, I would say that I need to have a possibility to change
> them at any time my application is running. I understand that I need to use
> construction with "ApplicationContext.queueCallback" for that, do I get it
> right? So, every time I need to change component's property by calling
> component's methods from my code I need to wrap it using Runnable and invoke
> "queueCallback" method, right?
>
> Regards,
> Rafal
>
> Tuesday 20:59, Roger L. Whitcomb wrote:
>
>> Hi Rafal,
>> Couple of things: the code that checks the context for the event
>> dispatch thread also allows "main" as an acceptable thread because things
>> can be done in "main" BEFORE starting the Event Dispatch Thread (EDT) (not
>> after, though), so that doesn't quite explain it.
>> But, I think you have hit on the real problem: "setHeight" is meant to
>> be called from within Pivot with the final calculated height once all the
>> dust settles. For a Frame (as most containers) it will try to size itself
>> to an appropriate value for its children and then call "setHeight" with the
>> final value. Setting a "preferred" value will override (at least usually)
>> the size calculated from the children and use that preferred value for the
>> container size.
>> Also, the "startup" method is probably the right place to do UI size
>> calculations because you have the Display which can get you to the screen
>> size, etc. (rather than in the "main" method which doesn't have that
>> information directly).
>> So, I'm sorry I didn't think about these things in my first reply. The
>> "best" code, then, would be something like this:
>>
>> public void startup(Display display, Map<String, String> properties)
>> throws Exception
>> {
>> Frame frame = new Frame();
>> frame.setPreferredHeight(100);
>> frame.open(display);
>> }
>>
>> Roger Whitcomb
>>
>>
>> -----Original Message-----
>> From: Rafał Gierusz [mailto:[email protected]]
>> Sent: Tuesday, February 14, 2012 11:30 AM
>> To: [email protected]
>> Subject: RE: RE: 2.0.1 Resizing problem
>>
>> Hi Roger,
>>
>> I tried a lot of "tricks" before I wrote about my problem, I'll try to
>> share my result here. Let's assume that the base for our discussion is
>> the code I put in my first email. When "frame.setHeight(100)" will be
>> replaced with:
>>
>> new Thread() {
>> public void run() {
>> frame.setPreferredHeight(100);
>> }
>> }.start();
>>
>> the exception will the thrown: Exception in thread "Thread-4"
>> java.lang.IllegalStateException: this method can only be called from the
>> AWT event dispatch thread, and not from "Thread-4". Which makes me think
>> that I used the right thread in my "base" code from first email. I
>> noticed also that a method assertEventDispatchThread(Component
>> component) from Component is used to validate if the proper thread is
>> used for executing request of change.
>>
>> But anyway, I went further and tried also something like this:
>>
>> DesktopApplicationContext.queueCallback(new Runnable() {
>> public void run() {
>> frame.setHeight(100);
>> }
>> });
>>
>> and in that case it had no result, no result at all. But... when I
>> change setHeight to setPreferred, like in the following example:
>>
>> DesktopApplicationContext.queueCallback(new Runnable() {
>> public void run() {
>> frame.setPreferredHeight(100);
>> }
>> });
>>
>> it seems to be working correctly. But I still don't know why setHeight
>> doesn't work.
>>
>> Any ideas about that?
>>
>> Regards,
>> Rafal
>>
>> ---
>>
>> From "Roger L. Whitcomb"<[email protected]>
>> Subject RE: 2.0.1 Resizing problem
>> Date Tue, 14 Feb 2012 17:15:30 GMT
>>
>> Hi Rafał,
>> Without actually trying to run your code, I think the problem is that
>> you shouldn't be modifying
>> any UI elements in a non-UI thread.
>> Once you call "DesktopApplicationContext.main()" it starts another
>> thread to run the basic
>> event loop of your GUI application. This calls "startup()" as one of the
>> first things it
>> does. But, since your "main" method and the "startup" method are now in two
>> different threads,
>> it is problematic which one runs first, and it is basically illegal to
>> modify any UI components
>> in a different thread than the UI thread (for a number of reasons). So,
>> your call to "frame.setHeight()"
>> in the main thread is violating this rule. If you put the
>> "frame.setHeight()" right after
>> "frame = new Frame()" and before the "frame.open" then everything should be
>> fine. Something
>> like this:
>> public void startup(Display display, Map<String, String> properties)
>> throws Exception
>> {
>> Frame frame = new Frame();
>> frame.setHeight(100);
>> frame.open(display);
>> }
>>
>> public static void main(String[] args) throws Exception {
>> DesktopApplicationContext.main(BasicTest.class, new String[0]);
>> // This is a non-UI thread now, so no changes to "frame" are going
>> to work if done
>> here
>> }
>>
>> Let us know if you have further problems.
>>
>> ~Roger Whitcomb
>>
>> -----Original Message-----
>> From: Rafał Gierusz [mailto:[email protected]]
>> Sent: Tuesday, February 14, 2012 8:23 AM
>> To: [email protected]
>> Subject: 2.0.1 Resizing problem
>>
>> Hi,
>>
>> I have problem with resizing a Frame window, please take a look on the
>> code below (I tried to make it as simple as possible to show my
>> concerns, it's not pretty).
>>
>> public class BasicTest extends Application.Adapter {
>> static Frame frame;
>>
>> public void startup(Display display, Map<String, String> properties)
>> throws Exception {
>> frame = new Frame();
>> frame.open(display);
>> }
>>
>> public static void main(String[] args) throws Exception {
>> DesktopApplicationContext.main(BasicTest.class, new String[0]);
>>
>> Thread.sleep(2000); //to have a short while to take a look on the
>> displayed window
>>
>> frame.setHeight(100);
>> }
>> }
>>
>> When application starts we can see a main window and a very small
>> internal window (Frame) in it. After two seconds internal frame changes
>> its height to 100, I do it using frame.setHeight(100). But when you move
>> mouse over the main window Frame changes back it's height to the one
>> before we changed it to 100. Can you tell me what's wrong here?
>>
>> What's more interesting, when I use setPreferredHeight instead the
>> Frame's height is not changed until mouse is moved, which is of course
>> not good too.
>>
>> Regards,
>> Rafal
>>
>
>
> --
> Pozdrawiam,
> Rafał Gierusz
>
>
