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

Please see my comments in issue 34998.

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

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

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

still not possible in 6.1

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.

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

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'.

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!

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".

Please, vote in this issue if it is important for you. :-D

Created attachment 81383 [details]
First patch... should be improved

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

Hi hmichel,

I was a first person who voted for this issue few years ago (sic!).

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

I need this modification so I add my vote.

Created attachment 110885 [details]
Mercurial diff patch

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.

Tomasi, can you please take a look at this patch and integrate it if you don't find any problems? Thanks!

> 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).

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.

> 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?

> 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.

(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).

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.

(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.

Thanks again Jan. I will endeavor this more and ask for help always it is necessary :) I hope it gonna be fun.