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".
Related
I got a commercial app, which works for a lot of customers.
One guy however has this problem:
After he installs OOB app to his computer and then hits its icon to launch it nothing happens.
I checked myself, icon is pointing at sllauncher just like everyones else.
SL was reinstalled yesterday, its the most recent version (5.xxx).
He says everything had been working fine, but he had fought a virus recently, and after that it stopped to work. Its not 100% that this virus and anti virus check are the reason, but thats the only system change he can name, which happened recently.
What could be the problem you think?
This sllauncher is pretty annoying to debug I guess as it doesnt give any clues, simply nothing happens.
App doesn't require elevated trust.
update: I did check event viewer and there is nothing interesting
Try to disable to anti-virus and run it - if it runs, Add an exception in the anti virus.
Also, go to the file properties and check that you don't need to unblock the file.
Two things worth trying:
First, right-click on your application icon and choose "Run as Administrator" to invoke it.
Second, if that doesn't work, consider uninstalling your application, and re-installing it.
This is achieved in Windows 7 by doing Start/Control Panel/Programs and Features. Then in the list find the name of your Silverlight application. Right-click on it, and choose "Uninstall".
Then re-install it in the same way your other customers do their installs.
First, let me start off by stating that I will be more than happy to post whatever code or other information I need to in order to help resolve this issue. Unfortunately, at this time, I am just not sure what I need to post.
I have a WPF application that uses the Microsoft Ribbon library. I know the ribbon control has been rolled into the 4.5 framework but since I am still deploying to some XP machines, I am forced to use the 4.0 framework. I mention this only in case there is some obscure issue with the old library.
In the application, I have a RelayCommand that is bound to one of the ribbon buttons that does not enable itself correctly (or at all for that matter). The code that is in place to determine if the command can execute is the exact same as the code for a few other buttons. These other buttons behave correctly. Even worse, the behavior is correct on my machine but not on any of the other machines that I have tried it on. It doesn't appear to be isolated to XP or Windows 7. Even worse, I have placed a regular button in the interface that calls the CanExecute method for the command and it reports a value of True even when the button is disabled.
I am at a complete loss of where to start looking. Perhaps someone can steer me in a direction of where to begin.
Thanks in advance to anyone who is able to assist me in my desperate state.
* EDIT *
On a whim, I installed .NET 4.5 on the machine that was not functioning correctly as this was a glaring difference between the development (my) machine and the other machines. To my surprise, this corrected the issue. That said, are there updates to the .NET 4.0 framework that are applied by installing version 4.5? As I mentioned above, I am targeting some XP machines so I cannot install 4.5. Perhaps there are some other updates that can be installed without installing 4.5?
I'm running my SL5 application (that has been working well so far) on Windows 8, and it is not going well. I have a background picture which usually does not render correctly, almost everytime I navigate my background (including the controls over it) just goes white till I resize IE, then it re-paints (what makes it stranger is that the parts that goes white is outside of the navigation frame, why is it getting repainted). (Chrome renders fine)
When I run my application out-of-browser my login screen pops up and works correctly but after the login screen closes it looks like the gray background of the login screen remains behind and I cannot click on anything, resizing makes no difference, it looks like every control has been disabled.
I have updated my NVidia Drivers to the latest, don't think its a display driver issue though.
Anyone else had these issues? Anyone else running SL5 fine on windows 8?
(Looks like I'll be downgrading back to windows 7 soon)
Silverlight should run great on any desktop browser in Windows 8, just like it does on Windows 7, Vista, and Mac. The underlying runtime is 100% the same. That does not mean you may not find a glitch with a graphics driver, but it means you shouldn't - and likely won't.
I did want to make a clarifying point, however, that Silverlight is not part of the Modern Internet Explorer (the Metro Internet Explorer). Only a subset of Flash is supported and that is only supported on white-listed sites.
This means Silverlight solutions that you might have expected to run on the Surface RT (running Windows RT - or Windows on Arm) will not run (as there is no SL runtime). And, I think we can all have a collective moan and ask, together, "Why not?" To which there is no acceptable answer.
The theoretical goal, of course, is to write native Windows 8 apps. If you want to write something web based you should write it in HTML5. That's the official word. I think we all know that HTML5 has a ways to go in order to catch Silverlight, but it is what it is. Can't change some things.
I have had no issues with any of my Silverlight 5 apps running on Windows 8 - I focus mainly on line of business apps but have some graphical and otherwise apps that run fine as well.
I'm only marking this as the answer to close the case, what the actual answer was to the problem we will never know. The solution: automatic updates. After much hassles with getting automatic updates to actually go through, my machine is now working well.
How does join.me allow attendees to control someone else's desktop without requiring a download on their part? Unless we're mistaken, it seems like only the organizer is required to download anything.
I don't specifically know how join.me does their desktop sharing, but there are JavaScript-only solutions for the client, like http://kanaka.github.com/noVNC/, so that all you'd need is for the organizer to have a VNC client installed. SmartCode has a version of a VNC ActiveX control that almost certainly violates the VNC GPL (here), but it might be something you'd want to look into for the organizer-side.
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.