<Swing Dev> [10] RFR JDK-8183529: FilleChooser in "Detail view" does not change the Language of the column headings

Semyon Sadetsky semyon.sadetsky at oracle.com
Mon Jul 10 14:59:51 UTC 2017


Hi Prasanta,

Please, add static modifier to those java constants.

Also, in ShellFolder2.cpp, could you move the initialization lines from 
_doGetColumnInfo() to _initIDs()?

--Semyon

On 07/07/2017 10:49 PM, Prasanta Sadhukhan wrote:
>
>
>
> On 7/8/2017 2:22 AM, Semyon Sadetsky wrote:
>>
>> Why you declared fields instead of constants? Are they supposed to be 
>> changed?
>>
>> Also, most of them are already declared in the superclass:
>>
>>     private static final String COLUMN_NAME = 
>> "FileChooser.fileNameHeaderText";
>>     private static final String COLUMN_SIZE = 
>> "FileChooser.fileSizeHeaderText";
>>     private static final String COLUMN_DATE = 
>> "FileChooser.fileDateHeaderText";
>>
> Those had private access and I did not want to change superclass but 
> anyways, if you insist here's the modified webrev
> http://cr.openjdk.java.net/~psadhukhan/8183529/webrev.05/
>
> Regards
> Prasanta
>>
>> --Semyon
>>
>>
>> On 07/07/2017 09:26 AM, Prasanta Sadhukhan wrote:
>>>
>>> Modified webrev to not create new string objects every time 
>>> doGetColumnInfo() is called, rather it "gets" the  string objects.
>>>
>>> http://cr.openjdk.java.net/~psadhukhan/8183529/webrev.04/
>>>
>>> Regards
>>> Prasanta
>>> On 7/7/2017 8:51 PM, Semyon Sadetsky wrote:
>>>>
>>>> I may be wrong, but the cause may be that you did not keep 
>>>> references to those objects and they were garbage collected.
>>>>
>>>> --Semyon
>>>>
>>>>
>>>> On 07/07/2017 08:13 AM, Prasanta Sadhukhan wrote:
>>>>>
>>>>> I tried that putting the initialization in initIDs() which will be 
>>>>> called once only but am getting jni crash citing " Pointing to 
>>>>> zapped jni handle area". Only in doGetColumnInfo(), it's working.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 7/7/2017 8:38 PM, Semyon Sadetsky wrote:
>>>>>>
>>>>>> That's better. But still each time when getFolderColumns() is 
>>>>>> called the title keys are initialized.
>>>>>>
>>>>>> That will be more optimal to initialize them once only and reuse 
>>>>>> them in consequent calls, won't it?
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>> On 07/06/2017 11:26 PM, Prasanta Sadhukhan wrote:
>>>>>>>
>>>>>>> Modified webrev after removal of intermediate variable temp and 
>>>>>>> reusing strings
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8183529/webrev.03/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>> On 7/6/2017 9:52 PM, Semyon Sadetsky wrote:
>>>>>>>>
>>>>>>>> Why do you need intermediate variable temp to convert C string 
>>>>>>>> to java string?
>>>>>>>>
>>>>>>>> Also could the strings be created only once and reused?
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>> On 07/06/2017 09:12 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>
>>>>>>>>> Hi Semyon,
>>>>>>>>>
>>>>>>>>> I missed that. I see now, the page mentions that "The first 
>>>>>>>>> four fields are standard for all file system folders"
>>>>>>>>> Column index
>>>>>>>>>
>>>>>>>>> 	Column title
>>>>>>>>> 0 	Name
>>>>>>>>> 1 	Size
>>>>>>>>> 2 	Type
>>>>>>>>> 3 	Date Modified
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> so I modified webrev to rely on column index rather than string.
>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8183529/webrev.02/
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Prasanta
>>>>>>>>> On 7/6/2017 9:01 PM, Semyon Sadetsky wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>
>>>>>>>>>> See what MSDN says [1] about the column titles obtained by 
>>>>>>>>>> IShellFolder2::GetDetailsOf:
>>>>>>>>>>
>>>>>>>>>> ... Bear in mind that these titles can be localized and might 
>>>>>>>>>> not be the same for all locales.
>>>>>>>>>>
>>>>>>>>>> --Semyon
>>>>>>>>>>
>>>>>>>>>> [1] 
>>>>>>>>>> https://msdn.microsoft.com/en-us/library/windows/desktop/bb775053(v=vs.85).aspx
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 07/06/2017 01:13 AM, Prasanta Sadhukhan wrote:
>>>>>>>>>>> Thanks Semyon for spotting this. Since this bug is for 
>>>>>>>>>>> windows, I concentrated on windows only.
>>>>>>>>>>>
>>>>>>>>>>> But it seems, for non-windows platform, ShellFolder uses
>>>>>>>>>>> COLUMN_NAME = "FileChooser.fileNameHeaderText";
>>>>>>>>>>> COLUMN_SIZE = "FileChooser.fileSizeHeaderText";
>>>>>>>>>>> COLUMN_DATE = "FileChooser.fileDateHeaderText";
>>>>>>>>>>> string which is locale-sensitive.
>>>>>>>>>>>
>>>>>>>>>>> Only for windows, it uses Win32ShellFolder which calls 
>>>>>>>>>>> IShellDetails::GetDetailsOf() to get columns details.
>>>>>>>>>>> Modified webrev applicable for only windows to convert this 
>>>>>>>>>>> windows specific names to locale-sensitive names.
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8183529/webrev.01/
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Prasanta
>>>>>>>>>>> On 7/5/2017 8:40 PM, Semyon Sadetsky wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Prasanta,
>>>>>>>>>>>>
>>>>>>>>>>>> Haven't you tested how the details header localization 
>>>>>>>>>>>> works after your fix with other L&Fs and platforms?
>>>>>>>>>>>>
>>>>>>>>>>>> --Semyon
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 07/04/2017 11:42 PM, Prasanta Sadhukhan wrote:
>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please review a fix for a locale issue where it is seem 
>>>>>>>>>>>>> FileChooser dialog is not showing the column heading
>>>>>>>>>>>>> in selected locale in "Detail view mode".
>>>>>>>>>>>>> This was because, even though the locale strings are 
>>>>>>>>>>>>> present in properties resource file,
>>>>>>>>>>>>> /share/classes/com/sun/java/swing/plaf/windows/resources/windows.properties//
>>>>>>>>>>>>> //FileChooser.fileNameHeader.textAndMnemonic=Name//
>>>>>>>>>>>>> //FileChooser.fileSizeHeader.textAndMnemonic=Size//
>>>>>>>>>>>>> /the check done is wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Proposed fix is to check and get locale string resources 
>>>>>>>>>>>>> correctly.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8183529
>>>>>>>>>>>>> webrev: 
>>>>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8183529/webrev.00/
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards
>>>>>>>>>>>>> Prasanta
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20170710/120b2a9e/attachment.html>


More information about the swing-dev mailing list