Created attachment 37390 [details]
stacktrace

please, do not paste long stacktraces to comments. Add them as attachments. It's
easier to search for duplicates later.

I do not know how to improve the new-file creation. It is still the same problem
with data-object invalidation. Adame, do you how to solve this for asure 100%
fix. It looks like the data-object invalidation is done asynchronously since the
re-validation is always done after the new-file creation.

Created attachment 37394 [details]
another log

Another exception (see attachment above): close IDE, remove visualMidlet.java,
visualMidlet.form in th filesystem. Start IDE, try to create new visual midlet.

The second exception is related to a general problem in FileSystems module.
External file deletion is not automatically propagated to the FileSystem layer.
Since the layer caches file descriptors then it still thinks that the file still
exists. Maybe invoking "File | Refresh All Files" main menu action would help you.

still happens in 0119 build when creating new visual midlet

definitely stopper for M7, really annoying issue that confuses users when they
creates a new file

seems that the issue disappeared. I'll remove it from stoppers list tomorrow if
it won't appear.

It was fixed a few weeks ago.

ok, then verifying. I haven't seen it for long time

trunk Feb/20/2007 - the exception is still there though the stacktrace looks
different. Reopening.

Created attachment 38728 [details]
stacktrace

removing it from M7 stoppers list. Doesn't happen in M7 (at least it haven't
happened to me or Fabi). 
Seems that's neverending story. There are 4 weeks till next milestone. Please
fix it with cooperation with other teams.

Created attachment 38806 [details]
another exception with latest(0222) David's hack

A partial workaround has been added. It is forcing the refresh of fileobjects in
parent folder right after a new file is created. This should enforce data-object
revalidation.

Created attachment 38808 [details]
DataObject invalidation within the DataObject.createFromTemplate method call

Created attachment 38809 [details]
DataObject invalidation within asynchronous FolderList.Task.run method call

Jardo, could you please look at invalidate-within-createFromTemplate.txt and
invalidate-asynchronously-within-folder-list.txt stack traces? Thanks.

The first is happening most of the time, and therefore the DataObject returned
by DataObject.createFromTemplate method is returned as invalid.

The second stack invalidation is happening rarely and is not covered by our
workaround.

Here is the workaround:
// reqular code
DataObject fromTemplate = tpl.createFromTemplate (target, name);
// this reduces amount of "uncovered" cases to +- 1%
fromTemplate.getPrimaryFile ().getParent ().refresh (true);
// this a simple workaround for invalidation
// within the "DataObject.createFromTeamplate" method call:
fromTemplate = DataObject.find (fromTemplate.getPrimaryFile ());

Adding dependency on issue #95399. After switching to FreeMaker, the file
creation should not use refactoring at all and therefore the data-object should
not be invalidated.

After fixing the issue issue #95399, the workaround above is going to be removed.

Observed the same issue :
Build : 20070311 with JDK 1.6 on XP.

Creating CDC application.
After adding CDC platform Exception poped in the IDE.

This bug is caused by issue #95399. Setting Target milestone to 6.0.

Adame, the FreeMaker was integrated. Could you change the new-file creation to
the new API. For more info see:
http://www.netbeans.org/download/dev/javadoc/org-openide-loaders/apichanges.html#scripting
The Designer1 and Designer2 are going to use ${name} and ${user} attributes and
license section.
Thanks.

Adding dependency on issue #100763 which describes endless-loop while FreeMarker
engine is used.

Fixed in main trunk.

Created attachment 41480 [details]
stacktrace from 0423 build

reopening - happend when creating new Visual Midlet in 0423 build. I used the
NBI standard installer

Issue #102629 is the root cause of this issue.

The issue #102629 has been fixed in main trunk. Therefore removing the
workaround (in FileWizardIterator) from main trunk.
Still leaving the issue open, since the issue #102629 is not fixed in Milestone 9.

changing the Target Milestone to TBD because the origin one finished already.
Please reschedule

Setting a TM to 6.0M9 since the issue #102629 was fixed on the second in
Milestone 9. The fix makes this issue to be fixed.

this issue is back. Roumen, had to skipped the Mobility demo with M9 because of the exception. I'm not sure that is the
same behavior. It happened to him when created CDC project.

Roumen, do you have the stacktrace? Please, assign it here and reopen or fill a new issue when it's different to those
already attached. 
thanks

roumene, what build exactly are you using?

Version: NetBeans IDE 6.0 Preview (M9, build 070501)

I do not have the full stacktrace (for some reason it is not in messages.log) but this is what I found in uigestures:

<message>java.lang.IllegalStateException: The data object
MasterFileObject@ab2113[C:/demo/CdcApplication7/src/cdcapplication7/Main.java] is invalid; you may not call
getNodeDelegate on it any more; see #17020 and please fix your code</message> 

This new IllegalAccessException is not completely a new issue. It is caused by file templates in CLDC and CDC project
modules which are not converted to use Template-Scripting feature.

Sorry for typo:
The new appearance of the issue is not related to Visual Designer. It is caused in CLDC and CDC project modules.

if this is caused by old templates style then it is already fixed in M10

verified in beta1 09/11 build