The client is requesting a localization solution to using Tabs in the Infragistics Ultimate UI for WPF controls.
Previously they have released the layouts Tab using your controls from ASP.NET and Windows Forms.
Depending on local data would have a different Tab list layout in their application.
The local office is from Japan, they would need Japanese localization solution to WPF but based on their country's user in the Windows Application and ASP.NET Web Application experience.
Since the branding that is run on WPF need to match the same look and feel from both previous platforms, the developers need an inheritance solution for dynamic localization Tab layouts.
Do you have an inherited sample solution written in C# that would provide dynamic Tab layout lists that are different in Japan and outside of the country?
Hello Duane,
My team and I have done an initial review of this forum thread, and by an “inherited sample solution” in this case, I am under the impression that you are looking to be able to reuse the code that you used for the Windows Forms or ASP.NET layouts that you have previously released. If my impression in this case is incorrect, please let me know.
Continuing from the above impression, the WPF XamTabControl does not share its code with the Windows Forms UltraTabControl, but it is still possible to host Windows Forms controls within a WPF application if you wish to go that route. There is information on how to do that here: https://learn.microsoft.com/en-us/dotnet/desktop/wpf/advanced/walkthrough-hosting-a-windows-forms-control-in-wpf?view=netframeworkdesktop-4.8. This would potentially allow you to reuse the code you have written for the Windows Forms solution that you mentioned within a WPF application.
Regarding having a dynamic Tab layout list that is different in Japan and outside of the country, something you could do to achieve this would be to add the tabs dynamically based on the static CultureInfo.CurrentCulture as this will be pulled from the system information of the machine that the application is running on. For example, you could do something like the following:
CultureInfo info = CultureInfo.CurrentCulture; if (info.IetfLanguageTag.Contains("jp")) { //Japanese localization - add tabs for Japanese culture }
The part I’m unsure about with your original description is whether or not the tab list itself is going to change, or if you simply want the headers of the tabs to be localized when the application is run in other locales? If you are looking for the headers of the tabs to be localized, it should be possible to do this using Resource Strings using the methods described here: https://jeremybytes.blogspot.com/2013/07/changing-culture-in-wpf.html.
I hope this helps. Please let me know if you have any other questions or concerns on this matter.
You just don't clearly understand what is being requested here. Even though this is a WPF forum, what the client needs clearly is to be able to use all of the platforms for layout tabs. Yes, your Infragistics layout tabs.
It doesn't make any sense that you have check marks for WPF, Windows Forms, and ASP.NET in your Ultimate UI product for the same controls if the client gets blamed from WPF when previously the team has released their Windows Forms application using your Infragistics controls.
Just about every reply that you have posted is a solution about WPF only and Windows Forms only, not base class implementations to use both WPF and Windows Forms using your Infragistics controls.
By the way based on your responses you seem to expect that all platforms need to be tested. That's only because you have no base inheritance, your company is really really terrible when it comes to testing only one platform and ensuring that all platforms work using your Infragistics controls.
I think I do understand what is being requested from your most recent response – it sounds to me like you are looking for a cross-platform tab control inheritance structure that would allow you to write a tab layout once and use it across multiple platforms with our controls. If that is incorrect, feel free to let me know but please clarify your requirement in doing so.
Assuming my impression above is correct, unfortunately we do not have this. There is only a subset of controls in the different Infragistics toolsets that actually share any code and the tab controls are not one of them – they are completely different controls with completely different base classes and architectures. This is why I had recommended the WPF / Windows Forms interop above that would let you host a Windows Forms control in WPF or vice-versa.
If you are using the ASPNET Web Forms toolset, there are no controls in that entire toolset that share code with any other Infragistics toolset because that toolset was created and essentially entered “maintenance mode” before any of our controls became cross-platform. This is because Microsoft deprecated ASPNET Web Forms and there was no reason for us to continue active development on a soon-to-be dead platform at the time. It is still included in the installer for legacy application reasons.
I’m not sure how my previous response indicates that we expect all platforms to be tested, but if you are releasing an application on multiple platforms, I would hope that you do test it on each platform you intend to release on. As for our controls working on those platforms though, our controls have extensive automated testing for every platform that we support that is run many times before each and every release to ensure the best user-experience.
All of the clients don't have the time to be trained in creating projects in all platforms because it would simply be too much time of the user waiting to get every published application. Even just publishing one application is tedious for the business. They want to test only one platform but to make sure that the other two platforms in ASP.NET and Windows Forms will work even without testing others prior.
This goes the same thing as far as ASP.NET first or Windows Forms first vice versa. It's a common problem when users get experience seeing in one platform then they start getting requests in running multiple devices after.
Training is a huge problem for users, they usually just pick one platform and stick to it however when business does go up they really want multi devices which is what your product offers but can't be disqualified just because all platforms weren't tested to begin with.
So as far as Tabs is concerned every WPF user is running on their own windows machine and is being trained on it however depending on the revenue of the company's brand they want to run it on everything that Ultimate UI has to offer.
Is there any solution out there that uses Tabs either in WPF only, ASP.NET only, or Windows Forms only however depending on which one is run first there will definitely be no problems to what the users are seeing Tab Localization in all of them later even if users are only experiencing one platform?
There does not currently exist a solution that uses tabs in a WPF, Windows Forms or ASPNET application that will ensure that there are no problems with the other two platforms with Infragistics tab controls, as with the current implementation of Infragistics tab controls, this is essentially impossible due to the code-sharing parts I have mentioned above. To reiterate, none of the tab controls within WPF, Windows Forms or ASPNET share any base classes or code – they are completely different controls with different architectures. As such, they would need to be written differently in their corresponding platform’s application.
Regarding the tab localization part, you could likely reuse something like the CultureInfo code I had provided in my original response within each WPF, Windows Forms and ASPNET application and I would expect that this code should work, as this is just .NET Globalization code that should be common to the .NET Framework that you are targeting in each application. If you did this with resource strings (.resx), you would also likely be able to reuse the .resx file in multiple applications as well. Again though, the way these are reused with respect to the tab controls would need to be different on each platform due to the differences in architecture between the ASPNET, Windows Forms and WPF tab controls.