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.

Bug 14998 - NewFromTemplate=>doesn't remember location where it was invoked
Summary: NewFromTemplate=>doesn't remember location where it was invoked
Status: CLOSED INVALID
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC All
: P3 blocker (vote)
Assignee: akemr
URL:
Keywords:
: 11910 15157 15170 (view as bug list)
Depends on: 14999
Blocks:
  Show dependency tree
 
Reported: 2001-08-31 09:21 UTC by dmladek
Modified: 2008-12-22 16:41 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dmladek 2001-08-31 09:21:12 UTC
[NBdev-200108310100]
rh70,jdk1.3.0_04
=====================
Have at least mounted 2 FSs.
on already mounted FS create new package.
select this package and invoke popup menu and select:
eg. New->Classes->Class

in the First Wizard Panel is thrown NPE (another dependend issue)
and it doesn't remeberlocation (packaga and FS, where you invoke the Wizard)
simply you must choose right FS again, and again choose location where do you
wish to create this file.
Comment 1 dmladek 2001-08-31 09:24:19 UTC
as I already said this issue is probably depends on issue #14999
Comment 2 dmladek 2001-08-31 10:47:39 UTC
Because sometimes (but very ocasionaly) might happen that it remember
the position. Jirka came up with 100% reproduction procedure:

if you aren't able to reproduce it:
1.close ide
2.delete your nbdev dir
3. start ide (with clear user settings)

now you must be able to reproduce it.
Comment 3 Pavel Buzek 2001-09-04 08:44:41 UTC
Daniel, can you attach the NPE?
Comment 4 dmladek 2001-09-04 09:34:22 UTC
I fired 2 bugs for this matter with wizard.
the NPE is attached in issue #14999 and this bug is already fixed AFAIK;-)

