|
jgalak wrote: I don't have a CloseableHeaders.g.cs file
If that's the case then no, it's not going to work because the members are truly not part of the class.
Right-click on the "InitializeComponent()" in your CloseableHeader.xaml.cs file....choose "Go to definition".That should bring you to the generated file (CloseableHeaders.g.cs) - the other half of your partial usercontrol class. Does it?
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Mark Salsbery wrote:
Right-click on the "InitializeComponent()" in your CloseableHeader.xaml.cs file....choose "Go to definition".That should bring you to the generated file (CloseableHeaders.g.cs) - the other half of your partial usercontrol class. Does it?
No, it doesn't. In fact, that's one of the compile errors that comes up.
Is there a way to force it to create the generated file?
|
|
|
|
|
Just create a new usercontrol by adding one to your project. Then copy the code into your new xamlcs files.
Or if you have the source code from the article then the g.cs file should be in there.
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
You are missing the obvious Mark. Its a namespace issue just as I originally said 2 days ago, but OP chose to ignore my advice  . He is missing the namespace in his x:class.
|
|
|
|
|
Well I figure if he just adds a usercontrol to the project the namespace will be fixed
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Jeez man... why didn't you just listen to me?  ... your problem is EXACTLY what I told you. Your class is WGPM.Views.ClosableTab, but your XAML is just ClosableTab. Fix your x:Class to be WGPM.Views.ClosableTab and all will be right with the world.
|
|
|
|
|
SledgeHammer01 wrote: Jeez man... why didn't you just listen to me?
Mostly, because I didn't understand how the namespace was specified in xaml. I thought that xmlns:local="clr-namespace:WGPM.Views" took care of it.
Your suggestion worked perfectly - changing the x:Class line fixed all of the build errors.
Thank you,
Juliean.
|
|
|
|
|
Hi,
I am going to create one windows application using C# + WPF + MVVM + prism 4.
But be-four start to working, i want to know few think about C#,WPF,MVVM and prism 4.
1. Which is Good Project Solution Structure for C# + WPF + MVVC + prism 4. Can give some reference for this.
2. Which is Good way to create Project Solution Structure.
3. Which is Good Way for Exception Handling
4. If any one know LinQ, is LinQ suitable with WPF + MVVC + prism 4. Any LinQ extended library which help for development.
5. Any Existing or 3'rd party library which help for development like Microsoft Enterprise Library
6. Any suggestions for different Tool,Framework,Design Patterns. ...etc
7. Any Reference/Help site links
I know this Discussion is quite big, let us know if want to create diff. discussion for each point.
Thanks In Advance
|
|
|
|
|
1. Depends on what kind of program you're writing
2. See #1
3. See #1
4. See #1
5. See #1
6. See #1
Your choices of tools and design methodologies should always depend on what you're trying to accomplish. The team developing Diablo 3 isn't going to use WPF and MEF, and a group developing an internal accounting system isn't going to be writing DirectX code... Different tools for different tasks.
|
|
|
|
|
Thanks Ian Shlasko,
Application is very simple stock management and accounting system ,
But problem is i am little but new in WPF + MVVM + Prism, so want to some guideline from u about this.
Any Link any think that help me.
|
|
|
|
|
Try this[^] out.
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
|
|
|
|
|
Given your questions I would suggest this is a very bad choice. Use the tools and languages that you understand and are comfortable with. Writing a major application in a language that you are new to is a recipe for disaster at worst, and severe pain at best.
If you just want to learn WPF then there are lots of beginner articles here on CodeProject; here[^] is a really good starting point.
The best things in life are not things.
|
|
|
|
|
Scrolling in nested Listbox
Hi Friends
Hope you all are doing good.
I have few questions about WPF List BOX
Some Background:
We are trying to build a scheduling control like outlook with some custom functionality.
I have already gone through the similar post in Code Project but we tend to take slightly different approach (trying to use MVVM approach).
Problem:
Currently we have a Listbox with 3 items. Each item in the list box is another Listbox with borders as sub items. For E.g. the XAML code looks like this.
<Grid Height="500" Width="500">
<ListBox Name="MasterListBox" HorizontalAlignment="Stretch">
<ListBox.ItemsPanel>
<ItemsPanelTemplate>
<StackPanel Orientation="Horizontal"/>
</ItemsPanelTemplate>
</ListBox.ItemsPanel>
<ListBoxItem >
<ListBox Name="Child1" Height="240">
<ListBoxItem >
<Border Width="200" Background="Red" Height="40"></Border>
</ListBoxItem>
<ListBoxItem >
<Border Width="200" Background="Blue" Height="40"></Border>
</ListBoxItem>
<ListBoxItem >
<Border Width="200" Background="Green" Height="40"></Border>
</ListBoxItem>
</ListBox>
</ListBoxItem>
<ListBoxItem >
<ListBox Name="Child2" Height="240">
<ListBoxItem >
<Border Width="200" Background="Yellow" Height="40"></Border>
</ListBoxItem>
<ListBoxItem >
<Border Width="200" Background="Green" Height="40"></Border>
</ListBoxItem>
<ListBoxItem >
<Border Width="200" Background="Pink" Height="40"></Border>
</ListBoxItem>
</ListBox>
</ListBoxItem>
<ListBoxItem >
<ListBox Name="Child3" Height="240">
<ListBoxItem >
<Border Width="200" Background="Aqua" Height="40"></Border>
</ListBoxItem>
<ListBoxItem >
<Border Width="200" Background="Beige" Height="40"></Border>
</ListBoxItem>
<ListBoxItem >
<Border Width="200" Background="Brown" Height="40"></Border>
</ListBoxItem>
</ListBox>
</ListBoxItem>
</ListBox>
</Grid>
The problem is when I click on the 1st item(Child1) of the MasterListBox in the white area and drag right, the MasterListBox list box scroll to right, But when I click on the subitem (for e.g. say red border) and drag right the MasterListBox doesn’t scroll right.
I am aware that I am trying to drag the item of the inner list box and that’s the reason the outer list box is not scrolling, But it there a way we can override this. I want to select the inner item also so cannot set IsHitTestVisible="False" for inner item.
Thanks you for looking into this. Your help is greatly appreciated.
Regards
Saurabh
modified on Friday, July 22, 2011 7:37 AM
|
|
|
|
|
I would replace the inner listbox with an ItemsControl.
Don't be overcome by evil, but overcome evil with good
|
|
|
|
|
Hi all,
My application is just fine and could work like it is now.
It would be nice to have a kind of "Wait Window" with a progress bar (optional).
So I did the following, and the wait window is showing and closing when I want it:
wndSave oWindow = null;
void oOrg_Save(object sender, SaveEventArgs e)
{
this.isEnabled = false;
this.Dispatcher.Invoke(new DispatcherOperationCallBack((param)=>
{
oWindow = new wndSave();
...
System.Threading.Thread oThread = new Thread(updWindow);
oThread.Start();
wndSave.ShowDialog();
return null;
}), DispatcherPriority.BackGround, new object[] { null });
}
void updWindow()
{
oWindow.Dispatcher.Invoke(new DispatcherOperationCallBack((param)=>
{
foreach(myModel oModel in myView.Models)
{
System.Threading.ParameterizedThreadStart oStart = new ParameterizedThreadStart(mySave);
System.Threading.Thread oNewThread = new Thread(oStart);
oNewThread.Start(oModel);
Action showMethod = new delegate()
{
oWindow.UpdateProgress();
}
}
return null;
}), DispatcherPriority.BackGround, new object[] { null });
}
void mySave(object State)
{
myModel oModel = (MyModel)State;
myModel.Save();
}
If anybody has a trick how to refresh the progressbar would be nice. It is not necessary to be able to move the window, but it would be nice also. Don't know if it is a XBAP problem.
Thank you very much.
|
|
|
|
|
I just solved it by myself:
I had to remove the dispatcher and use an Action<t> instead. That did the job
|
|
|
|
|
Hi folks!
Is it possible to define the targettype of a style to be an interface or an abstract class.
Something like this (in pseudo code)
Style s = new Style();
s.TargetType = class where inherit from baseclass
or
Style s = new Style();
s.TargetType = class which implements given interface
This is needed for creating a generic dragdrop element, where the items in the source can be derived classes.
e.g:
abstract class DDItem<T,Q>
{
public T Identifier {get;set;}
public Q DisplayableContent {get;set;}
}
<ListBox>
<ListBox.Ressources>
<Style TargetType={x:Type local:DDItem}>
<EventSetter Event="MouseLeftButtonDown" Handler="Drag"/>
</Style>
</ListBox.Ressources>
</ListBox>
Would be fine to do this in plain c# as well.
Help would be appreciated!
|
|
|
|
|
Why don't you try inheriting the Style itself?
Silverlight 5 Tutorials : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
|
|
|
|
|
Hello,
There's a lot of talk on the net about the View-ViewModel interaction but little about the ViewModel-Model interaction.
I have a Report that has (as a composition) a collection of Parameters. So I have a ReportViewModel that has a collection of ParameterViewModels, a ReportView bound to the ReportViewModel, and the ReportView in turn carries an ItemsControl-full of UserControls bound to the ParameterViewModels. The ReportViewModel's constructor gets passed the Report object and passes the Parameter objects in turn to the sub-viewmodels.
The Views and ViewModels interact nicely, the ViewModels "load" themselves from the underlying Models. More precisely, they keep a reference to the Model and synthesize whatever information the View needs.
Now for what puzzles me: when/how does the data flow back from ViewModel to Model ? When/how does the user's gesturing finally impacts the Model ?
I see that there are at least two possibilities...
1/ Live-update the Model whenever the ViewModel changes. Whenever we want to run operations on the updated Report, there's nothing extra to do.
2/ Implement an explicit "Apply" method in both ViewModels - obviosuly ReportViewModel.Apply will call ParameterViewModel.Apply. Whenever we need an up-to-date Report, first call Apply then save it somewhere, or print it, whatever.
What's your take on this ?
Jean-Louis
modified on Tuesday, July 19, 2011 7:49 AM
|
|
|
|
|
You're right. Too often the interaction from the VM back to the M is glossed over. The answer really depends on what you're trying to achieve though. If you are saving data from the view back to a database, for instance, you may want to batch all the changes from a particular edit and submit them at once. Alternatively, your backing store may be updated whenever a property passes validation. This is so dependent on your requirements that there are very few hard and fast rules.
|
|
|
|
|
When you are setting your binding to two-way, you are updating the model.
Yes, your view is bound to the viewmodel and not the model, but the view-model, but if your binding is two-way, the model is going to be udpated.
Maybe I've understood your question wrong here 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
|
|
|
|
|
I don't bind the view directly to model properties, and I don't want to change that. For starters, I don't like it. Moreover, in the general case it is not always possible. The ViewModel may contain properties that have no direct counterpart in the Model. Also my Model objects contain collections. So I would need to use ObservableCollections...but they're pulled from a Hibernate session so I don't even have control over the exact type of the collections.
|
|
|
|
|
I may have misread your post, but it seems to me like you have a fundamental misunderstanding of the ViewModel and Model portions. Yes, your View should only bind to stuff in the ViewModel only. However, the ViewModel is not creating, copying, storing, loading, saving, etc. the data, that is the models job. The ViewModel is simply a thin *wrapper* around the model and has a reference to it. If your model is implemented correctly, you shouldn't need much (if any) repackaging of the data. Your ViewModel generally just exposes a bunch of RelayCommands that manipulate the model. If you are doing a lot of repacking work in the ViewModel, or are copying around data a lot... as they say on teh internetz: "UR DOIN IT WRONG!" 
|
|
|
|
|
Hmm, I don't think I have a "fundamental misunderstanding". In my app the ViewModel does not store or load data by itself - it tells a DAO to do so. As for validation, it asks the Model to do it.
Ok, let's imagine that we rewrite Notepad the MVVM way. We have a Document object with a string property - say Content. And a DocumentViewModel that holds a reference to a Document. It has a a string Content property too, which is loaded from the underlying Document. And then a DocumentView with a text box that binds to the DocumentViewModel's Content. I know I could bind to Document.Content directly but I've beaten that horse in my original post already.
Am I on the right track here ?
Now loading the ViewModel from the Model has been dealt with but what about the data flowing back from Mr/Ms User to the View to the ViewModel to the Model ?
My current take is this…
ViewModel exposes commands such as NewCommand, OpenCommand, SaveCommand, SaveAsCommand - and then some more like Copy/Cut/Paste Commands.
NewCommand.Execute checks whether pending changes exist and possibly offers to save. Then it sets the VM's Document to a "new Document()". The VM updates its Content property and fires an event.
SaveCommand.CanExecute returns True if the document has been changed. SaveCommand.Execute copies the text from VM.Content to Document.Content then tells some object to save the document - via an interface so it can be mocked and unit-tested.
SaveAsCommand.Execute…hmmm…I guess it sets the VM's Document to a "new Document()" before transferring the VM.Content to Document.Content. But this assumes that the VM has copied all the Document's information. Or maybe the Document is cloneable and we replace the VM.Document with VM.Document.Clone() ?
Now in my real app, it's a bit messier because the Document is a composition of other objects that have their VM too.
|
|
|
|
|
Jean-Louis Leroy wrote:
Ok, let's imagine that we rewrite Notepad the MVVM way. We have a Document object with a string property - say Content. And a DocumentViewModel that holds a reference to a Document. It has a a string Content property too, which is loaded from the underlying Document. And then a DocumentView with a text box that binds to the DocumentViewModel's Content. I know I could bind to Document.Content directly but I've beaten that horse in my original post already.
Am I on the right track here ?
---
No, that is exactly what you do *NOT* do.
In your example, you have DocumentViewModel that holds a reference to a Document(Model). Document(Model) has a string Content property (the content of the text file).
So far, so good.
The next step is where you head off the reservation a bit .
DocumentViewModel should DEFINITELY NOT have its own string Content property. It should simply *wrap* the one from the Document(Model). I.e.
DocumentViewModel.cs:
public string Content
{
get
{
return _document.Content;
}
set
{
if (_document.Content != value)
{
_document.Content = value;
OnPropertyChanged("Content");
}
}
}
The reasons for this are two-fold:
1) you don't have to worry about keeping the VM and M in sync, since they are always by design in sync
2) you are not storing the same data in multiple places. Imagine if the text file is 100 bytes... no biggie right? your design uses up 200 bytes of memory. No biggie. Now imagine if the text file is 1MB or 10MB or 100MB... with your design, you are using up 2MB, 20MB or 200MB of memory. Not good.
Rule #1 in good software design, ESPECIALLY in WPF & MVVM... is that you should only have one instance of an object in memory at all times. The reason why its more important in WPF is that imagine this scenario:
SomeObject (inst 1) ... somebody binds to it ... all good... anytime SomeObject (inst 1) is modified, the UI is updated
Now imagine that somebody went and made a COPY of SomeObject and now you have SomeObject (inst 2)... changes made to one will not update the properties in the other and data binding will be broken .
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
