|
|
I am sorry, but I honestly have no idea what you're talking about. If you wrote to them and they did not get back, one has to assume that you've been rejected. The alternative is to find out who is on this list, and ask them directly.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
The Disciples are a group of WPF enthusiasts who actively blog, write articles, give talks, and generally shout out about WPF and related technologies, as well as point out its deficiencies and where things need to be improved. This is a google groups list consisting of people like Josh Smith, Sacha Barber, Marlon Grech, Karl Shifflett (and me), and it's invitation only. The threads are available for anybody to view, but the discussions are limited to the members - basically those who've shown they have the inclination and experience in WPF.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
OK - they get to complain about WPF and Josh stays an MVP ? I got kicked out for complaining about stuff in public when no-one at MS would listen to me.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
It's all right - they won't even look at me for MVP status.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
*grin* I am glad to hear that WPF is an area where they are listening to criticism. I am far from the guru status that such a list would imply, but I use it daily and there's some big holes in it. And the bug I reported while it was in beta, whereby WPF cannot render images it has to resize without destroying them, is still in there. That after the bugs they ignored or insisted were features in VS2008, is when I realised that the MVP program had become a bit of a joke, at least in my neck of the woods.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
I've seen your complaints about WPF destroying images when resizing. As far as I can determine from your posts about this, you've only demonstrated it with one image. Correct me if I'm wrong.
I can only report my own experience. I've used WPF to resize thousands of images with all kinds of different camera exposures, and never once ran into anything less than accurate results.
I agree there are some "big holes" in WPF, but in my experience, resizing images is not one of them. The biggest holes I've found are related to preserving metadata through image transforms (including of course, resizing). There are other holes, often related to features of previous technologies that the WPF architects had philosophical reasons for not implementing in WPF. Developers just get around them through PInvoke, and hopefully Microsoft will find ways of delivering this missing functionality somehow in future versions of WPF that still stay within its guiding principles.
|
|
|
|
|
fjparisIII wrote: As far as I can determine from your posts about this, you've only demonstrated it with one image. Correct me if I'm wrong.
Wrong. We have an image library, and it destroyed all the photos, which were all jpgs. The illustrations, which were all pngs, were fine. So I dunno which of those was the issue. Our code reloads images at the requested size, and it only destroys them for some sizes, which is what makes it intermittent, but my sample code, using a known bad size, destroyed the image every time.
We resize the images because WPF is so terrible at resource management.
fjparisIII wrote: I've used WPF to resize thousands of images with all kinds of different camera exposures, and never once ran into anything less than accurate results.
I suspect the difference is that we resize to arbitrary sizes ( although we always maintain aspect ratio ) and I expect most people would just resize to obvious steps, like 800x600, 1600x1200, etc.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Christian Graus wrote: I suspect the difference is that we resize to arbitrary sizes ( although we always maintain aspect ratio ) and I expect most people would just resize to obvious steps, like 800x600, 1600x1200, etc.
I just got through resizing 250 TIFF images from full sizes images (max size was 3504x2336, but about 3/4 of them were cropped in various ways) from a Canon EOS-1 Mark II to JPEGs into a box 628x471, which is a pretty off the wall, non-standard size, and every image was as perfect as you would want. Come on. I challenge you to tell me what "arbitrary sizes" don't work and I'll be perfectly willing test those sizes. I would jump for joy to see failures as you've described, but I have little hope that I will.
|
|
|
|
|
fjparisIII wrote: I challenge you to tell me what "arbitrary sizes" don't work and I'll be perfectly willing test those sizes.
Well, like I said, we have two sets of images, one are photos and the other are illustrations. One are jpegs and the other are pngs. Our code lets you drag out a zoom box, and the image is resized to fit. For some sizes, the images failed. I don't even know if the sizes were always the same, I just took the time to work out a size that always failed for one specific image, and submitted that to MS. The image I use in my blog, was definitely the one that looked the worst, but you could see the degradation across a whole range of images, as I said. I have proven that it's a bug, MS accepted it was a bug, although they never fixed it, I've blogged about it, I have zero interest in getting in an argument with you about it. If every image got destroyed, at any unusual size, MS would plainly have found it and fixed it prior to release. But, the bug is real and reproducible, for the images we have ( clinical photos and radiographs ). I could care less if you believe me, and if it's never affected you, I am glad for you.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Hi,
Please do let me know about how to disable the maximize button in a WPF application.
Thanks in Advance,
Ashwath.
|
|
|
|
|
Surely there's a MaximizeButton property on the form, just like there is in winforms ?
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
|
Wow - that's not insane at all.......
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Yeah gotta wonder why it was left out.
But who wants to use the OS windows in WPF anyway 
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
True - we always generate a fake title bar so we can style it. Another weird oversight, IMO.
Christian Graus
Driven to the arms of OSX by Vista.
Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
|
|
|
|
|
Hi
In design u set the code like ResizeMode="CanMinimize"
|
|
|
|
|
|
I have a WPF image viewing program that I thought for sure was automatically using ICC color profiles imbedded in bitmap images. I thought this for two reasons: (1) I never found any properties in classes like Image, JpegBitmapDecoder, or TiffBitmapDecoder that let you specify whether color profiles are used, so I thought it just did it by default; (2) None of my beta testers ever complained. In fact I had one raving about the high quality of image rendering my app had on his high gamut monitor, and I also have a high gamut monitor where the images just knock your socks off. But I now suspect that the colors look accurate only because the images use the sRGB color space.
In a previous app using GDI+, I had to explicitly tell GDI+ to use ICC color profiles by passing true for the icm parameter of various Bitmap constructor overloads, and it was obvious that this was working, because when I used Adobe RGB for my TIFF files and sRGB for my JPEG files and I A/B'd them, there was no perceptable color difference. If they were not used, the TIFF files would appear washed out because sRGB is used by default if you don't explicitly tell GDI+ to use ICC color profiles. They appear washed out because Adobe RGB has a wider color gamut than sRGB.
But when I specifically A/B'd the same under my WPF application, I was appalled to see that the ICC color profiles built into the images were not being used! My sRGB images looked great and my Adobe RGB imaes looked washed out, whereas in Photoshop they looked the same. Now WPF is touted to be an outstanding replacement for GDI+ applications that Windows Forms and C++/MFC applications were forced to use.
What is really surprising is that the BitmapFrame class (the class I use to display images) has a ColorContexts property that has the ICC color profiles! So why wouldn't it be using them??? This is a read-only property and there doesn't seem to be any other property that would tap the BitmapFrame class on the shoulder and say, "Hey, use your ColorContexts property to display the bitmap, dummy."
Since it has the ICC color profiles right there in front of it, I find it impossible to believe that WPF does not have a way of telling its visual layer to use them. If it doesn't, this would be an application killer of a defect and I'm just sunk: nine months of development down the drain! Please tell me I'm just blind and have somehow missed the property that I must set to get WPF to use ICC color profiles! What is it that I have to do?
modified on Friday, October 2, 2009 9:12 PM
|
|
|
|
|
You need to use one of the BitmapEncoder classes (not the BitmapDecoder classes) and set the ColorContext through that.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
I'm not sure how your suggestion applies. I'm taking image files straight out of Photoshop that already have ICC profiles imbedded in them, getting a BitmapFrame from them (through static member, BitmapFrame.Create()) and actually displaying the image though a statement like the following:
image.Source = BitmapFrame;
where "image" is an instance of the Image class and is imbedded in a Grid.
I have told my camera to use the Adobe RGB profile and Photoshop finds that profile in the TIFF files that I save. Then in a separate step, I tell Photoshop to convert the profile to sRGB, and save the result as a JPEG. Re-reading the files into Photoshop shows that the TIFF files do indeed have Adobe RGB and the JPEG files do indeed have sRGB, and they look virtually the same in Photoshop. But when I use the above technique for reading and displaying the TIFF and RGB files in my application, the TIFF files lose saturation, a typical result from ignoring the imbedded profile and applying sRGB by default, as many WEB applications do.
|
|
|
|
|
Imagine an ItemsControl that is a fixed width. Each item is a grid with a fixed width as well.
Let's say each grid item is 200 pixels wide, so when generated in the items control it's like:
Name: Value
Name: Value
Name: Value
Value is dynamically rendered. I host it inside a content control, like this:
<ContentControl Content="{Binding Converter={ControlConverter}}" HorizontalAlignment="Stretch"/>
Inside the converter, I might return a TextBox, a PasswordBox, a CheckBox, etc.
The problem I'm having is that I am setting the width of these like so:
return new TextBox() { HorizontalAlignment=HorizontalAlignment.Stretch };
Of course I'm setting other properties but you get the gist.
Unfortunately, the resulting controls are sizing themselves to the content, not the container.
The stretch basically isn't working the same as if I have a actual TextBox in place of the content control.
Anyone have an idea of why the stretch isn't working? Should I wire into some event and rebind the size somehow or make it dependent on the parent control (perhaps pass the parent as a parameter?)
Thanks,
Jeremy
|
|
|
|
|
Have you tried setting the ContentControl's HorizontalContentAligment
to Stretch?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Worked perfectly, thank you!
|
|
|
|
|
I have to realize a binding like this
<br />
<TextBlock Text="{local:mybinding Path=folder1.folder2.item}" FontSize="16"/><br />
<br />
in the Path I have a string but this doesn't correspond to an object tree,
I would dynamically attach a real object that corresponds to this string.
example folder1.folder2.item1 I create an object obj1=new MyObject("folder1.folder2.item1")
example folder1.folder2.item2 I create an object obj2=new MyObject("folder1.folder2.item2")
obj1 and obj2 are the real objects I want bind.
Maybe it's possible with ExtensionMarkup but Silverlight 3 doesn't support it, do it?
Do you have any solution?
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
