setVisible "Lost in the weeds"?

[Jim Crowell]

Systems:
I am using Eclipse 2.1.3 on a Win XP platform to develop a Java 1.3.2
Stand Alone App.

The app extends JFrame that then host a set of TAB's designed to
provide a user friendly Form Centric App.

The app is working well but a new anomaly has appeared.

In my main class I instance the app as follows:
myApp app = new MyApp(args[0] ...);

I follow that line with a "app.setVisible(true);" command.

The problem:
About 20 % of the time there is no return from the 'setVisible' request
and the JFrame of the app is not shown.

I used the debugger to follow the 'setVisible' process and deduced that
the hang up was in the validate method. Going in there gets me into
things that I just do not understand.

I then changed the 'app.setVisible(true);' command to 'app.validate()'
and placed sysout command before and after. Each time my app hangs up I
never see the "Return from 'validate' printout.

Comment:
Over time my biggest problem with Java has been focus problems.
I am looking to produce a stable, robust stand alone app but keep
running into problems similar to this one.
Over the last few months I have written a precise set of requirements
["Focus Change Event Processing"] and unit test to define focus rules.
I was finally confident that I had taken control of the Java
environment until the above problem appeared.

Question:
Any ideas on what can be causing the above irreguality or what else I
can be doing to get control over this environment?

I do not understand peers very well.
Is there a chance that the problem is 'peer' related?
I have a Mac OS X [panther] system that I plan to test this app on.
Should I run the test on that computer to determine if the problem is
platform related.
That is a bit of a tangent from my planned development process but
could be done if you think it will aid in solving this problem. Please
advise!

FYI:
I have used 'sysout' to write the following 'app' instance parameters
following the return from the above 'new' command:

peer Name = sun.awt.windows.WFramePeer
'app.isValid' = false
'app.isVisible' = true

The above output is the same for the working and the hang up
executions.

Thanks
Jim C.

 

[IchBin]

Systems:
I am using Eclipse 2.1.3 on a Win XP platform to develop a Java 1.3.2
Stand Alone App.

The app extends JFrame that then host a set of TAB's designed to
provide a user friendly Form Centric App.

The app is working well but a new anomaly has appeared.

In my main class I instance the app as follows:
myApp app = new MyApp(args[0] ...);

I follow that line with a "app.setVisible(true);" command.

The problem:
About 20 % of the time there is no return from the 'setVisible' request
and the JFrame of the app is not shown.

I used the debugger to follow the 'setVisible' process and deduced that
the hang up was in the validate method. Going in there gets me into
things that I just do not understand.

I then changed the 'app.setVisible(true);' command to 'app.validate()'
and placed sysout command before and after. Each time my app hangs up I
never see the "Return from 'validate' printout.

Comment:
Over time my biggest problem with Java has been focus problems.
I am looking to produce a stable, robust stand alone app but keep
running into problems similar to this one.
Over the last few months I have written a precise set of requirements
["Focus Change Event Processing"] and unit test to define focus rules.
I was finally confident that I had taken control of the Java
environment until the above problem appeared.

Question:
Any ideas on what can be causing the above irreguality or what else I
can be doing to get control over this environment?

I do not understand peers very well.
Is there a chance that the problem is 'peer' related?
I have a Mac OS X [panther] system that I plan to test this app on.
Should I run the test on that computer to determine if the problem is
platform related.
That is a bit of a tangent from my planned development process but
could be done if you think it will aid in solving this problem. Please
advise!

FYI:
I have used 'sysout' to write the following 'app' instance parameters
following the return from the above 'new' command:

peer Name = sun.awt.windows.WFramePeer
'app.isValid' = false
'app.isVisible' = true

The above output is the same for the working and the hang up
executions.

Thanks
Jim C.

Not look at the problem. Right off the top you are using an old version
of Eclipse and very old version of JDK.. This will more than likely not
be a problem but you can't upgrade Eclipse to at least to 3.1 and Java
to 1.5?


Thanks in Advance...
IchBin, Pocono Lake, Pa, USA
http://weconsultants.servebeer.com/JHackerAppManager
__________________________________________________________________________

'If there is one, Knowledge is the "Fountain of Youth"'
-William E. Taylor, Regular Guy (1952-)

 

[Chris Uppal]

The problem:
About 20 % of the time there is no return from the 'setVisible' request
and the JFrame of the app is not shown.

Have you tried putting all of your initialisation code onto the AWT thread
(EDT) ? If not then that might be worth a shot.

-- chris

 

[steve]

Systems:
I am using Eclipse 2.1.3 on a Win XP platform to develop a Java 1.3.2
Stand Alone App.

The app extends JFrame that then host a set of TAB's designed to
provide a user friendly Form Centric App.

The app is working well but a new anomaly has appeared.

In my main class I instance the app as follows:
myApp app = new MyApp(args[0] ...);

I follow that line with a "app.setVisible(true);" command.

The problem:
About 20 % of the time there is no return from the 'setVisible' request
and the JFrame of the app is not shown.

I used the debugger to follow the 'setVisible' process and deduced that
the hang up was in the validate method. Going in there gets me into
things that I just do not understand.

I then changed the 'app.setVisible(true);' command to 'app.validate()'
and placed sysout command before and after. Each time my app hangs up I
never see the "Return from 'validate' printout.

