Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 24187 - setMnemonics('x') should be considered as hard coded
setMnemonics('x') should be considered as hard coded
Status: NEW
Product: java
Classification: Unclassified
Component: I18N
All All
: P4 with 1 vote (vote)
: 6.x
Assigned To: Ralph Ruijs
: I18N
: 26253 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2002-05-29 12:53 UTC by _ pkuzel
Modified: 2011-11-28 09:21 UTC (History)
2 users (show)

See Also:

The changed sources of i18n module (13.22 KB, application/octet-stream)
2002-09-04 12:27 UTC, _ mihmax
Demo form, storing text, mnemonic & displayedmnemonicindex (2.27 KB, application/octet-stream)
2002-09-04 12:39 UTC, _ mihmax

Note You need to log in before you can comment on or make changes to this bug.
Description _ pkuzel 2002-05-29 12:53:28 UTC
i18n module should also check for some hardcoded
chars as in above example. It requires precise
java source model rather than current REs.

Also note that replacement code is different for
this case i.e.:
  char Util.getChar("xx_mne")

instead of:

  String Util.getString("xx").
Comment 1 Marek Grummich 2002-07-19 17:07:31 UTC
Target milestone was changed from not determined to TBD
Comment 2 _ mihmax 2002-09-02 12:56:15 UTC
I'd like to add that setDisplayedMnemonicIndex(int) should 
also be considered as a candidate for I18N.

I hacked FormI18NString & created FormI18NInteger and 
FormI18NCharacter with respective editors, (I'll attach 
them tomorrow).

And now I'm able to manually change the editor of Mnemonic 
to "Resource bundle - Character", creating a key in RB, 
and making it I18nable, but still looking around the 
automatic lookup&replace - the algorithm in I18NFinder is 
rather big.

I'll try to patch the finder in a week in order that it 
will be able to find not only hard-coded strings, but also 
hard-coded chars and integers.
Comment 3 _ pkuzel 2002-09-02 13:35:38 UTC
Max, the algorithm in I18nFinder is parametrized by regular expression
("RE"). It should be enough to provide:
 - hardcoded mnemonic RE
 - internationalized mnemonic RE
 - replacement code format.

I'm not sure if anyone can design universal replacement code format
for both mnemonics and texts. Actual format need to be parametrized by
hardcoded string type and generate diferent code for mnemonics and
Comment 4 _ mihmax 2002-09-04 12:21:02 UTC
See also RFE 27009:

If it will be solved, no need in this ENCHANCEMENT ;)))
Comment 5 _ mihmax 2002-09-04 12:27:08 UTC
Created attachment 7299 [details]
The changed sources of i18n module
Comment 6 _ mihmax 2002-09-04 12:39:20 UTC
Created attachment 7300 [details]
Demo form, storing text, mnemonic & displayedmnemonicindex
Comment 7 _ mihmax 2002-09-04 12:44:15 UTC
The two attachments are: - the changed sources of i18n module (changed from release34 tag) - the demo form, using the patched module, which stores all
properties (Text, Mnemonic & DisplayedMnemonicIndex) of a button in a

However, the change of storing the Mnemonic & DisplayedMnemonicIndex
properties in a bundle was hand-made ;( via changing the editors for them.

Please, take a look.

Comment 8 _ pkuzel 2002-09-04 14:07:30 UTC
This enhancement is still needed because Form editor is not the only
tool for designing forms. In theory.

Leaving as low priority enhancement.
Comment 9 _ pkuzel 2002-09-04 14:56:50 UTC
Patch accepted and integrated.

Thanks you Max.
Comment 10 _ mihmax 2002-09-04 20:00:30 UTC
Petr, I'm certainly proud that you integrated the patch, but that was
a buggy patch, I think ;(

For instance - Please take a look at &
FormI18nIntegerEditor, they both contain non-i18nized strings, marked
with // NOI18N:
" - Mnemonic" and " - Integer" both in getDisplayName() method.

And they are just cut & paste from FormI18nStringEditor & FormI18nString.

Also, please update the @author tag to include me. If there will be
bugs, Peter Zavadsky & Petr Jiricka are not responsible much ;)
Comment 11 _ pkuzel 2002-09-05 11:31:04 UTC
I fixed these before integration.

I'm responsible for bugs.
Comment 12 _ mihmax 2002-09-05 12:08:42 UTC
I18N should utilize them, and it can be achived only by modifying the
algorithm for searching, which seems to be a lot of rework, I18nFinder
seems to be hard-coded for Strings ;):
nextString, HcString, etc.
Comment 13 _ pkuzel 2002-09-05 12:51:12 UTC
I have not closed the issue for the same reason, see above.
Comment 14 Tomas Pavek 2003-03-11 15:08:06 UTC
*** Issue 26253 has been marked as a duplicate of this issue. ***

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