Skip to main content

Of Netbeans form files, Widget macros and Matisse.

Posted by panaseam on October 29, 2006 at 1:18 PM PST

Just recently I've been tinkering with my project particularly in the realm of

“Widget tweaking”. I won't bore you with the details, but suffice to say that

“Something strange happened to me on the way to the repository!”

Basically I was editing my component source then checking that my changes worked OK in

Netbeans. The problem occurred when I made a mistake in a container class and the IDE

registered it as a component. I investigated the problem, saw my stupid mistake and rectified it.

So having closed my test form in the IDE, I reopened it but, to my dismay, the damn thing was

still not behaving like a container. My first thought was that the class was not being unloaded

by the VM. So I put a bit of code in to fire a message box. This worked, so the IDE was

obviously doing the right thing with class loading (I never doubted it really!) but the thing

was still registered as a sub component.

I then tried adding another instance of my container class and “lo and behold” this correctly

registered itself as a container.Then the penny dropped. I opened the form file in another editor

and sure enough there was my original instance tagged as a component

and my new instance tagged as a container.

Now I'm sure many people will think “how stupid can this guy be?” either because they think I

should use Eclipse or simply that I should have known Netbeans would retain the original tag.

Well firstly, as there is only me on this project, making my widgets usable with Eclipse is still

on the “to do” list, secondly, I suppose I did know about the contents of the form file but it just

didn't dawn on me at the time. Of course it is, perhaps, an example of why some people do not

like the idea of the form file controlling what happens in the IDE.

I can see there are pro's and con's to the concept of a separate IDE control file, with it the

integrity of the IDE generated stuff is probably safer from inadvertently screwing up by

editing the source in another editor. But on the con side it is another file that must be

maintained and if somehow it got out of sync with the java source ar worse still if it got lost...!

Well it just doesn't bear thinking about.

Anyway, the aim of this blog was not to start another Netbeans vs Eclipse (or any other IDE)

flame war, it's about my fun and games with creating compound components or widgets as I

prefer to call them which leads me to my next point, which is more of a request for comment.

Widget Macros (or Macro Widgets).

Whilst getting confused with the niceties, or otherwise, of Netbeans form files, I started musing

about the problem of compound widgets in an IDE. What I mean is creating a widget

that contains sub components. Obviously the IDE has no visibility to the inner components of

such a compound widget. This can be a pain if you just want to tweak an odd property as you

either have to wrap the required sub component methods in your widget class API or you could

provide access to the sub components with suitable getter methods, but it isn't very elegant.

So what I wondered was, and this could apply to any IDE, would it be feasible to derive a sort

of macro approach where a compound widget could be assembled using the IDE as if it were

a normal form and then saved, in source form, as a macro “template” which could be inserted

into a real form at design time, expanded out so that all the inner parts of the widget became

separately visible to the IDE but bound together in some way to prevent breaking the

predefined relationship of the widget's sub components.

It's probably a daft idea, or it's already been done. But I just wondered what anyone thinks?

Also: Matisse and ScollPanes who's in control?

Whilst on the subject of IDEs, or Netbeans in particular. Is there any way to stop Matisse

automatically adding a JScrollPane when you add a Scrollable component?

I couldn't find any way but it could be I never looked in the right place!

The reason I ask is that in the earlier version of my project I had created a JTextArea and a JList

subclass that, at run time, automatically added a JScrollPane as an instance of either got added

to my custom subclassed JPanel container.

Matisse adding its own JScrollPane in such a case was a nuisance as it was not obvious to an

end user that they must remove that JScrollPane. The new version of my widget appears to the

IDE as a JComponent so Matisse ignores it, so the problem has gone away at the moment.

I just wondered if there was an easy fix?

If there isn't, then I would respectfully suggest there should be!

Any automatic feature, no matter how brilliant should always allow the end user to switch it

off if required.

The switch should be a property associated with any form class so that templates can be

created with the feature switched off if necessary. Or, alternatively, it should be possible to

mark a widget class so that the feature was disabled even though the class implements Scrollable.

Just my two pennies worth.

Anyway enough of my ramblings!

Happy hacking,


Related Topics >>