Bug 32367 - [71cat][65cat] CardLayout's card name property could use code not just simple string
[71cat][65cat] CardLayout's card name property could use code not just simple...
Status: NEW
Product: guibuilder
Classification: Unclassified
Component: Code
6.x
PC All
: P3 with 13 votes (vote)
: 6.x
Assigned To: issues@guibuilder
issues@guibuilder
sp_review_61
: NETFIX
: 34998 53249 118121 153064 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-03-26 16:18 UTC by lkishalmi
Modified: 2011-09-30 12:58 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
:


Attachments
First patch... should be improved (1.29 KB, patch)
2009-05-01 16:15 UTC, Michel Graciano
Details | Diff
Mercurial diff patch (1.23 KB, patch)
2011-09-19 22:45 UTC, Michel Graciano
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description lkishalmi 2003-03-26 16:18:59 UTC
It would be nice that the CardLayout's card name
property could be edited somewhat similar like
other properties so it could overtake a value from
method calls, variables, etc.
Comment 1 Tomas Pavek 2003-07-22 15:01:33 UTC
*** Issue 34998 has been marked as a duplicate of this issue. ***
Comment 2 Tomas Pavek 2003-07-22 15:02:16 UTC
Please see my comments in issue 34998.
Comment 3 Tomas Pavek 2003-07-23 09:18:25 UTC
*** Issue 34998 has been marked as a duplicate of this issue. ***
Comment 4 Tomas Pavek 2005-05-16 15:26:13 UTC
*** Issue 53249 has been marked as a duplicate of this issue. ***
Comment 5 Tomas Pavek 2007-10-09 13:02:27 UTC
*** Issue 118121 has been marked as a duplicate of this issue. ***
Comment 6 kate 2008-04-28 16:49:08 UTC
still not possible in 6.1
Comment 7 shaulgo 2008-08-27 16:51:37 UTC
Can't the card name be equal to the components variable name. Like what is done with the components name. From what I
see Netbeans dynamically changes the name of the component to it's variable name. The same should be applied to the card
name. 
Sure I think that it showed have all the features that where asked before. But this seems like something that should be
done anyway and will probably fix most of the problems people are having.
Comment 8 Jiri Vagner 2008-11-13 10:52:25 UTC
*** Issue 153064 has been marked as a duplicate of this issue. ***
Comment 9 Michel Graciano 2008-11-13 12:17:41 UTC
Yes, it is really necessary, and the suggestion from shaulgo is not necessary and if implemented should be possible to
disable as usual. IMO the card name should accept variables, fields and so on since normally we use enums or constants
to define this names, which today is not 'refactorable'.
Comment 10 Nikita Krjukov 2009-04-29 16:52:59 UTC
I've just faced the same problem. 
Current approach is inconvenient because a card name specified in the properties (property sheet) is impossible to use. 
For example, if I need switching cards, I need put to my code a new text with the same content as has specified in
properties. I vote for the issue!
Comment 11 zajjar 2009-05-01 09:03:53 UTC
This issue was submitted in 2003 year and nothing has been done with it since that time :(
First of all, I need this "enhancement" when I create some wizards based on CardLayount.
It's very necessary "enhancement".
Comment 12 Michel Graciano 2009-05-01 16:13:50 UTC
Please, vote in this issue if it is important for you. :-D
Comment 13 Michel Graciano 2009-05-01 16:15:16 UTC
Created attachment 81383 [details]
First patch... should be improved
Comment 14 Michel Graciano 2009-05-01 16:46:25 UTC
This patch solve the problem, but the generated form file will not be compatible with old versions. I will try to
implement an advise to user that form version should be implemented. Ideas about how to do this and about the patch
itself are welcome.

Regards
Comment 15 zajjar 2009-05-01 17:46:13 UTC
Hi hmichel,

I was a first person who voted for this issue few years ago (sic!).
Comment 16 Michel Graciano 2009-05-01 18:09:43 UTC
I really know that. :-D
What I wish is that another people vote too. How much people want it and vote, more easier will be see it in the future.

Regards
Comment 17 bokc 2010-04-01 16:12:46 UTC
I need this modification so I add my vote.
Comment 18 Michel Graciano 2011-09-19 22:45:17 UTC
Created attachment 110885 [details]
Mercurial diff patch
Comment 19 Michel Graciano 2011-09-19 22:46:55 UTC
Any chance to get this integrated soon? I have received some users e-mails asking for this too so we have more users waiting for this enhancement. I have tested the patch with our production code and I can't see any problem with generated code.
Comment 20 Jiri Kovalsky 2011-09-30 09:08:03 UTC
Tomasi, can you please take a look at this patch and integrate it if you don't find any problems? Thanks!
Comment 21 Jan Stola 2011-09-30 10:05:07 UTC
> Tomasi, can you please take a look at this patch

As Tomas is no longer member of NetBeans team (for more than 1 year) it is probably me who should evaluate this patch.

> and integrate it if you don't find any problems? Thanks!

This patch is incorrect. It enables the mentioned support in UI only, but it doesn't deal with important parts of this functionality - with persistence and compatibility. BTW, the uncommented code mentions these parts. So, I am surprised that the author of the patch ignored that completely.

For example, if I apply the suggested patch then I am able to save a form that is using User Code for the mentioned property, but the property is not loaded when the form is opened (check its value in Properties window).

Also the form version should be increased when non-default property editor (like User Code) is used - to make sure that user of such form is notified correctly when (s)he attempts to open it in some old version of NetBeans (that doesn't support this functionality).
Comment 22 Michel Graciano 2011-09-30 11:59:52 UTC
Thanks Jan for the comments. I actually saw the comment but I can't find any problem during tests. I try more to fix the issues. BTW, how can I increase the form version?

Thanks again for your comments.
Comment 23 Tomas Pavek 2011-09-30 12:22:39 UTC
> I can't find any problem during tests.

Is the card name property really saved into the .form file as user code, and then also correctly loaded when you open the form again?
Comment 24 Michel Graciano 2011-09-30 12:26:45 UTC
> Is the card name property really saved into the .form file as user code, and
> then also correctly loaded when you open the form again?
I really don't remember Tomas. I gonna reapply the patch to my local copy and retest it today yet.
Comment 25 Jan Stola 2011-09-30 12:39:07 UTC
(In reply to comment #23)
> > I can't find any problem during tests.
> 
> Is the card name property really saved into the .form file as user code, and
> then also correctly loaded when you open the form again?

I wrote that already in my previous comment - the property value is not loaded (it is saved in .form file, but ignored silently during loading).
Comment 26 Michel Graciano 2011-09-30 12:47:37 UTC
Jan and Tomas,
I can confirm that the patch doesn't work, my tests were flaw. Shame on me :(
I really had no payed enough attention for generated .form. I had not ignored
the comments, but I had assumed that the 'persistence' mentioned is related to
the generated .java and I kind of had ignored the .form.

I would like to ask you for help to guide me how can I increase the form
version, maybe a sample or a place where it is already used.

Thanks again for your help and I apologize for any kind of trouble.
Comment 27 Jan Stola 2011-09-30 12:48:31 UTC
(In reply to comment #22)
> Thanks Jan for the comments. I actually saw the comment but I can't find any
> problem during tests. I try more to fix the issues.

Feel free to investigate it more, but it may turn out that the whole infrastructure around support of layout managers is not prepared yet to handle these non-default property editors.

The lack of this functionality is not caused by some simple oversight. It is a well known limitation that was not overcome yet because noone was brave and motivated enough to handle all the related problems.

I don't want to discourage you, of course, but I am trying to warn you that this issue may be more complicated than it seems at the first sight.

> BTW, how can I increase the form version?

See FormModel.raiseVersionLevel() and its usages.
Comment 28 Michel Graciano 2011-09-30 12:58:21 UTC
Thanks again Jan. I will endeavor this more and ask for help always it is necessary :) I hope it gonna be fun.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo