|
 |
Yesterday I was sitting at my PC, listening to Alisha's Attic and coding
in Java.
So... doing what I was doing 10 years ago, then. :-P
Some things change, others remain the same. Java ditched the Abstract
Window Toolkit and went with Swing. It's still absurdly over-complicated
and confusing. At least it appears to be very slightly better
documented. (Thankfully, NetBeans has a UI painter. Weirdly, it doesn't
let you specify alignment constraints or anything more sophisticated
then "put this button here". So if you resize the window, it's anybody's
guess what will happen.)
Figuring out how to do a tree view was fun. Fortunately, there's a
tutorial. Otherwise I would never have figured out that each tree node
is an object of class DefaultMutableTreeNode. (DefaultTreeNode won't cut
it, apparently.) I'm still waiting on why you need a JTree object
pointing to a DefaultMutableTreeModel object which /then/ points to a
DefaultMutableTreeNode representing the root of the actual tree being
displayed...
Just like in the old days, there are some very odd design decisions. For
example, you would /think/ that the tree would default to being
expanded. Failing that, you might guess that defaulting to being
collapsed would be reasonable. But in fact, Swing does neither. What it
/actually/ does is that _the root node_ defaults to being expanded,
while all other nodes default to being collapsed. Nice consistency
there. :-P
You would think there would be a method that says "expend this tree
node". Well, there isn't. Instead, what you have to do is create a "tree
path" object which describes the location of the tree node you want to
expand. Or, alternatively, you can use a row number. (Christ only knows
how /that/ actually works!) You might expect to find an "expand all"
method, with a matching "collapse all" method. You would be
disappointed. Yes, if you just want to expand all the nodes in the tree,
you have to actually manually write a for-loop to repeatedly call the
expand() method.
Also, depending on exactly which way you modify the tree, you may or may
not have to call reload() on the tree widget (not the tree model or the
tree root or the tree node you just changed) to make the change visible.
Otherwise the change only becomes visible if the window has to repaint
for some reason. No, hiding and revealing the window does not make it
repaint. But resizing it does.
Just like in the old days, things are still a bit buggy. For example,
Swing has a random feature where if some display text begins with the
token "<html>", then some but not all HTML formatting commands are
accepted. Of course, in real HTML, you'd mark chunks of stuff with tags,
and then use CSS to decide how to actually format that. Swing appear to
only understand raw HTML formatting commands. Naturally, the exact set
of commands supported is not documented anywhere.
The really buggy thing though is this: If you disable a widget, its
label goes grey. But if the widget uses HTML formatting, the text no
longer turns grey. Presumably because they haven't figured out how to
combine that with the HTML formatting. (Surely the solution is just to
apply a little alpha blending...)
There's a ticket for it on the bug tracker. But it's not marked as a
bug, but rather as a "feature request". (Yes, that's right. The software
working correctly in a certain special case is a "feature request", not
a basic expectation.) The priority is set to "very low". There are
thousands of replies, most of them containing elaborate Java source code
to work around the problem. People - THIS IS NOT HOW TO CREATE QUALITY
SOFTWARE! >_<
In other news, there appears to be no way to make NetBeans halt on
exceptions. Like, if an exception is thrown, I would like to halt the
debugger at the line where it was thrown, so I can inspect the program
state and, you know, /debug it/. But apparently no, you cannot do that.
Because technically, the exception is thrown, and then /caught/ by the
top-level exception handler. And handled exceptions "don't count". Never
mind the fact that Java's checked exceptions mentality /requires/ you to
catch all exceptions. Your code actually won't compile (and hence won't
run) if you don't do this. *sigh*
I have at least found out how to single-step Java code in the debugger
now. But that doesn't work at all with GUI code. You can't single-step
into an event handler that only runs when the user clicks a button. You
also apparently cannot set breakpoints - I can only presume because the
code runs in a thread other than the one the debugger was expecting.
Seriously, nobody thought to test that one?
In about two days of coding, I did manage to write my program, and have
it work. It's ages since I wrote a program with a real, native-looking
GUI. I'd forgotten how satisfying that is. (When it actually works!) But
now one of the program features has a small bug in it, which I am
seemingly powerless to track down. Time for the next iteration of my
prototyping...
Post a reply to this message
|
|
