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.
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'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.
Given the list of new features announced in Silverlight 4, when is WPF still required?
WPF still has a lot fuller 3D rendering capabilities.
Also even though they announced enhancements to the commanding and binding capabilities, that's no guarantee that it will have the full ability that WPF currently has or will have in the next version
Edit: After playing around with Silverlight 4 beta, it looks like pretty much all of the new features (webcam, file access, full screen keyboard, COM interop, etc) only work when the application is elevated trust, and elevated trust can only be enable when running out of browser. Some of this may change by RTW, but for now, WPF still looks like the only way to do these things inside of a browser window
I've been using mostly XBAPs for browser deployments while waiting for a Silverlight version that includes WPF's full templating and data binding capabilities. Perhaps Silverlight 4 will do it.
Several things that Silverlight 4 definitely won't be able to do are:
Allow you to seamlessly integrate your WinForms and MFC user interface components with your application
Efficiently work with data file structures originally defined in C/C++ (with WPF you can simply copy the code across and easily replicate the original C++ code using unsafe and StructLayoutAttribute)
Include unmanaged C++ code in your application
I have not actually downloaded the Silverlight 4 beta yet, so this list is necessarily incomplete.
The next version of Visual Studio will not be written in Silverlight ;) I can't wait to write an Audio utility in WPF---and Silverlight must be sand-boxed away from the incredible Windows Audio subsystem. However, I can see the day when WPF will be called Silverlight (or perhaps the other way around).
When you don't want to depend on a browser to do your work, when you need full and fast access to the file system without prior confirmation, when doing interop with unsafe bits of code. These are the few I can think of, but they might be other reasons as well, depending on what features Silverlight 4 will really have and how well will they really work.
The applications we (in our company) write today use nothing that is not supported by Silverlight except for local TCP/IP connections without limitations.
This is the only reason we are using WPF.
If we could use Silverlight instead (desktop mode) we'd be able to give our customers
the choice of working on Mac (and linux) systems as well instead of being forced (by us?)
to use a recent version of Windows (you'd be surprised how many companies still use old (partially) unsupported versions).
Even in WPF we try to limit access to the system, we create our own sandbox and
try not to go outside of it. (Never require admin rights, never access stuff you don't have to)
So for what we do, Silverlight + real tcp/ip support would be more than enough...
but there is absolutely still room for WPF and I'm pretty sure it's here to stay.
It all depends on what you're building.
Silverlight will always favor small payloads over functionality. Strategically, Microsoft will attempt to out feature Adobe's offerings using Silverlight, while WPF will be competing against other heavy platforms. If you look at WPF 4 you'll notice a push towards heavier weight features. I try to keep in mind that WPF started out as Avalon which was intended to permanently displace Win32. I won't be surprised if one day Windows XX is "native" WPF and Win32 will be emulated.
If you want to do direct database access through ADO.NET that's not something you'll be able to do in Silverlight 4. Access to devices will still be limited although you will now have some printing support and webcam/microphone. I haven't heard anything about 64 bit support so if you want to offer a 64 bit version of your app you'll need WPF. I also think even if Silverlight 4 makes better use of the GPU, it still won't be to the level that WPF utilizes it.
There are also a ton of other assemblies in the .NET framework that Silverlight doesn't include so if you need any of those you'll need to go WPF.
Just like HTML5 will reduce the need for a plugin like Flash or Silverlight in some cases, Silverlight will reduce the need for WPF but there are still plenty of cases where you'll need it.
WPF is still required if you need to do extensive Rich Text (FlowDocument) editing. Silverlight 4 has the new RichTextBox, but it is limited to very basic content, and doesn't provide the full set of features that are available in FlowDocuments in WPF. A FlowDocument can effectively do what the WinForms RichTextBox can do; but if you only need the basics, a RichTextBox in Silveright may do what you need.
The bottom line is that silver light is limiting. So, if you are going to use a less capable technology you should have a compelling reason for doing so. The only one I can come up with, and it is a big one in some circumstances, is that Silverlight is more platform indifferent. I just can't imagine anyone wanting to bring the browser and all of it's headaches into a solution. There must be a good reason.
I need to display a file that comes from a mac on a Windows machine.
The font name in the mac file is "Helvetica".
Windows does not have Helvetica but it has "Arial" which is the close. However, if I pass "Helvetica" to a WPF control the font family is ignored.
How can I get programmatically the closest font from "Helvetica" on Windows?
They are actually different fonts, though the difference is subtle. Talk to any obsessed graphic designer and he or she will probably start ranting about Arial's inferiority. Hell, they even made a movie out of it.
http://www.helveticafilm.com/
So that's why there's no "mapping". Because they're just plain different. You'll have to come up with your own way of choosing which font you want to use (that is, you'll have to detect what you have and then use what you get from the OS).
Some fonts contain an embedded PANOSE number, which classifies fonts visually and can be used to match similar fonts. It's what Windows' Fonts folder uses to list fonts by similarity. However, I'm not sure how widely supported it is.
Presumably, you'd need to know a particular Helvetica font's PANOSE number in order to find the near matches from the fonts you have installed.
See PANOSE on Wikipedia and MSDN Library page on Using PANOSE Numbers.
it may be possible to convert Helvetica into a windows something like transtype
you could then embed the font into your wpf app.
You may be on very sketchy ground in terms of licensing though!
There's a very good font stack generator over at codestyle.org, I've blogged about how to use it here http://devsigner.co.uk/creating-a-good-css-font-stack/
hope this helps!
There's some information about some Helvetica look-alikes here, maybe you could install these on your Windows machine. If you're worried about compatibility with other machines, you can't use this though, as it won't display the font on their machines (I believe it will default to some specific font, perhaps Arial or Times).
WPF is promising us a lot of niceties, but some of them don't live up to our expectations.
One example is the borderless window. So just this simple code added to the Xaml of the window:
AllowsTransparency="True"
Background="Transparent"
WindowStyle="None"
will make my it look nice like this: (ignore the ugly colors they got messed up during the screen clipping)
alt text http://img29.imageshack.us/img29/5759/withoutborder.png
Too good to be true?
Yes it is!
It looks nice, but once the user tries to select something from the ComboBox, he can't, because it opens behind !! - yes behind the window. Of course then he cannot see anything which is not very practical.
This is due to a known Windows XP bug, more here.
I was fortunate enough to be developig on an XP machine otherwise I wouldn't have found out about this until the negative feedback from my users would have hit me ... which makes me wonder, why this bug isn't mentioned anywhere, where this "great" transparent window feature is explained (e.g. books, MSDN etc.)
Even if the fix that is mentioned (link above) could work, I will not require my users to download a hotfix, just to make my windows look nice.
That's why I'm looking for a better solution, maybe someone figured something out?
Until then my windows will have to look like this:
alt text http://img29.imageshack.us/img29/1570/withborder.png
Not very enjoyable as you can see, so you can imagine my appreciation for any solutions out there.
UPDATE:
In the meantime I confirmed, that this is only an issue when using multiple monitors (in my case Extended Desktop).
After installing the fix, the problem is gone entirely (even with extended desktop).
Downloading the fix though was a pain. Why does Microsoft make you give them your email to then send you a link to a password protected file, which then needs to be extracted manually to be able to finally install the bug fix?
Are they serious?
Shouldn't they make it simple for the users to fix Microsoft bugs?
How can I tell my users (who may not be so computer inclined as we developers are) to go to some site, enter email (oh and captcha too - I guess Microsoft is afraid computers are stealing their bug fixes LOL) and then go through above described process?
Anyways, I'll stop here before the question is turned into an entirely different one which makes me emphasize that now even more I look for alternative solutions to the problem.
Yes, it is annoying when a feature like this doesn't work in an older OS and you need to support it. Here is how I would solve it:
Check the Microsoft license agreement for the hotfix download to make sure the following would be legal
Add the extracted .exe to your application (either as a separate file or inside your executable, extracted with GetManifestResourceStream, ReadAllBytes, and WriteAllBytes)
When your application starts up for the first time, check to see if you are on XP with Extended Desktop and if so, if the hotfix has been installed or you are on a newer service pack. If so, cache that fact in the registry so you can skip the check in the future.
If you are on XP with Extended Desktop and don't have the hotfix or the latest service pack, change the window background to be opaque and enable a menu option to install the hotfix.
If you are running for the first time as administrator, pop up a MessageBox saying there is a hotfix that allows window transparency and asking if you should install it. If the user says yes, run the hotfix install. If they say no, tell them the menu option is available if they change their mind in the future.
Or alternatively, if they are running on XP you could always run opaque and popup a message that your application "runs even better on Vista or Windows 7".