|
Thanks I've tried cleaning and rebuilding the project/solution but I havn't tried deleting the .suo file.
|
|
|
|
|
Ok tried that and a few other things still get the same error and can't display design time window. Also it won't let me compile a release version like this although a debug version is fine.
|
|
|
|
|
|
ok now I can get it to build debug or retail on my desktop but my laptop gives me the error. Mind you it always been the laptop giving the error. Brand new Laptop 4gig ram, has the new AMD APU in it. What throws me is that it will compile and run in debug but not retail and the designer can't display my main form.
Yet, on my desktop it is fine. This is driving me nuts. As for the Library Controls links I reviewed them, I do have some custom controls in my project but have not been giving me any trouble as they are basically overridden controls. Extended RTF editor, Masked Text Box, etc.
|
|
|
|
|
I've tracked down the issue, trying to resolve it now. My issue stems from creating a custom style in Blend for parts of a third party control. I am using NavigationPane from Codeplex and had created styles for the splitterbars and buttons this seemed to work fine on my desktop but when moving it to my laptop it wouldn't display the design-time preview of the form. removing the Style="" comment made it viewable again. I've decided to modify the source code of NavigationPane and added my own style to it's list of Styles. So far this has solved the issue.
This has been resolved Thank you for all the help.
modified 21-Sep-11 18:25pm.
|
|
|
|
|
I'm building a pie chart (from the WPF Toolkit). Here's the code:
public Chart ChartObject;
protected void MakePie(List<RepItem> data, string seriesTitle, string yProperty)
{
DisplayCategories categories = new DisplayCategories();
foreach (RepItem item in data)
{
categories.Add(item.Category);
}
System.Collections.ObjectModel.Collection<ResourceDictionary> palette = MakePalette(categories);
this.ChartObj.Palette = palette;
PieSeries series = new PieSeries()
{
ItemsSource = data,
Title = seriesTitle,
DependentValueBinding = new System.Windows.Data.Binding(yProperty),
IndependentValueBinding = new System.Windows.Data.Binding("Category"),
TransitionDuration = new TimeSpan(0),
};
this.ChartObj.Series.Add(series);
}
I have to build the palette manually because the number of values represented in the pie isn't necessarily the same, and they values are sorted from lowest to highest before creating the series. The end result is that the pie slice color must always be the correct color for the associated category regardless of that category's position in the pie.
In any case, that part works great. However, I decided I wanted custom tooltips, so I created a custom ControlTemplate in the app resources:
<ControlTemplate x:Key="PieDataTemplate" TargetType="wtkchart:PieDataPoint">
<Grid>
<Path x:Name="Slice"
Data="{TemplateBinding Geometry}"
Fill="{TemplateBinding Background}"
Stroke="{TemplateBinding BorderBrush}">
<ToolTipService.ToolTip>
<StackPanel>
<ContentControl Content="{Binding Path=Category}" FontSize="12" />
<ContentControl Content="{TemplateBinding FormattedDependentValue,
Converter={StaticResource TooltipValueFormatter}}"
FontWeight="Bold" FontSize="14" />
<ContentControl Content="{TemplateBinding FormattedRatio}"/>
</StackPanel>
</ToolTipService.ToolTip>
</Path>
</Grid>
</ControlTemplate>
If I uncomment out the code in the c# code, I get the tooltip I want, but all of the pie slices turn orange. If I re-comment the code, the tooltip isn't right, but the colors are. I THINK I want to change the binding on the Fill property in the control template, but I don't know exactly how to bind that with the parent chart's Palette property.
Any help?
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Would there be any way you would be able to bind the Palette background with the Fill background using relative resources?
Too much of heaven can bring you underground
Heaven can always turn around
Too much of heaven, our life is all hell bound
Heaven, the kill that makes no sound
modified on Friday, August 26, 2011 2:29 PM
|
|
|
|
|
Well, the Palette is a collection of ResourceDictionary objects, each of which contains a single brush component, so there is no palette "background" to bind to.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Well, I made the decision to switch away from the WPF Toolkit to Visiblox. In less than 1 day, I got all the charts working the way I wanted. I fought with the WPF Toolkit for more than a week, and it was still not right.
Good riddance WPF Toolkit. What a steaming pile...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
John Simmons / outlaw programmer wrote: Visiblox
Makes sense. Use whatever supports our requirements.
In defense of the toolkit, its not too bad.
I wonder why they have not been upgrading it though.
Too much of heaven can bring you underground
Heaven can always turn around
Too much of heaven, our life is all hell bound
Heaven, the kill that makes no sound
|
|
|
|
|
Abhinav S wrote: In defense of the toolkit, its not too bad.
Until you start to color outside the lines. I've NEVER experienced a time when I didn't need to do something that was beyond the in-the-box capabilities of of a chosen framework/library. The fact that it's near impossible with the Toolkit answers your next question:
Abhinav S wrote: I wonder why they have not been upgrading it though.
Because they know it's crap from a real-world standpoint.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
I used a WPF Toolkit DataGrid.
I'd like to move cell in a column with mouse.
There are a lot of examples about the drag & drop row but nothing for drag & drop of cell.
How can I do to drag & drop cell in a column ?
Thanks.
|
|
|
|
|
Hope the title is OK. Didn't know how to put it any better.
I am looking here for some background information, opinions if you will. I know how to code them.
But I can't get my head around why sometimes things are done one way and sometimes the other.
If you read WPF books (mostly) they teach you to implement RoutedUICommands.
So in short, to have a static class with commands, commandbindings in XAML and some codebehind.
If you read some of the MVVM articles on this site or this article http://msdn.microsoft.com/en-us/magazine/dd419663.aspx[^].
They implement classes with ICommand interface and/or a RelayCommand : ICommand class and put some command handling in the ViewModel
So, when and why, pros and cons, of using one or the other. This is what I hope to hear from you.
|
|
|
|
|
You should always write WPF code the MVVM way. It just produces cleaner, more organized and more efficient code. WPF and MVVM are really a match made in heaven. Once you get your MVVM framework situated, MVVM isn't all that difficult. People who don't want to take a couple of months to learn it and set up a framework are the only ones who make a big deal about how "hard and complicated" it is. If you try write a WPF the non MVVM way, you'll end up with a mess of spaghetti code.
|
|
|
|
|
Very well, I agree that MVVM is a good pattern.
But when not using RoutedUICommand class you loose the bubbling and tunneling, right?
This wil not get me into problems?
|
|
|
|
|
RelayCommand is really kind of required for MVVM. It allows you to define the CanExecute & Execute handlers as part of the RelayCommand object itself. With other types of command implementations, you need to add them to the CommandBindings collection which you don't really have access to in MVVM since the CommandBindingsCollection is part of the window and not the VM. You don't need bubbling and tunneling in VMs. Its mostly handling clicks and such.
|
|
|
|
|
Hm, make good sense to me.
Thx. 
|
|
|
|
|
Oh, one other thing I can clear up for you... bubbling and tunneling is really only useful in controls IMO. You may have thought about using them to communicate between a child view and the parent, but that is really not the recommended pattern in MVVM. Most frameworks will include some sort of messenger service that basically lets you send async messages around to anybody who cares to listen for that specific message.
|
|
|
|
|
SledgeHammer01 wrote: If you try write WPF the non MVVM way, you'll end up with a mess of spaghetti code.
FTFY...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Seriously? WPF seems way cleaner then MFC or Winforms. Sounds like you need a better MVVM framework  .
|
|
|
|
|
|
The best framework is one you write yourself
No joke. This is exactly what I did. There are a lot of popular frameworks out there: MVVM Light, Cinch, etc, but I've never been a fan of grabbing a bunch of open source libraries and getting them to work together. By writing it yourself, you learn MVVM and you know how stuff works inside. Imagine if you used Cinch and found some issue? Sascha is very active on CodeProject, but you never know what could happen down the road. Personally I like real light-weight stuff. So I pretty much have a full light-weight MVVM framework + light-weight DI container and don't have any of the Silverlight fluff that other libraries have.
|
|
|
|
|
I am not a fan of just grabbing a framework
either. At least you have to know the concept of what is happening in there. Otherwise when you will run into bug of the framework you will get stuck.
I am now in the process of making this decision. I know MVVM is the way to go. But I think I will start with my own implementation to see before I get involved in a framework.
Do you know this framework?
<a href="http://www.codeproject.com/KB/WPF/CatelPart0WhyChoose.aspx">Catel - Part 0 of n: Why choose Catel?</a>[<a href="http://www.codeproject.com/KB/WPF/CatelPart0WhyChoose.aspx" target="_blank" title="New Window">^</a>]
It’s a relative newcomer. What do you think of it?
|
|
|
|
|
I am developing an application for a project, and it requires many different features that each has to be addressed in a separate window....
so it should be built on something like a (next//back) hierarchy. This is what I've been doing:
**************************************
Parent par;
public Subclass(Parent var)
{
par = var;
par.hide()
this.show()
}
public void getback()
{
Parent.show()
this.close()
}
**************************************
the problem is, windows pop-up in different locations, and its generally unattractive... is there a better way to handle things in one window, or perhaps spawn windows at a specific location?
thank you
|
|
|
|
|
I siggest you read up on navigation[^]
Never underestimate the power of human stupidity
RAH
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
