|
Well, I tried your solution, but it made no difference. Is there another way to solve this? Is some way in the binding to force the datatype to be a particular type?
Thanks
|
|
|
|
|
Make sure all the service references involved are configured the
way you want them and updated (right click service referenc(es) and
choose "Update Service Reference").
If the automatic code generation tool isn't giving you what you
need then you can always hand-code the service interface stuff.
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
There's even some who would never use a tool to generate
the proxy code for them 
(I am not one of them)
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I just had a surprise from WPF in that the drawing functions are anti-aliasing (or something similar) my drawing.
Im not doing naything fancy :
....
RenderTargetBitmap renderBitmap = new RenderTargetBitmap (
PixelWidth,
PixelHeight,
DpiX,
DpiY,
PixelFormats.Pbgra32 );
foreach ( DrawingVisual aVisual in visuals )
{
//blah blah, get dc for each visual in my list, draw geomtry to visual
...
renderBitmap.Render ( aVisual );
...
}
Image img = new Image ( );
img.Source = renderBitmap;
///blah blah encode and save stream to file
all the geometries are simple pens of single color, but the final image has been antialiased, edge colors 'smoothed'.
As this is is an imaging app where every pixel value must be specific, I cant tolerate any kind of 'smart' smoothing.
What am I doing wrong wrong ? How can I guarantee that ONLY those colours that I specify will be displayed ? There must be someway to turn off this ant-aliasing.
thanks for your help, any suggestions or alternative would be appreciated.
|
|
|
|
|
Have you tried setting the VisualEdgeMode property of your DrawingVisuals
to Aliased (or maybe setting RenderOptions.EdgeMode="Aliased" on your RenderTargetBitmap,
something like RenderOptions.SetEdgeMode(renderBitmap, EdgeMode.Aliased); ?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks
I tried that on pretty well everything, the RenderTargetBitmap, the DrawingVisuals, and the PathGeometries (and even their pen and brush and Transform ) but still no luck.
That option didnt seem to make any noticable difference.
Any other suggestions ?
|
|
|
|
|
Hi,
I am trying to develop a desktop application in which I need to save some data locally. There will be images and information related to images in xml. There can be 100’s of images and multiple xml files.
1. How can I save all files (images + xml file) into one DAT file (so to speak)?
2. Could it be possible to save files in different folders inside that DAT file? If yes, how?
3. If I decide to use Access dbf file instead of xml, can it be saved as part of dbf file?
Please advice. Thanks
Pankaj
Follow your goals, Means will follow you ---Gandhi---
|
|
|
|
|
There's nothing in your post related to WPF/WCF/WF.
You can store any data you'd like to in a file.
You'll probably need to come up with a file format
that has enough information to extract individual items,
perhaps some kind of "directory".
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
For some reason I have to use the cumbersome Pack URI format to access an image file in my assembly. When I use a relative URI I get a System.InvalidOperationException on the following statement: Uri uri = new Uri(ResourcePath, UriKind.Relative);. It works fine when I use the following statement: Uri uri = new Uri("pack://application:,,,/" + ResourcePath);. Here ResourcePath is set to "Resource/Screenshot.png" and "Resource" is directly under my project in the Solution Explorer. Of course the Build Action of the .png file is set to "Resource" or even the Pack URI wouldn't work, which it does. What could be causing this kind of problem?
|
|
|
|
|
If "Resource" is a project folder then it should work.
I use relative URIs to images all the time, something
like this:
Uri uri = new Uri("Images/Airplane.png", UriKind.Relative);
myimage.Source = new BitmapImage(uri);
where "Images" is a folder in the project.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I looks like I'm doing exactly the same thing you are, but it's not working, so I must be missing something. Here "Resource" is a folder in my Solution Explorer project that contains the .png file. But the absolute path into my project is not being resolved. The Solution Explorer path relative to my project is: Resource/screenshot.png.
In reading the MSDN documentation, it seems to be saying I should preface the path with a slash. But when I do that, it resolves to an absolute path in the Windows file system that winds up in the Debug folder of my project, looking for the file at C:\...\bin\debug\Resource\screenshot.png. None of the MSDN documentation that I'm reading says that should happen!
Everything I'm reading says that absolute pack URI's should be fully exchangeable with relative pack URI's. But I can't get relative pack URI's working no matter what I try. Any ideas what's wrong?
|
|
|
|
|
Your "ResourcePath" contains a valid value for sure?
Also, I would try naming the folder something other than "Resource",
not that I know of any reason why "Resource" shouldn't work...
Other than that, I'm not sure why it wouldn't be working.
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Mark Salsbery wrote: Your "ResourcePath" contains a valid value for sure?
By this you mean what I've been specifying as Resource/screenshot.png? If so, then yes, it has to be valid, because specifying the absolute URI works. I have these lines in my code so I can easily switch back and forth between absolute and relative URIs:
#if true
Uri uri = new Uri("pack://application:,,,/" + ResourcePath);
#else
Uri uri = new Uri(ResourcePath, UriKind.Relative);
#endif
Mark Salsbery wrote: Also, I would try naming the folder something other than "Resource",
not that I know of any reason why "Resource" shouldn't work...
I tried renaming it to "Screenshots" with the same failure with relative URIs and success with absolute URI. I also tried with and without an initial slash in the relative path.
Mark Salsbery wrote: Other than that, I'm not sure why it wouldn't be working.
Anyone else have any ideas? Relative URIs is something I've never been able to get working in my 70,000 line WPF app. I've got absolute URI's all over the place to get around the problem. I even defined a global string so I wouldn't have to repeat the "pack://application:,,,/" string in a bunch of different places. There must be some kind of Dev Studio project setting that is causing relative URIs to be interpreted incorrectly.
|
|
|
|
|
|
What exception are you getting (add a ImageFailed handler to the image)?
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks for your reply and hanging in there on this extremely puzzling failure of UriKind.Relative. I did as you said, adding an ImageFailed handler to the image. When I set image.Source to the BitmapImage however, The ImageFailed event did not occur. The image simply did not show up in the window containing the image.
What I want to do is set the window Width and Height based on the PixelWidth and PixelHeight of the BitmapImage (taking into consideration the window border width and window option height -- irrelevant details). But the effort to get PixelWidth and PixelHeight causes an exception, in the following code:
double imageWidth = 450;
double imageHeight = 300;
try
{
imageWidth = screenshot.PixelWidth;
imageHeight = screenshot.PixelHeight;
}
catch (Exception ex)
{
string error = ex.Message;
}
As you can see, I set a default width and height to 450x300, just so the window shows up at all, but it shows up empty. string error in the exception handler says this (slightly simplified so just so you get the idea that it is looking at a path in my source code rather than a path in my project assembly):
"Could not find a part of the path 'C:\\...\\bin\\Debug\\Images\\screenshot.png'."
See the following reply for further details on what is happening. Maybe that will provide you with a clue about what is going on here.
http://www.codeproject.com/Messages/3237304/Re-Cant-get-UriKind-Relative-to-work.aspx[^]
|
|
|
|
|
I did exactly the same thing you did in your example. I put a .png file in a folder off the project called Images, made sure its BuildAction was Resource, then tried to look at the BitmapImage.PixelWidth (which I needed to size the window exactly that was to contain the image). I got an exception that reported that it "couldn't find part of the path", and it quoted a path something like, "C:\...\bin\Debug\Images\Airplane.png". Then when I set the image Source to the BitmapImage I got no exception and when I hovered over the image.Source code in the debugger, it showed a URI something like this:
"pack://application:,,,/MyProject;component/Images/Airplane.png
This is the syntax for an absolute pack URI when the resource is in a subfolder of a referenced assembly. But the image did not display in the window. I got nothing but a blank window.
Then I went back to an absolute URI. This time I was able to examine the PixelWidth of the BitmapImage with no exception and when I hovered over the image.Source in the debugger it showed this:
"pack://application:,,,/Images/Airplane.png"
This is the syntax for an absolute pack URI when the resource is in a subfolder of the local assembly. Continuing execution, I saw the image display in the window.
Any suggestions about how I could go about debugging what is wrong when I use a relative pack URI?
|
|
|
|
|
I'm not sure what's happening on your end, but you
shouldn't be getting any paths like "C:\...\bin\Debug\Images\Airplane.png",
since that is NOT a pack uri for extracting a resource image.
As far as getting PixelWidth/PixelHeight, that could be tricky.
For example, with the following code:
myimage.ImageFailed += new EventHandler<ExceptionRoutedEventArgs>(myimage_ImageFailed);
Uri uri = new Uri("/Images/Airplane.png", UriKind.RelativeOrAbsolute);
BitmapImage bi = new BitmapImage();
bi.BeginInit();
bi.UriSource = uri;
bi.EndInit();
myimage.Source = bi;
with a breakpoint on "myimage.Source = bi;", bi.PixelWidth/bi.PixelHeight
are 0, and also having the breakpoint there causes the image to not appear.
Put a breakpoint after "myimage.Source = bi;" (removing the
previous breakpoint!) and bi.PixelWidth/bi.PixelHeight are valid (but
is that just lucky timing?).
It appears the decoding is asynchronous, and I see no event for
decoding completion...
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Your statement about getting pixel dimensions could be tricky was all the hint I needed. The problem was I was executing the following statement last in my Loaded event:
image.Source = screenshot;
and immediately after the following statement
BitmapImage screenshot = new BitmapImage(uri);
I was getting the pixel dimensions of the image:
double imageWidth = 450;
double imageHeight = 300;
try
{
imageWidth = screenshot.PixelWidth;
imageHeight = screenshot.PixelHeight;
}
catch (Exception ex)
{
string error = ex.Message;
}
Apparently the very act of asking for the pixel dimensions somehow corrupted the screenshot BitmapImage object. When I moved image.Source = screenshot; from the end of the event to the statement immediately following the BitmapImage constructor, UriKind.Relative started working! Apparently using an absolute pack URI provided enough of a delay to complete the asynchronous decoding.
I hope this explanation is clear. If it isn't, I could make another post showing all of the code for the Loaded event. Thank you very much for sticking with me on this issue.
|
|
|
|
|
Glad you got it working.
I still hope they add a proper event like they did for
Silverlight, in which they added ImageOpened events to both
the BitmapImage and Image classes, specifically to get a look
at the loaded bitmap's dimensions before rendering.
Getting lucky with timing worries me, although in this case
maybe there's some mechanism forcing the decoding of the image
at that instance. I haven't seen that confirmed in any docs though 
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Yeah, it's pretty important to be able to get the image dimensions reliably. I do that all over the place, but I'm usually not dealing with assembly resources but external files.
|
|
|
|
|
<DockPanel LastChildFill="True" Height="18">
<Image Height="18" Width="80">
<Image.Source>
<DrawingImage>
<DrawingImage.Drawing>
<GeometryDrawing Brush="Black">
<GeometryDrawing.Geometry>
<LineGeometry StartPoint="0,9" EndPoint="38,9" />
</GeometryDrawing.Geometry>
<GeometryDrawing.Pen>
<Pen DashCap="Flat"
Brush="Black"
Thickness="0.5"
DashStyle="{x:Static DashStyles.Dot}, Mode=OneTime}"
/>
</GeometryDrawing.Pen>
</GeometryDrawing>
</DrawingImage.Drawing>
</DrawingImage>
</Image.Source>
</Image>
<TextBlock Height="18" Text="{Binding Name, Mode=OneTime}" Margin="3,2,5,0" />
</DockPanel>
Actually, I want to list all line styles in a ComboBox.
Glad to discuss with you and best wishes.
|
|
|
|
|
See this discussion: DashStyles.Dot Bug?[^]
(try changing your DashCap to Square or Round)
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hello Friends,
Is there any limitation on the number of controls that can be used in a single wpf window?
Thanking in advance
Johnny
|
|
|
|
|
I don't think there's been a control count limit since we all escaped from VB6, and even there it was possible to get around it with control arrays.
So basically, you're limited by your computer and your patience, because the more controls you have, the longer it'll take to render.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