But this bug: I mean it doesn't remember package and FS on which you
invoke the Wizard, still persists:-(
Simply it's quite annoying to looking for a package where you wish to
create your source file by expanding FS nodes:-(((

I thought that those 2 bugs had some kinda of relationship between
them, but maybe I was wrong?
Comment 5 Svata Dedic 2001-09-04 10:01:04 UTC
Is this problem only with New -> Classes | Forms (that is objects
which have custom Class Wizard attached to it) or even with simple
objects, like text file or html file ?
Comment 6 dmladek 2001-09-04 11:07:08 UTC
The Other object types:txt, html
don't have the panel where you specify their location. So it doesn't
offer its location AND desired file is created in the wanted folder.
I've tried it repeatedly, then the wizard for JAVA files started
remember the location where the TEXT file was created, but when I
wanted to created on the different location it still remember the
previous one till I didn't create here a TEXT file....

seem that some variable isn't inicialized and  filed when you start
CLASS/JAVA wizard.


Comment 7 Svata Dedic 2001-09-06 16:57:36 UTC
Lowering priority. If unhappy, please provide a justification.
Reassigning to java module -- since it hapens only in java class 
generation and since I've created my private copy of the location 
chooser.
Comment 8 Svata Dedic 2001-09-07 07:18:42 UTC
*** Issue 15170 has been marked as a duplicate of this issue. ***
Comment 9 Jan Chalupa 2001-09-07 09:57:29 UTC
Raising the priority back to P2.

Justification:

- it's a regression
- it's very annoying; if you fail to notice that the file you're 
creating is not to be put into the folder/package you've selected, 
you need to move the file afterwards

Comment 10 Jan Zajicek 2001-09-07 13:38:34 UTC
*** Issue 15157 has been marked as a duplicate of this issue. ***
Comment 11 Svata Dedic 2001-09-07 20:06:41 UTC
OK.
For the records, I claim that it is *NOT* specific to java module or 
java module-provided iterator. I claim that the bug was not 
discovered, because it was hidden by other bug, which I've 
discovered and reported against WizardDescriptor today.

Reproduction steps:
1. Start fresh NetBeans. Disable  java module, if you want and 
restart  (just in case).
2. Dive down and select some file (not a folder, this is important)
3. Invoke (using main menu) File | New, or use New from Template 
toolbar button (not a context menu)
Template chooser should appear.
4. Select some stupid template - like Text. Don't select java, 
beans, form or JSP templates.
5. Press Next. Target location chooser should appear. Press Cancel

6. Now, go to any folder and select it.
7. Bring up popup menu, select Add -> Other -> other stupid 
template, like properties (or text)

Now, according to UI people, you should see only *name chooser*, but 
the IDE will display full target chooser.
The target chooser does not reflect the position in the filesystem 
tree.
THIS is the P-2 bug reported in this page.

My investigation:
This bug was hidden by another one: if the N.F.T wizard was first 
invoked on a *folder*, from that point on it will *always* display 
simple name chooser and *never* full location chooser. This was 
already reported against openide.
Because of this bug, Joe the user gets always only name chooser, not 
the full one.
I commited a fix for other issues, which involved another 
implementation of target chooser logic, which always displayed full 
chooser, regardless of previous invocations (that is good) and 
regardless of how the wizard was invoked (context menu, main menu - 
that is bad, of course). The appearance of full chooser made this 
bug more visible.


My conclusion:
- Java module-specific code was not involved in this process
- The buggy code is wholly in openide
- The bug was most probably caused in TemplateWizard rev. 1.36, 
which commented out implementation of setTargetFolder() that updated 
internal variables, which are then used by the location chooser to 
initialize its UI.
- The UI of location chooser uses package private protocol to access 
wizard data. This data cannot be reached by OpenAPI calls (e.g. from 
new action impl)
- The action code uses public calls which overrides the private data 
for outside callers, but not for the bundled UI.

Comment 12 David Strupl 2001-09-10 12:50:14 UTC
Trying to rollback last vita's changes in TemplateWizard.
Comment 13 David Strupl 2001-09-10 13:34:34 UTC
Testing patch consisting of undoing changes in TemplateWizard (1.34 -
1.36) and NewTemplateAction (1.45 - 1.46). I will rollback these and
check whether it is ok.
Comment 14 David Strupl 2001-09-10 13:57:53 UTC
Fixed in trunk. Waiting for feedback before putting into the xxx_qbe1
build.
Comment 15 Jan Zajicek 2001-09-10 14:21:58 UTC
*** Issue 11910 has been marked as a duplicate of this issue. ***
Comment 16 David Strupl 2001-09-10 14:38:13 UTC
Commited also to branch BLD20010907_qbe. Marking as fixed.
Comment 17 Jan Zajicek 2001-09-11 14:51:44 UTC
dev #20010910
Comment 18 dmladek 2001-10-05 13:39:07 UTC
[NBdev-200110050100]
jdk1.3.1, rh71
====================

this bug has been fixed but probaly not for all of the availbale
templates.

The one for which I'm reopening this bug is: "IDE plugin Module"
I dind't discovered any other Wizard's templates which has this problem,
so I'm putting the priority to P3 (instead of P2 which is was previously).


Reproduction:
=============

1. Mount some FS.
2. Create a package here
3. on this package invoke popupmenu and select:
  New->API Support->IDE plugin Module
4. on the First Panel of the Wizard, name your Module. press NEXT
5. on the Second Panel you must again select target FS and
directory...:-(((( ....which is IMHO annoying

Comment 19 Jan Zajicek 2001-10-08 10:35:14 UTC
AFAIK, Ales or Jesse, works on the ide plugin module template. Seems
to me like issue from this template, not as general issue as this was
reported before. Passing to Ales.
Comment 20 akemr 2001-10-08 10:56:45 UTC
This is as designed behaviour.
Target FS and directory on Second panel is for module package to be 
generated.

In current packege in repository will be created target _jar_ file.
Comment 21 Quality Engineering 2003-07-01 15:49:07 UTC
Resolved for 3.4.x or earlier, no new info since then -> verified
Comment 22 Quality Engineering 2003-07-01 16:10:01 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.