It seems that after modification of a property in properties editor
(bottmo textareas) editor doesn't fire fileModified event (or
something similar).

Steps to reproduce:

1. open a properties file
2. select a property in properties editor table (e.g. column Key)
3. edit its key and comment in extareas Key, Comment

Result: appropriate cell's value is changing but properties file is
not set as changed

I've just verified that it behaves exactly the same way in NB 3.5.1.
The user can edit a single property without getting the "file
modified" flag updated. However, when a different key/value property
is selected for editing, the flag is updated and the file can be saved
as usual.

I don't agree this is a P1 bug. It's been around for a while and no
one seemed to notice. It's true the user may potential lose changes
made to a *single* property, so I still consider it a high priority
bug that should be addressed soon, though it's probably too late for 3.6.

I've found it working the same as 3.5.1 and older (I've learnt to live
with issue 30018 mentioned by Jan Chalupa) when I created a new
project and opened a bundle in it. But in my original project with cvs
filesystem imported from 3.5.1 IDE it behaves exactly as I described,
even changing the focus to the next row or any other action doesn't
change the state of the "Save" button, although the state of "Save
all" button changes. I consider it to be a bug which should definitely
be fixed in 3.6 final.

I've found a strange behavior: it behaves incorrectly when I start the
ide with imported project and also when I switch to any other project,
but it behaves as expected when I create a new project (no cvs
filesystem). It is probably related to the imported project (or cvs
filesystem?) somehow.

Uff, I've reproduced it. It seems it is problem with CVS filesystem.

Steps to reproduce:

1. import a project from NB 3.5 with mounted CVS filesystem
2. open this project
3. restart IDE
4. open a properties file from the imported CVS filesystem

The file cannot be saved after any modification.

Non-CVS filesystems did work right and other types of files too.

Martin E., can you please look at that? Could this really be a VCS
filesystem issue?

(Ignore the other issue described in bug #30018. It's clearly a
properties module problem.)

I am glad that you where able to find this issue. I tried to report it
in issue# 39927. But I didn't know how to reproduce it, but this
sounds exactly like what I was seeing.

I don't know if this is part of this bug but I have also seen where
after you save the properties file there is still a * in the tab of
the properties file. If it isn't I can submit a new bug.

Well, this issue looks quite strange to me. I'm not aware of any
mechanism in VCS modules, that would prevent from saving properties
files specifically.
Is anything in ide.log? Any exception thrown?

I could not reproduce it. Should I use "Open" or "Edit"? Did you mount
JavaCVS filesystem (built-in) or command-line filesystem in 3.5.1?

I created a project in NB 3.5. There was one VCS (command line)
mounted filesysystem. I imported this project into NB 36 and opened
(Open action) a properties file from the VCS filesystem.

I am using the built-in VCS system. It's working just normal when I
create a new filesystem in 3.6. The problem occurs after importing a
project from 3.5.1, in grid-editing mode (open).

Now I found it happens also when I create a new project and mount a
local directory which happens to be a subdirectory of a cvs local
repository

I only get this in the ide.log if it helps:

Note -
org.netbeans.modules.properties.PropertiesOpen$PropertiesCloneableTopComponent
ought to override getPersistenceType() rather than using the client
property or accepting the default.

Created attachment 14148 [details]
ide.log

The log shows that there is a problem after the file is saved - the
properties module tries to set name of TopComponent in non-AWT thread
- and window system does not allow this. The exception happens during
the SaveCookie removal. But it does not seem to cause this bug - at
least I can see the exception too and saving works for me.

We'll look at this for the post-3.6 NetBeans version.

More analysis: seems that this bug can be reproduced easily - just let
a properties file opened in the IDE and restart it - then the Save
action remains disabled (for that file). However, the file is marked
as changed and the user is prompted for saving changes when closing
it. So data loss should not happen. After reopening the file, the Save
action works well again. Save All action is enabled correctly and
works always. So I think this is not a showstopper for NB 3.6.

This could be a candidate for release notes:

"When editing a .properties file (if it stays opened between the IDE
restarts), it may happen that the Save action is not enabled and even
Ctrl+S does not work. If this happens, close the file - you will be
asked whether to save it. After reopening the file, everything should
work fine."

Thanks, Tomas. Proposed wording to be consistent with style of other
relnotes:

Description: If you leave a .properties file open between sessions of
the IDE, the Save command might become disabled.

Workarounds: To save the file, you can do one of the following:

* Close the file. You will be prompted to save the file.
* Choose File | Save All.

*** Issue 42109 has been marked as a duplicate of this issue. ***

*** Issue 42297 has been marked as a duplicate of this issue. ***

There were several problems mentioned in this issue:

1. The modifications in the currently selected cell
   is lost when Ctrl-S is pressed or File>Save action
   is invoked.

2. The "table editor" attempts to set name of its TopComponent
   from non-AWT thread.

3. When "table editor" is opened during IDE start (as a part
   of the deserialization of the previously opened editor)
   then save action doesn't work.

All these issues have been fixed.

Verified in nb200507181000.