This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When switching from one project to another, the project settings of the new projects are lost after restart. It seems that NB tries to load the setting for main class of the old project but cannot find that class (obviously because it's in a different project) leaving a corrupted project options file I have attached an ide.log where the error is reported. Note that WbManager.java belongs to the previously loaded project not to the current. After this the properties in Tools/Options/System/Project Options are empty. The only way to restore them is to delete org-netbeans-modules-projects-settings-ProjectOption.settings
Created attachment 8151 [details] ide.log with error
It seems that switching the project with 3.4.1 has more problems. I have just switched between to a different project, then back to the original one, and NB completely hang while switching back. The only way to get it working again, was to delete project.last. After starting NB again (skipping the settings import) I was able to switch from the default project to the desired one.
is it really a new defect in nb341 or is it already existing in 3.4 ?
The bug itself has been in 3.4 as well :-( I haven't seen 3.4 hang while switching project, but it never happened again with the dev builds after (approx) Jan 10 2003
Well, projects are under a huge rewrite in 4.0 Let's hope these errors vanish with it.
The mainclass problem should be fixed now in main trunk, please verify it. I am sorry to be late for 3.4.1.
Vitezslav, CVS log please, I'll make a patch and test it against release341 branch. If everything goes fine, we can do nbm with an updated module layed out on AutoUpdate server. Smth like 3.4.1 update1 NBM. Sounds?
Maxym, I am sorry to say this, but there is quite a big difference between trunk and release34 branch because of Open API separation (e.g. the TopManager doesn't exist anymore in trunk, etc.). Also this separation affected the core and projects module (which depends directly on core to be able to do some dirty things with layers on SystemFilesystem). That's why the diff of my fix in main trunk can't be simply applied to relase34 branch. However, if you think this is really ugly bug I can try to look at release34 code and think how to fix this particular problem there using 3.4 version of Open API.
Vitezslav, CVS logs are useful any way, even if they are not applicable to release341 branch. Have you read "HOWTO fix bugs NetBeans way" I post to nbdev? I may repeat: Exclusive NetBeans HOWTO ;-) 1. Never fix issues unless there's 10 duplicates in IssueZilla (big user feedback). 2. Never fix issues in the same version they were reported to. You live, let live the issues in the upcoming release too. NEW! 3. Never fix easy issues, look at them, mark as TBD (to be defined) and go on your business. 4. If you did such a foolish thing to fix an issue, commit, mark it FIXED and go on a vacation. The others won't need cvslogs anyway. Don't be offended, it's just for fun. I just want to change a situation to the better side. --------------- If you can, please look at the release341 branch code.
Hehe, I read already your HOWTOs. I can imagine that from IZ notifications the situation might look exactly as you wrote. That's bad. I promise to look at release341 branch and do the foolish think ;-).
Cannot reproduce, verified.