|
That's what the database is for.
|
|
|
|
|
Pete O'Hanlon wrote: That's what the database is for.
You are starting to sound like SAP/SAS
Thats what the data dictionary is for. 
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Pete may have a point here, my wife has absolutely no idea how a database works.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I was talking about the files being on disk. If they're actually in the database, you should be safe.
.45 ACP - because shooting twice is just silly
-----
"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
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
Never mind. Got it
Everything makes sense in someone's mind
|
|
|
|
|
Thats got to be the fastest response I have ever seen. Normally there is a few minutes delay while you think about it.
OR did you edit the original question!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Kevin Marois wrote: Never mind. Got it
Ok.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
My latest tip/trick
Visit the Hindi forum here.
|
|
|
|
|
Hi!
I have added a hyperlink in silverlight.
But when i click on the link it displays a blue rectangular border for the size of the hyperlink control.
The link opens a popup window, so this doesn't look so good on the webpage.
<HyperlinkButton x:Name="History"
Content="History"
Margin="0"
FontFamily="Arial"
FontSize="10.667"
Click="HistoryHyperlinkButton_Click"
Foreground="Black"
FontWeight="Bold" Background="{x:Null}" Cursor="Hand"
BorderThickness="0"
/>
Is there a way to disable this or have i missed somethink?
|
|
|
|
|
One way is to set the IsTabStop="False" on the button.
The other way, more correct but tedious, is to style the hyperlink button to modify the focussed state of the state manager.
For this you will need to either use Expression Blend or pick up the style from msdn and then modify and use it.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
My latest tip/trick
Visit the Hindi forum here.
|
|
|
|
|
Thank you!
IsTabStop got the result i wanted 
|
|
|
|
|
I see a large body of work on handling dialogs amidst the MVVM WPF application, but I am having a tough time finding a good example of a standard Folder browser dialog. I want to browse for a folder and then get a list of files from the selected directory.
Can someone point me in the right direction?
Cheers, --EA
|
|
|
|
|
I would use an IOC container like a simple ServiceLocator and implement a simple dialog service. Some of the MVVM frameworks already have this. Both a ServiceLocator and a DialogService are pretty trivial to implement.
|
|
|
|
|
Seems like a lot of pomp and circumstance to me to get a string value from the client. I have looked at the MVVM Light Toolkit and a couple of the other examples out there and just thought it seemed like an awful lot of code for a simple request. I guess that is why they pay us the "big bucks" though.
Thank you for your insight,
Cheers, --EA
|
|
|
|
|
MVVM *IS* pomp & circumstance. Most things you can do "the old way" in 1/10th the code and 1/10th the time that it'll take you in MVVM. You don't need to use it. You can write a WPF app just fine "the old way".
Since you mentioned a FolderBrowserDialog, I'll use that as an example of why MVVM is "teh awes0me!" .
The Old Way: Lets say you have a dialog with a button on it. The button launches the FolderBrowserDialog. You've just rendered the entire window and all the code involved "untestable". If you try to run a unit test and happen to run down the path that pops up the FolderBrowserDialog, no one will be there to select a file and thus your unit tests will fail.
Normally, your "infrastructure" code will be unit testable and your GUI code will not be.
MVVM splits that up. So now your infrastructure code is unit testable AND about "most" of your GUI code is as well.
The ServiceLocator helps solve part of that problem.
Lets say your code is littered with:
FileDialog fd = new FileDialog();
fd.Browse();
... fd.SelectedFile;
you can't unit test that... but with a service locator, you can... now instead of having that code everywhere, you'd do:
IDialogService svc = ViewModelBase.ServiceLocator.GetService<IDialogService>();
svc.ShowFileDialog();
How will that help?
Well, under normal circumstances, you would have a REAL IDialogService and ShowFileDialog() would call FileDialog fd = new FileDialog();, etc...
but when you are doing unit tests, you would register a dummy IDialogService, in this version, ShowFileDialog() would simply be hardcoded to return "c:\\dummy.txt".
You haven't changed any application code at all and now you can unit test.
Makes sense?
Thats just a basic example, but thats the general concept behind the service locator pattern.
If you don't care about unit testing and you are working on the code by yourself, I'd skip MVVM. If you are required to do unit tests, MVVM and ServiceLocator will work well.
In general, MVVM will produce cleaner WPF code (once you get your pomp & circumstance code in place ).
|
|
|
|
|
I don't particularly care about unit testing and I am working on this project by myself, but not being a formally trained programmer and picking up everything from the internet, I am hesitant to take the easy way and end up in a bad habit situation. Some day there could be a second gunman on the grassy knoll, so to speak, and I don't want to be the one left holding the smoking gun.
With that said, this answer definitely provided me with the greatest insight and I appreciate the candor. Prior to working with this WPF MVVM project I have worked only on C# Windows Forms Apps, so I don't understand the concept of a service locator or how to implement the service model. I have been googling it for the past two days and there is hardly a large body of work on this subject. It seems to me that WPF and MVVM are an underdeveloped concept still, which is good. Always nice to be on the "cutting" edge.
Could you give me a couple google buzz words that might point me in the right direction?
Cheers, --EA
|
|
|
|
|
This[^] link might help you.
The funniest thing about this particular signature is that by the time you realise it doesn't say anything it's too late to stop reading it.
My latest tip/trick
Visit the Hindi forum here.
|
|
|
|
|
I read through that and I just don't understand why I need to implement such a lengthy amount of code for such a simple task. Besides that, the example provided really isn't relevant for what I want. I am looking for a folder browser dialog that returns a directory or even a string if not a directory.
Looking at all this code I see that it is generally a method of reacting to input, but I do not see where it sends information back from the window to the client, aside from giving a dialog response (ok, cancel, etc)
In addition to that, if there is no native folder browser dialog am I going to have to write a user control with a treeview that navigates the file system, because that looks like a lot of excess code as well.
|
|
|
|
|
In my previous response, I gave you an example of why ServiceLocator is "good" as it relates to the folder browser dialog. The link that Abhinav gave you is a bit over engineered and generalized IMO. ServiceLocator is not MVVM. MVVM is the architecture pattern and ServiceLocator is one of the design patterns used to support it. To do MVVM "the right way", you'd need ServiceLocator, a dialog service and an event aggregator service. Some people will use a mediator pattern instead of event aggregator, but I wouldn't. EventAggregator is just as easy (if not easier) to implement and its more loosely coupled and more general.
Once you get past all the pretentious buzz words, all this stuff is pretty basic when implemented in a generic way.
ServiceLocator is just a map of service type -> service instance
EventAggregator is just a map of message type -> subscribers
* unit testability is one reason for MVVM
* expression blend support is another
* you could theoretically have a graphics designer do the eye candy aspect without having to touch the code (theoretically)
* its easier to completely swap views out for something else
Honestly, as I mentioned before, if you don't care about the 4 points above (and don't think that you ever will), why bother with MVVM? it does have an initial startup cost to get everything situated and understand the concepts. BUT, if your infrastructure is well designed in a generic reusable package, that start up cost is one time and can be reused in all future MVVM projects.
Another quick example... if you are used to the Winforms way, your window code are probably very closely coupled to the data structures and control types. If your first pass is a linked list tied to a list control, you probably have all the linked list stuff intermingled with list control stuff. What if you want to change one or both to something else? That'd be a hassle without MVVM, but with MVVM, it would be a lot easier.
|
|
|
|
|
In my many months of research on this I don't think I have found a better explanation than that. I like MVVM and WPF, I like the concepts and the ideas. The esoteric language is what makes it all so difficult. Thanks for the candid response.
|
|
|
|
|
There is a built in FolderBrowserDialog. See SHBrowseForFolder(). Its kind of cheezy looking. If you are only targeting Vista and above, you can use the FOS_PICKFOLDERS flag on IFileDialog for a much nicer one.
|
|
|
|
|
I use WPF with MMVM all the time. I don't understand your confusion. What's wrong with this?
public string PromptForFile()
{
string retVal = string.Empty;
OpenFileDialog fileOpen = new OpenFileDialog
{
InitialDirectory = ".\\",
Filter = "All Files (*.*)|*.*",
FilterIndex = 0,
RestoreDirectory = true
};
if (fileOpen.ShowDialog() == DialogResult.OK)
{
retVal = fileOpen.FileName;
}
return retVal;
}
Place this code in you viewmodel, or in some class called by your view model. Store the return value to a property on the view model that implements INotifyPropertyChanged, and your View will see it automatically.
Everything makes sense in someone's mind
|
|
|
|
|
Kevin, it sounds like you don't really fully understand MVVM. What you did here is "illegal" in MVVM. Your ViewModel is supposed to be unit testable. Popping up a modal dialog violates that.
|
|
|
|
|
umm, ya, sure - I don't understand MVVM.
If you read what I wrote, you would have seen where I said to put this in some class that gets called from the VM.
Everything makes sense in someone's mind
|
|
|
|
|
I did read what you wrote. Did you? Did you read what I wrote?
You gave the OP a PromptForFile method that calls fileOpen.ShowDialog() directly.
It doesn't matter what class that method lives in, calling it from the **VM** is a violation of MVVM -- because it pops up a modal dialog thats not mockable.
Had you used a ServiceLocator like everybody else in this thread suggested, that method would be fine and could even live in your VM.
Are you somehow magically subclassing OpenFileDialog?
MVVM is more then just splitting your CodeBehind into another class. Its also about making your ViewModel unit testable. Popping up a modal dialog (like the OpenFileDialog or MessageBox) without it being replaceable is not allowed.
|
|
|
|
|
The traditional MVVM way to do this would be to implement something like:
public string PromptForFile()
{
IFileDialog dialog = ServiceLocator.Get<IFileDialog>()
{
InitialDirectory = @".\",
Filter = "All Files (*.*)|*.*",
FilterIndex = 0,
RestoreDirectory = true;
}
if (dialog.ShowDialog() == DialogResult.OK)
return dialog.FileName;
return string.Empty;
}Obviously, this implies the use of a service locator, and there are many acceptable alternatives including my particular favourite MEF.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
