Making WPF CheckBox and RadioButton display correctly in Windows classic theme
When developing a wpf app for work I ran into a display problem for the CheckBox and RadioButton. Most of our office computers still use windows XP with the classic theme and even the new Windows 7 computers are set to use the classic theme as well.
Originally, I wrote my RadioButton and CheckBox like so
<RadioButton Style="{StaticResource myRadio}"
As you can see the "Content" part is what determined my label for the defined RadioButton, and here is where the problem is. I am not sure why but the Classic theme in windows can't render this properly causing the entire control to be inaccessible.
To fix this problem we need to remove "content" and link a label to the control. This is quite simple to do as you can see as follows:
<RadioButton Style="{StaticResource myRadio}" GroupName="someGroup" Name="radioButton1">
<Label>Option 1</Label>
</RadioButton>
I would like to know more why this is a problem on the classic theme but right now this workaround works great across all OS's and themes
Why I chose Silverlight over Flash for my FTP client
UPDATE: I have been having issues with silverlight sockets so this project hasn't been finished. If anyone had any luck with something like this please share your experience. Thanks
I made this File uploader that connects to an FTP server to upload customer files. My first instinct was to use flash and action script. The project went smoothly and development was rather easy, I was impressed by the simplicity of the Actionscript sockets. It turns out all that simplicity came at a price, just a few hours after deployment some users could not upload files, the app would hang and crash some browsers.
After a few minutes of researching I discovered that the files that caused this problem were large files. The size of the file that caused the problem was dependent on the system, older systems with small memory would crash with files that were 200MB while others could handle 1GB files.
as it turns out my problem was that Flash could not load a file partially. you pretty much have to load the entire file to memory to send it with a socket. then there is the problem that flash doesn't support any sort of bytesSent property of progress event handler.
While .net sockets don't support progress event handlers they do provide with the bytesSent property. also FileStream allows for the partial loading of a file. All this translates to two thing:
- I can read a file piece by peace, so now i can send 1GB files from any system.
- Since i can read a partial file I can now resume an interrupted upload.
Silverlight Sockets are harder to implement thought, since all receives and sends are asynchronous any method that updates the interface needs to be implemented as a delegate. You also need to keep track of the order in which messages arrive. A simple way is to block the application and make it wait for an eventComplete from the socket using and Autoevent.
So in conclusion I ended up using Silverlight for my FTP Client because of the flexibility that FileStream provided and even thought Sockets in Silverlight are more difficult to implement, now I have a more robust application for my customers.
P.S one bit of advise is that if you must receive and send messages at the same time in the same socket, use two socketEventArgs, one for sending and one for receiving