 |
|
 |
 |
|
|
 Pete Morgan's BlogSwing ArchivesOf Netbeans form files, Widget macros and Matisse.Posted by panaseam on October 29, 2006 at 01:18 PM | Permalink | Comments (0)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, Pete | |
 java.net RSS Feeds
|
