I'm working on a multi-lingual WPF project that will be localized into many different languages. One issue we are currently having is localizing the tool tips on the minimise, maximise and close buttons. The tool tips seem to get localized when changing the OS language in Vista and Windows 7, however on XP SP3 the tool tips still appear in English even though the current OS language is set to Arabic (ar-SA) for example.
Are these tool tips controlled by the operating system or do they come from somewhere else like the .NET language pack?
UPDATE:
I forgot to add, applications such as Microsoft Word and Notepad appear with localized tool tips on the same XP machine that failed to display our application's tool tips in the desired language.
The language has been changed via the Keyboards and Languages panel in intl.cpl.
UPDATE AGAIN:
Installing the English version of the application on Arabic Vista also results in Arabic tool tips suggesting that the localization of these tool tips is done outside of the application. I have seen no trace of a .NET language pack on the Vista machine leading me to believe that with Vista, the tool tips are controlled by the OS. The question now is why aren't these tool tips being localized for the Arabic application being installed on Arabic XP SP3?
FURTHER UPDATE:
Today I went on the XP machine and created a new WPF application out of curiosity to see what it's tool tips came out like and discovered that they were localized to Arabic; meaning that the problem with the tool tips is within the application itself. The question now is, what possible ways are there of preventing these tool tips being localized? It was suggested today that it could be the setting of the windows xml lang, however I did not get the time to test this out and can hopefully try this tomorrow.
The tooltip texts come from the operating system and the language will depend on the language version of the operating system. If you for instance open the Windows Explorer, the menus of that application should appear in the same language as the tooltips for Minimize/Maximize buttons.
Note that changing regional settings in the Control Panel does not affect this.
The problem is our use of some 3rd party controls. These controls do some localization that works in Vista and Win 7 but falls back to some strings in an XML file on XP for some reason.
Related
When I create new Windows Phone project I have an option to create a "Windows Phone" or "Windows Phone Silverlight" app. I know that they have different runtimes and different APIs.
I was under the impression that Microsoft wants to unify Windows and Windows Phone platforms so why is there even a Silverlight version? What benefits does it bring?
Also, if I want to create an app just for Windows Phone and never have plans to bring it to Windows, what should I choose, Silverlight or Windows Phone?
I'd suggest you go with "Windows Phone" (non-Silverlight). It's the new API, which works for both Windows and Windows Phone. At some point you may want to port the app or create a new one for Windows and you'll already know the API (and porting will be way easier). Also, the new API will most likely get more updates and features added, and at some point you may even be forced to update to it (either because the old one is no longer supported, or because it does not have some features that you need).
As it was said in the other answers - the Silverlight option is there only for backward compatibility and is likely to be phased out in time. That is - it's good if you already know the API and have many libraries (yours or others) for WP Silverlight, but if you're just starting - you'd better go for the new technology.
Edit
There is one other thing to consider before choosing between the two types of apps. Some features are only available in a Silverlight app, and others (smaller amount) - only in a Xaml app. Here's an article with some info on the differences: Migrating your Windows Phone 8 app to a Windows Runtime XAML app
Windows RT Xaml is quite new and People have to generate some knowledge first.
Silverlight for phone has been around for years and there's a load of tools available: Phone Toolkit, diverse Controls, etc.
Just killing it off would have hurt many developers who built up intellectual property over a long time forcing them to start over.
When starting a project with Silverlight you will have more things around that help you get stuff done.
When starting with WinRT Xaml, you will have better performance, but will have to figure a lot out by yourself.
So the Silverlight option is there to not throw of Silverlight developers.
I recently started a new project on WinRT Xaml and my experience was that I had to recreate a lot of common tools like Caches, etc. But also a lot of things that were in Toolkits previously are now part of the platform itself. Also, when moving over to Windows 8, you get to share a lot of code which is nice.
Unifying the environment(s) would be ideal. In my opinion, it hasn't been very successful. At one point in time, you could only develop under Silverlight, so what you are seeing is just a newer version of the same thing to keep backwards compatibility as well as to keep Silverlight's developers happy. In the future, it will probably be phased out. Plus if you want to support older Phones, Silverlight is basically your only choice (you'll be surprise, how many WP users haven't updated their 8.0 to 8.1)
There really isn't any other real benefit of Silverlight other than maybe the Windows Phone Toolkit which has been tremendously useful (you can see how many SO's answers rely on this simple addon). Once the universal runtime gets fleshed out to the point where the documentation reflects what's actually available -- then I think it would be the default project for developing in Windows going forward.
If you're just starting, I would use Silverlight the knowledge based is much greater. After you get use to the WP environment then switch to runtime.
I am planning to write a twitter app for Windows phone 7 with supporting Arabic, RTL with complex scripting, and with Arabic keyboard layout like the one in this app as this langauge is not supported by WP7.
I tried looking for a resources to help with this porcess but couldnt find any.
So does anyone have an idea on how the complex scripting can be rendered in WP7 through apps?
regards,
I saw a demo on a Windows Phone lately. Arabic text is shown normally in internet explorer and even SMS! But user can not write Arabic in the current moment as the Windows Phone 7 now is not supporting it. But People in Redmond promised it will be available in next language package updates! May be you should let Arabic supporting feature for the next version of your application.
About the app you pointed as example, I believe they have made their own custom keyboard! So you might contact the company developed the application and ask them for keyboard if it is available as 3rd party component.
I want to write an application for my Windows 6.1 standard smart phone that intercepts incoming SMS messages and auto responds if they match a specific criteria, but despite installing countless SDk's I am unable to do what I need.
The code I want to use relies on the Microsoft.WindowsMobile.PocketOutlook.dll assembly, but I can't seem to find that assembly. Is it possible to use this assembly on a standard mobile device, or do I have to have a Windows Mobile professional device?
So basically I need help getting set up to create Windows Mobile applications.
I am using SharpDevelop (because I
can't afford Visual Studio).
I need the
Microsoft.WindowsMobile.PocketOutlook
assembly (Since I have already written code that should work, that uses it).
A device emulator would also be nice
so I don't have to test on my phone.
Is what I want to do possible on a Windows 6.1 Standard device (HTC OZone)?
Any help would be appreciated, since I am completely stuck at this point.
Thanks,
I tried to compile my code and I get the following errors, as I suspected I would.
The type or namespace name
'WindowsMobile' does not exist in the
namespace 'Microsoft' (are you
missing an assembly reference?)
I can't find the Microsoft.WindowsMobile.PocketOutlook assembly so of course I'm missing an assembly reference.
Where can I get this assembly, and will this code run on my Windows 6.1 Standard phone if I can find it?
In my opinion it's very difficult for someone new to Windows Mobile development to work without Visual Studio.
In theory you can use SharpDevelop or MonoDevelop, but you wouldn't be able to do any debugging on the emulator or a connected device. Being able to debug by stepping through the code while it's running seems to me an unmissable thing if you're new to Windows Mobile and are not quite sure why something you coded is not working. It requires more effort and time to debug something and in the end you might find it more cost effective to buy a Visual Studio license.
The minimum required is Visual Studio 2005 Standard. You could try to see if you can find somewhere that sells it cheaply (as most developers now use VS2008/2010). If you're a student you could get an academic license or take advantage of Microsoft's DreamSpark program. Or if you're a startup you could look at Microsoft's BizSpark program.
Try starting with sample code that has most of you requirements implemented. The SDK comes with the sample: SMSIM
link text
It demonstrates how to use C# to write a managed code version of a Short Messaging Service (SMS) interception application.
I hope this helps.
Mike
I'm starting a hobby project in which I would like to have a graphical, touchscreen interface for interacting with a kiosk-like device running on top of Windows XP Embedded. For development of a rich UI experience, I was considering using WPF. However, a number of demonstration videos that I have come across have used Silverlight, while I haven't seen a single WPF demonstration.
It was my understanding that Silverlight was targeted towards website developers, while WPF was more targeted towards desktop development.
So this question has two parts. Firstly, what is the recommended graphical subsystem for development of a rich UI experience on a kiosk-like device hosted on the Windows XP embedded platform? Secondly, if it is Silverlight, which version is suggested (1.0 or 2.0) and why?
It seems that WPF works fine on embedded. See here the second comment.
I think that your choice should be dependent on the type of kyosk you want to build. Some kyosks are just an open browser page. And then you have stuff like Microsoft Surface that can be used like an horizontal kyosk :-)
I would recommend also WPF, have done few kiosk apps using it.
also I would recommend http://fpscomponents.com/Product.aspx?id=8 as a virtual touch screen keyboard software component. it's done in WPF and very flexible and customizable.
User can define custom theme(skin), layout and language of keyboard. guys are working with customers and hear theirs voice so any suggestions might be accepted.
I'm building a .net application with windows forms. I'm pondering on the following problem: If I specify fonts in my application that are available only in Vista and Office 07, what will happen when the application tries to run in a machine without these ?
I suppose the system won't be able to fall back to a font of it's family, since they are initialized internally using strings (eg "Segoe UI").
What's the best practice to follow, such that I will still be able to specify fonts through the forms designer and not worry about things like this breaking ?
I think it's System.Drawing.SystemFonts.MessageBoxFont that gives Segoe UI, Tahoma, then MS Sans Serif depending on the OS. As long as your layout is fluid enough---WPF is good at this, but in Windows Forms it's much harder---then it'll work great. Regardless, it'd be worth using that setting then testing in VMs to see if it works.
Also rather unfortuantely the designer doesn't have support for setting the font like that, and it will reset things to hard-coded Segoe UI sometimes (if you're using Vista).
This kind of thing was actually one of the reasons I'm starting to move to WPF :).
Either check the OS and use Tahoma on XP and Segoe UI on Vista or let the user choose in an options dialog. Installing Segoe UI on XP seems to be considered not-done by most.
I agree with Brian Cline, if you can include them that would be best.
A great way to see what will happen with a clean OS is to start up a virtual machine on your system and install the program on it. Microsoft has a free virtual machine program called 'Microsoft Virtual PC'. Using this, you can load up any operating system within a virtual machine and test how your application will react in a 'clean' install environment. It will act the same as a regular computer and will only have the programs you install on it specifically. I use this for my winforms applications and it works great!
Let me know if this helps!
JFV
Either take Jasper's advice, or follow mine: Don't do it. Unless you're reskinning the whole app for some reason, just use the fonts already defined on the system. If you look like every other battleship gray (or mildly themed) app, except the fonts, it looks a little odd to users.
Either way, including the fonts is a EULA violation. Users can download the Office 2007 Compatibility Pack and get most of them, but the one notable exception will be (I believe) Segoe UI: This font is a Vista-only font.
If you do want to be different, then take Jasper's advice and detect XP vs Vista. If you're on XP, either use Tahoma or Trebuchet MS. If you're on Vista, go ahead and use the cool new fonts.
Check the EULA first in both Office and Vista to make sure the fonts aren't sacred, but you may be able to include those fonts in your installer package and have it install them.
Barring the ability to redistribute the fonts in your installer, you may have to check for the existence of said fonts first. If they are not there, have your app pick an alternative font from a static list of fallback choices.