Home » Eclipse Projects » WindowBuilder » Workaround for WindowBuilder Problems?(WindowBuilder crashes due to JComboBox & sqLite interactions)
| Workaround for WindowBuilder Problems? [message #1786529] |
Sat, 05 May 2018 18:42  |
 Patrick Moran
Messages: 141
Registered: March 2018 |
Senior Member |
|
|
Limitations of WindowBuilder & How to Get Around them
Update:
I've fixed a few errors in the attached code. I still can't get the update, save, and delete buttons to work, and ComboBox stuff must be commented out to make it possible to work in design mode.
===============
I have been working for many, many hours to solve a problem that shows up in WindowBuilder. I don't want to become a professional Java programmer. I just want to get something I need for educational purposes built right. Peter Ream has already mentioned a problem with this same Java code that we both copied from an on-line tutorial. With certain parts of the received code in place, when you try to view it in Design mode, WindowBuilder will go into an infinite loop or something that acts like that, and it becomes necessary to force-quit Eclipse. I have traced the problem down to the two pieces of code that set up and use a JComboBox. With that functioning code deleted, one can open the program in Design mode, e.g., to add a JLabel for displaying photographs. Most of the things I wanted to add would not show up in Design mode if I added them in Source mode, which is not the way I have been told that WindowBuilder is supposed to be able to do. So I am stuck.
When I fix the GUI displays, of course the ComboBox is not visible because it has been commented out. But after I go back into Source mode, uncomment the ComboBox stuff, and run the program, the ComboBox is not there. Blast it, I'll have to go back into Design mode and redraw it. That worked, and I've set it up right, but of course this is a new JComboBox, so there is no code to tell it what to do. No problem, I'll just copy the missing stuff from the now-useless old JComboBox code. That should work, no?
When I do that and run the program, however, the ComboBox is visible, but it does not function. Surely I made a mistake in copying. However when I copy out the code, print it, and compare it line by line, there is no difference whatsoever. So now I am in Catch 22.2.
I suspect that WindowBuilder chokes on all the special calls to sqLite management code. Perhaps it can't do whatever it needs to do because the code is dependent on stuff in a couple of JARs.
Is there any application out there that can go directly from fairly complex Java code to GUI? WindowBuilder seems no longer to have that capability. I've not been able to get it to do the simplest GUI stuff beyond making labels show up on-screen.
Here are the two versions. To me, they look identical. They should look identical because I copied one from the other. I've printed out the working version and will go over the current version again in the morning. As it is, the program appears to ignore this stuff.
If I disable the ComboBox stuff I can start over on the visual representation of the ComboBox, get it to do the add action listener stuff, and go back to the source mode to patch in the needed code. As soon as I uncomment the ComboBox code, I can't use the Design mode anymore, so it seems best to pre=plan the whole Design mode stuff including action listeners for any buttons added (and add a few extra buttons to save annoyance down the road.
}
[Updated on: Sun, 06 May 2018 20:21] Report message to a moderator |
|
| |
| Re: Workaround for WindowBuilder Problems? [message #1786710 is a reply to message #1786581] |
Wed, 09 May 2018 17:23  |
Patrick Moran
Messages: 141
Registered: March 2018 |
Senior Member |
|
|
Thank you very much. Peter Ream recorded this problem two years ago, but he did not identify the real problem. I had figured out that the offending dynamic code could be commented out thereby making the project appear in design view. The use of code hiding tags works for getting access to the design mode too, but when I tried it the code with those tags in it would not compile properly. I thought maybe I'd done something wrong.
I tried again with a new copy of the code, and just hid a small part of the code having to do with showing a photo. When I compiled it, another project in the same workspace was opened. I thought it was operator error, but when I tried with earlier, untouched, versions of the same code, I still got a single picture and it was clear that the other program was being run.
I had to make a new workspace and copy in an early copy in a third workspace to get things back to normal. So I don't think the "hide" method is any good. I can get the same result by commenting out the dynamic code.
Thank you for confirming my guess that it was the "dynamic" stuff (having to deal with taking in information from a DB and processing it) that was causing the problem.
[Updated on: Wed, 09 May 2018 18:46] Report message to a moderator |
|
| |
| Re: Workaround for WindowBuilder Problems? [message #1786734 is a reply to message #1786728] |
Thu, 10 May 2018 07:53 |
Patrick Moran
Messages: 141
Registered: March 2018 |
Senior Member |
|
|
I thought that was the way the hide tags were supposed to work. I opened a spare copy of my most recent code, put them in, took a look in the Design mode while all the Combo box stuff was hidden. I don't recall adding anything in the design mode. I went back to the source mode and hit "run." There are a couple of messages that are set off before the regular screen appears. One is a confirmation that the running program has found the object that makes contact with the database. Another is just a left-over debugging statement that I always forget to track down and delete. Ordinarily it may take a while for these messages to show up, but then when I click through them the actual GUI aspect of the program is manifested almost immediately and I can access data with it, etc. But when I tried running it yesterday afternoon, I just got a blank screen after the database confirmation and the odd debugging message showed up.
I next tried opening the other spare copy of the program, thinking I could just delete the other one since I couldn't figure out what was wrong with it, and I discovered that it was doing the same kind of non-performance. I checked the "date modified" on these two files. One was changed at 2:33 yesterday afternoon, and the other was changed at 2:34.
Thanks for your help.
I've seen a fairly regular succession of incidents similar to this since I started using Eclipse. I'm on a Mac running the newest OS.
I had a copy of a simple program to display a jpg image on screen, and the program that we've been talking about, all in the fifth workspace, I had been trying to add a picture display box to the L-Method stuff, and I had made the simple photo display in a separate project to make sure that it was working properly. But when I ran the L-Method project, only the photo from the other program showed up. I couldn't find anything in the L-Method code to explain this anomaly, so I had to dig up a working copy of the L-Method code, and make workspace 6 with it. Then when I got that established and checked out, I made a couple of spare copies, and moved one to put in my workspace 6.
When I was doing a lot of C programming, I learned to put a copy of anything good on another disk and stash the disk far out of reach so I wouldn't get overly excited and corrupt it along with its successor versions. That still seems like a good idea. But in those days there was very little "under the hood" that I couldn't account for except for the system calls to the Mac OS (I mean that stuff that handles all the graphics, primarily). I would occasionally get results that indicated that their documentation wasn't exactly right, but ordinarily if something went wrong it was clearly my mistake and clearly right there to be found if I printed out the code and look at it attentively.
Fortunately I could go back to an earlier workspace, get a good copy, and copy it into a new workspace.
|
|
| | | |
Goto Forum:
Current Time: Fri Apr 19 08:47:30 GMT 2024
Powered by FUDForum. Page generated in 0.02727 seconds |
] 
Search
Help
Register
Login
Home
