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.
Hi, I've now encountered many occasions where the code is not correctly processed when I switch between configurations. Only those files that are open in the editor seem to be affected when switching configurations, when it comes to pre-processing. This is very tedious, since it means that I need to keep many files open all the time. It has now happened various times that even though I closed NB with some configuration, the related code-blocks are commented out (I'm using abilities) when I re-open NB, although they belong to the currently selected configuration (or rather the currently selected configuration has an ability but the code for that ability is commented out, although it wasn't when I closed NB).
all files are always stored in DefaultConfiguration on disc. Otherwise change of configuration would result in a modified file and thus CVS collision. When opened in the editor files are preprocessed and shown in current configuration which allow users to use the right code completion, etc. On save, files are preprocessed back to DefaultConfiguration. During build (even outside the IDE) *all* files are preprocessed and result can be found in build/preprocessed. So this is not a bug. If it causes you any other problem, please feel free to attach more information otherwise this issue will be closed.
Well if this is the case as you describe, than there is actually something wrong in 4.1, since I get repeatedly the wrong pre-processor block 'active'. In fact, yesterday I opened a file which has specific code for Nokia phones and I have an ability called NOKIA, which is added to all Nokia configurations but not to DefaultConfiguration. I opened the file and it opened with DefaultConfiguration, but the code for the NOKIA ability was active. Only after switching to another configuration and back to DefaultConfiguration, that code was correctly commented and the !NOKIA code was active. In addition, I had checked in my sources while they had switched to DefaultConfiguration and a colleague of mine checked it out and compiled it, but he had compiler-errors due to code that was related again to the NOKIA specific code, although he had DefaultConfiguration selected as well. I think that your solution of storing the files always in DefaultConfiguration is great and it works well, but I still have these problems (BTW I never experienced these with 4.0 for which I had much more complex device- fragmentation like support for Nokia, Siemens and Sony-Ericcson devices as well as CLDC 1.0, 1.1 and MIDP 1.0 and 2.0 specific configurations). I have an enhancement (will file it separately as well) regarding device- fragmentation and CVS: Is it possible to only have NB say that a file has changed when it really has changed and not when I have only switched between configurations? As you said, the DefaultConfiguration is always on disk, so in fact this should already be the case, but it isn't. But I'll file an enhancment request for this. Thanks, Iwan
If you have any reproducible case where sources are physically stored in a different state then DefaultConfiguration (and related abilities) it is a serious preprocessor problem. Could you, please, attach zipped fragment of the code and project meta-information (nbproject folder). The other issue is marking the files as modified inside IDE (the star behind the name in editor) when switching the configuration. This issue has been fixed just last week in the next version of NetBeans Mobility. But saving the "modified" file after configuration switch should not change the file content. The only confusion may happen when changing abilities of the DefaultConfiguration - then there is no implicit re-preprocessing of the all source files. I'll think what can we do in that case.
Ok, here's a subset of the project I use, it contains a file where the probably consistently occurs, I also included the depending files, so it should be compilable. I also included the nbproject dir in the zip. I'm sorry but I can't attach my whole project. If you need more code, I can probably send it directly to you. Just to help you out on the source SplashScreen.java. There're 2 abilities we have here. One is NOKIA, the other is BigScreen. DefaultConfiguration has the ability BigScreen but not NOKIA. As you can see, the code for BigScreen is commented, as soon as I switch from DefaultConfiguration to Nokia_Series_40 for example (which has the NOKIA ability but not the BigScreen ability) the code changes. When I get back to DefaultScreen the NOKIA stuff is commented and the BigScreen is uncommented. You can see this behavior in the screenshots I included. Hope this helps. Iwan
Created attachment 24765 [details] Relevant files for this issue as per request.
Created attachment 24766 [details] Initial view of relevant file
Created attachment 24767 [details] View of changing from DefaultConfiguration to something else
Created attachment 24768 [details] View of changing back to DefaultConfiguration from something else
First thank you for the code - it helps a lot. Yes, you are right - there is a race condition. I found that abilities are sometimes incorrectly recognized in two cases: 1. during first load into editor 2. during save when converting into default configuration The impact is that source files may be save in default configuration but not respecting the abilities assigned to the default configuration. And that file opened into editor for a first time may have wrong ability preprocessor blocks commented out. The good news is that this issue is already fixed in the upcomming release (the corresponding code has been completely changed). Other good news is that this issue should not affect build process where all abilities are taken directly from project.properties and I found no problem in preprocessing. Annoying part of this issue is that configuration has to be switched to get correct commented blocks in editor in same cases. Another confusion may be cased by difference between stored "canonical" sources and the sources preprocessed to the default configuration. I am sorry about that and I would like to encourage you to temporary live with the "switch configuration" workaround and look forward to NetBeans 5.0 Beta.
verifying all old issues