Comment:
Over time my biggest problem with Java has been focus problems.
I am looking to produce a stable, robust stand alone app but keep
running into problems similar to this one.
Over the last few months I have written a precise set of requirements
["Focus Change Event Processing"] and unit test to define focus rules.
I was finally confident that I had taken control of the Java
environment until the above problem appeared.

Question:
Any ideas on what can be causing the above irreguality or what else I
can be doing to get control over this environment?

I do not understand peers very well.
Is there a chance that the problem is 'peer' related?
I have a Mac OS X [panther] system that I plan to test this app on.
Should I run the test on that computer to determine if the problem is
platform related.
That is a bit of a tangent from my planned development process but
could be done if you think it will aid in solving this problem. Please
advise!

FYI:
I have used 'sysout' to write the following 'app' instance parameters
following the return from the above 'new' command:

peer Name = sun.awt.windows.WFramePeer
'app.isValid' = false
'app.isVisible' = true

The above output is the same for the working and the hang up
executions.

Thanks
Jim C.

this looks like a threading issue, but you could try it on the mac, so that
it is against the latest JVM.
But seriously you should be looking at getting the latest 1.4 jvm onto your
system , unless you are specifically tied to 1.3

steve

 

[Jim Crowell]

Have you tried putting all of your initialisation code onto the AWT thread
(EDT) ? If not then that might be worth a shot.

That fixed my problem, many thanks.

I used the following approach:
public class MyApp {
MyApp() {
}
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable() {
public void run() {
new MyApp();
}
});
} }

I tested it 13 times in a row with no hangups.

The only problem I encountered was a 'null' Pointer error when I used
the
'KeyboardFocusManager.getCurrentKeyboardFocusManager'.getActiveWindow'
method.

I added a check for a 'null' Active Window and everything is fine now.
The 'null' check should have been programmed anyway.

Any idea as to why the KeyBoardFocusManager is affected by the above
'invokeLater' processing?

Regards,
Jim C.

 

[Jim Crowell]

Not look at the problem. Right off the top you are using an old version
of Eclipse and very old version of JDK.. This will more than likely not
be a problem but you can't upgrade Eclipse to at least to 3.1 and Java
to 1.5?

I had a typeO error in my initial message in that I am actually using
Java 1.4.2_08.

I just checked the Sun site and see that there is a J2SE for 1.4.2_12.
I stopped looking for updates after 1.5 was released.
I'll update to the latest and greatest 1.4.2 today.

Why not 1.5?
I do not need any of the new stuff for my app yet and my history has
been
that a new version update has caused me more work than I expected.
Actually the Java 1.4 update went well but I'm still gun shy about
updating until I have to.

The older Eclipse version is a "my ignorance" problem [once again].
I did the download and insall for 3.1 but found that the Project setup
had changed
and I could not figure out how to convert my current Project to the new
approach.

I am developing a Java Package [com.MyPackage] that is designed to
produce a Java StandAlone Application. I test it from a class [MyApp]
that extends the MyProgram Class.
I have the test Java programs in a C:/TestMyPackage/ folder and the
'MyPackage' source in the
C:/TestMYPackage/com/MyPackage folder.

Ideally I would like to host the 'MyPackage' source in a
C:/com.MyPackage/ folder but I could not get that to work even in my
Eclipse 2.1.3 setup.

I started all this just using the EMacs Editor with the JDE plugin on a
Linux platform.

FYI: I did EMacs on Windows 98 for awhile but switched to Linux because
of Win hangups,

EMacs was nice because I was using command line execution and setup the
Java environment using classpath, etc. which I could understand.

I switched to Elipse and Win XP a couple years ago because I wanted the
"Refacturing", JavDoc Comment Tool, etc. capability.

I can't seem to get the setup right in the Eclipse 3.1 version so I
just stuck with what works,
i.e. Eclipse 2.1.3.

I have the "The Java Developers Guide to Eclipse" book that I found
useful in setting up my 2.1.3 Project. It is written to Eclipse SDK
2.0.

Eclipse is nice and I would like to keep up with it's releases but can
not afford a lot of learning curve time.

Thanks,

Jim C.

 

[Jim Crowell]

this looks like a threading issue, but you could try it on the mac, so that
it is against the latest JVM.
But seriously you should be looking at getting the latest 1.4 jvm onto your
system , unless you are specifically tied to 1.3

Thanks Steve,

It was a threading problem. See my response to Chris Uppal.

I had a typeO error in my initial message in that I am actually using
Java 1.4.2_08.

I just checked the Sun site and see that there is a J2SE for 1.4.2_12.
I stopped looking for updates after 1.5 was released.
I'll update to the latest and greatest 1.4.2 today.

Jim C.

 

[Chris Uppal]

Any idea as to why the KeyBoardFocusManager is affected by the above
'invokeLater' processing?

None at all, I'm afraid.

The best I can offer is the observation that if you treat AWT's internals --
especially the initialisation -- as a massively complicated, bug-riddled, and
under-designed muddle, then you won't go far wrong.

I'm not suggesting it /is/ that, mind you[*], but it's good working
assumption -- in much the same way as it's often sensible to write user-facing
code as if the users were all malicious idiots.

-- chris

[*] From what little I've seen of it, the code looks reasonable enough, and the
problems appear to be more about the difficulties of OS integration than [lack
of] quality in code or design.