Skip to Main Content

Java SE (Java Platform, Standard Edition)

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Localized Accelorator Keys

843806Feb 7 2008 — edited Feb 20 2008
Hi folks,
I have a problem with localization and accelerator keys. I am developing a localized Swing GUI where a user can set his preffered Locale and then all texts are translated.... That's all no prob. The problem is, that in JMenus the accelerator keys for items are displayed not according to the set default locale (e.g., en-US) but are displayed according to the OS user.language (in my case de [German]). Hence, the accel. keys read, e.g., '*Strg-N*' instead of '*Ctrl-N*' as expected for default locale en.

This is just a display problem, the functionality / the keys work fine, of course.

I guess my prob is (somehow) related to the awt.properties. When invoking, e.g.,
KeyEvent.getKeyModifiersText(keyStroke.getModifiers() 
(which I assume is called for JMenuItems to display the acc keys) I get the modifier key as string in German. These properties are loaded on startup? according to the OS user language. If i change my user language (e.g., with the jvm switch
-Duser.language=en
) everything is fine. When changing this system property inside Java Code (e.g. in my main-method) the awt.properties are already loaded (somehow) with the OS user.language. Hence, this option doesn't work.

Has anybody an idea / workaround how I get these modifier keys displayed localized. Is there perhaps a way to change the awt-property on runtime or, at least, to set the values of these properties, e.g. AWT.control?

Thanks!

Comments

Frank Kulash
Answer

Hi,

I don't see any advantages to using "17 MOD 6".

It's certainly better to use documented techniques.  The 2 ways seem to be equally efficient.  Neither is inherently clearer, or simpler to code, or easier to maintain than the other.  In SQL, you have no choice: only "MOD (17, 6)" works in SQL.  I suggest using it in PL/SQL, too.

Marked as Answer by Aketi Jyuuzou · Sep 27 2020
Ramin Hashimzadeh

As Frank said Certainly better to use documented function better than use undocumented.

And if only in the 12s, improved switching sql <-> pl / sql. So I think it's better in the pl/sql to use the documented function of sql (MOD (a,b))

----

Ramin Hashimzade

Paul Horth

Not completely undocumented - it is buried away in an example here: 4 Using PL/SQL

BluShadow

PaulHorth wrote:

Not completely undocumented - it is buried away in an example here: 4 Using PL/SQL

Hmmm, that's a dubious example. 

It's got one mention in a bit of example code, but that example itself says "Note the use of the SQL numeric function MOD to check for no (zero) remainder. See "Using Numeric Functions" for information about SQL numeric functions." and if you go to look at the "Using Numeric Functions" section the example given there uses the "MOD(employee_id, 2)" style.

The actual syntax diagram for MOD clearly shows it in the latter style...

MOD

So that is the one I would say is the documented syntax.

I know the other style is used in other languages, and it could be that perhaps the person creating that example you found had created the example without thinking, and was just lucky that PL/SQL understood it that way.

Ramin Hashimzadeh

PaulHorth wrote:

Not completely undocumented - it is buried away in an example here: 4 Using PL/SQL

Maybe. But i think better will be use MOD (a,b) with SQL , "a mod b" with pl/sql to exclude switching sql <-> pl / sql. It is only my opinion ))). I think Mr. Kyte could better answer to this question.

----

Ramin Hashimzade

Frank Kulash

Hi,

RaminHashimzadeh wrote:

... But i think better will be use MOD (a,b) with SQL , "a mod b" with pl/sql to exclude switching sql <-> pl / sql. It is only my opinion )))...

----

Ramin Hashimzade

Try some experiments to check your opinion.  You'll see there is no difference in performance.

Almost all of the SQL single-row functions, including MOD, are implemented in the PL/SQL package dbms_standard.  There is no context switching when you use a function like MOD in PL/SQL.

Ramin Hashimzadeh

Hi Frank,

if it is really implemented then off course , there will be no difference. But really i don't know it is implemented or not.

----

Ramin Hashimzade

Paul Horth

BluShadow wrote:

PaulHorth wrote:

Not completely undocumented - it is buried away in an example here: 4 Using PL/SQL

Hmmm, that's a dubious example. 

It's got one mention in a bit of example code, but that example itself says "Note the use of the SQL numeric function MOD to check for no (zero) remainder. See "Using Numeric Functions" for information about SQL numeric functions." and if you go to look at the "Using Numeric Functions" section the example given there uses the "MOD(employee_id, 2)" style.

The actual syntax diagram for MOD clearly shows it in the latter style...

MOD

So that is the one I would say is the documented syntax.

I know the other style is used in other languages, and it could be that perhaps the person creating that example you found had created the example without thinking, and was just lucky that PL/SQL understood it that way.

I'm not disagreeing with you that it's dubious. Strange that it is accepted by PL/SQL but not officially documented though

BluShadow

The fact that PL handles it but SQL doesn't is good enough reason not to use it, especially as mod is a common mathematical operator/function.  Better to use what is common between the both.

Solomon Yakobson

I wonder when  n1 MOD n2 was introduced. Could it be XQUERY related, to support:

SCOTT@orcl > select xmlquery('9 mod 7' returning content) from dual;

XMLQUERY('9MOD7'RETURNINGCONTENT)
--------------------------------------------------------------------------------
2

SCOTT@orcl >

SY.

Paul Horth

BluShadow wrote:

The fact that PL handles it but SQL doesn't is good enough reason not to use it, especially as mod is a common mathematical operator/function.  Better to use what is common between the both.

Still not disagreeing with you

I was just intrigued as to why they added support for it and then didn't document it.

BluShadow

PaulHorth wrote:

BluShadow wrote:

The fact that PL handles it but SQL doesn't is good enough reason not to use it, especially as mod is a common mathematical operator/function.  Better to use what is common between the both.

Still not disagreeing with you

I was just intrigued as to why they added support for it and then didn't document it.

I suspect it stems more from the Ada language upon which PL is based.  In Ada, the syntax is "X mod Y" style, but in Oracle they obviously like functions to be more "fn(arg1,arg2..)" style.

Aketi Jyuuzou

Thanks for replies.

I will use Method1 which is documented.

Why I found this 2 methods is I made the same logic VB2005 and PL/SQL.

First step is making VB2005 logic.

Second step is making PL/SQL logic(Of course bese code is copied from VB2005 code).

1 - 13
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Mar 19 2008
Added on Feb 7 2008
9 comments
925 views