CollectionEditor issues in localized code - by Radim Literak

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


1
0
Sign in
to vote
ID 788504 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 5/23/2013 7:34:14 AM
Access Restriction Public

Description

If I am using localized code (forms, controls), I have found some issue, when items in collection are messed up.

It causes, that localizations are lost/changed etc. and SW engineer have to fix it manually after each update.

It was tested primary on ImageComboBoxEdit component from DevExpress company, but the same result was obtained also from MS ComboBox component.

It seems, that the reason of this issue causes changes in generated keys to the RESX resource file, but keys in the RESX file are not affected (contains previous pairs key/value - not updated).
Sign in to post a comment.
Posted by Microsoft on 6/28/2013 at 6:42 PM
Thank you for reporting this issue. Customer feedback is a critical part of a successful, impactful software product. Unfortunately another part is the reality of schedules and the need to prioritize investments according to the objectives of the product. We have evaluated the issue that you have reported and at this point in the product's lifecycle, it does not meet the criteria to be addressed. This evaluation is carefully done and considers many aspects including the cost of the fix, implications of the change, and the number of reported instances of the issue.
As a workaround you could try saving combo box values as string resources in resource editor and then adding them to the combo box in the code, after the form is initialized. In other words move this code from <form1>.designer.cs file into <form1>.cs file:
this.comboBox1.Items.AddRange(new object[] {
            resources.GetString("comboBox1.Items5"),
            resources.GetString("comboBox1.Items1"),
            resources.GetString("comboBox1.Items2"),
            resources.GetString("comboBox1.Items3"),
            resources.GetString("comboBox1.Items4")});

 
Thank you,
The Windows Forms Product Team
Posted by Radim Literak on 6/5/2013 at 2:28 AM
Maybe some another little notice...

I am talking about manual fixing. It is possible as the worst scenario, but it is also so complicated. Because of I can't speak every localized language... So, if elements are reordered by designer after some changes in the default locale, it's very difficult to fix all the localizations...

From all these reasons I think there is a bug and should be fixed. There should be some mechanism, which correctly updates all localizations after changes in the default locale.
Posted by Radim Literak on 6/5/2013 at 1:40 AM
Hello!

This is probably some misunderstanding, but I am at default locale. Look at attached sources, look at reproduction steps. Also DevExpress confirms my results.

I understand, that I can't do changes in non-default locale, but my issue is related to the default locale. I do changes in DEFAULT locale and later, when I switch to non-default locale (e.g. Czech), then non-default locale has wrong order of items/elements (look also at attached screenshots). It is completely reordered (each locale) and user must manually fix all the elements. It so complicated and inefficient etc. Each minor change in collection (especially changed order of elements) requires later manual fix of all locales. You have no chance to any workaround, because of elements' keys are generated by designer.

     Radim
Posted by Microsoft on 5/30/2013 at 5:44 PM
Hello, Radim,
Thank you for your feedback.
We see that DevExpress support representative had referred you to this article: http://msdn.microsoft.com/en-us/library/y99d1cd3(VS.71).aspx and suggested to revert to the default language when making changes in designer. This is a design limitation is the windows forms design time serialization, you would have to follow these steps. Could you please explain why this workaround is not acceptable?
 
Thanks,
The Windows Forms Team
Posted by Microsoft on 5/30/2013 at 1:08 AM
Thanks for your response.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Radim Literak on 5/24/2013 at 4:32 AM
I have attached (private) sources, inc. some screenshots. Hope it's helpful.

Also I would like to notice, that this issue was discussed first time with DevExpress support team:

http://www.devexpress.com/Support/Center/Question/Details/Q495877
Posted by Microsoft on 5/23/2013 at 10:56 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. In order to efficiently investigate and reproduce this issue, we are requesting additional information outlined below.

Could you please give us a demo project to demonstrate this issue so that we can conduct further research?

Please submit this information to us within 4 business days. We look forward to hearing from you with this information.

Microsoft Visual Studio Connect Support Team
Posted by Microsoft on 5/23/2013 at 7:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)