|
Are you using a viewmodel to supply data to the view? If the datacontext of the view is the viewmodel, you might have to use a relative source to access the proper data context.
ex:
<ComboBox
ItemsSource="{Binding RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type UserControl}},Path=DataContext.DocRefTypes}"
DisplayMemberPath="Type"
SelectedValuePath="Id"
Grid.Row="2"
Grid.Column="1"
Margin="5,1,4,1"
Width="395"
SelectedValue="{Binding ReferenceType}"
HorizontalAlignment="Left"/>
It really depends on the data context for the container of your control, but if the parent container or control has a datacontext set on a viewmodel, this might work for you. Change the Path to point to whatever the ObserveableCollection(?) that you are trying to bind to.
Cheers, --EA
|
|
|
|
|
Thanks for the response. I'm a part time 'programmer' trying to learn C# and WPF after years (and years) of Excel VBA and some T-SQL. The MVVM learning process has been VERY slow for me as I completely lack experience in creating and, more importantly, programming with POCO classes. All my past work that required data access used direct connections to the db and calls to stored procedures.
So, in a long winded fashion I'm replying that this WPF attempt is not using MVVM concepts and I'm trying to databind to EF EntitySets and EF entities.
Because of the issue in the original question and some other problems, I've paused the project while trying to get some MVVM education. Still am struggling to find any non-trivial examples/explanations of how one goes from EF or LinqToSQL to MVVM models. While there is a tremendous amount of quality MVVM information available, here and elsewhere, there seems to be an ongoing assumption that the readers are well versed in getting from a database datastore all the way through the construction of the models. I see very little discussion about what concepts are important to incorporate, what the approach should be, etc.
Again, thanks for your response. Maybe I'll be back after making progress on the MVVM front.
|
|
|
|
|
I define some listview that each row contain 2 button.
Each button contain text that exist in the sql server database.
I want to bind the button text to the database - but i don't know how to do it because of the special listview structure.
|
|
|
|
|
The simplest way to do this is to create a DataTemplate as I demonstrate in this[^] article.
|
|
|
|
|
Yanshof wrote: I want to bind the button text to the database - but i don't know how to do it because of the special listview structure
Very briefly, you need to get data back from the database (via a web service) and then the ListBox's itemsource to a collection.
The button's can then be bound to the properties within the collection.
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.
|
|
|
|
|
In the winforms apps I could load the data on demand because it was nice and synchronous and it only loaded when the app required the data and then held it in a static class for the duration of the app.
This all falls apart when we move to silverlight, at the moment I have a viewmodellocator that creates static viewmodels and the 'static' data is loaded upon application start, 6-10 asynchronous calls are made to the database to get the data to support comboboxes etc. This can result in state clashes as the service tends to lose the plot.
I am looking at implementing a queued process where each call waits for the previous to complete before jumping the service. We are using the Galasoft messaging to manage comms between the viewmodels so it is a fairly simple process.
Any better suggestions on how to handle this issue will be appreciated.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I would do the data retrieval at app starup, and defer EVERYTHING else until that's completed. I know it kind breaks your tidy MVVM stuff, but hey, those are just guidelines, right?
Our silverlight app makes half a dozen or so calls to a web service before anything else is done (and for the same reasons as yours).
.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
|
|
|
|
|
John Simmons / outlaw programmer wrote: Our silverlight app makes half a dozen or so calls to a web service before anything else is done
Mine is doing the same, that are all asynch of course so I'm getting some errors where the state of the object (the service) won't process the request. I presume this is caused by the half dozen asynch calls all being fed in at the same time.
So do you put up a progress indicator while loading the static data.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
No on the progress indicator.
I came up with a system where I queue up the web service requests into a list, and execute them one after the other. When the last one is done, it sends a "complete" event. I wrote an article about it here:
How I Optimized my Silverlight Asynchronous Web Service Consumption[^]
I made it even simpler by having a single "get" method in my web service that accepts the stored proc name and an xml data string that represents the parameters needed by the stored proc. I believe I briefly touched on that in the article, but I did write a tip/trick about that aspect:
Pass a Dynamic List of Parameters to a Web Service[^]
You may be able to extract something useful from those two items.
.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
|
|
|
|
|
I remember reading the T/T and thinking nah, not for me, I generate all the code in the service anyway so a generic proc has no real attraction.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Hello,
I'm implement some UI application.
The problem i have is how to fire events between two threads ?
Thread A (ui main window/wpf) launch thread B (console app project) with the logic of the app. here i have some recursive algorithm, which generate some question to the user.
Then by event i fire this question to the main ui window and update the ui with the relevant question (any other way to do it ?)
After the user see the question he needs to insert some answer, and according to this input the recursive algorithm continue it's execution.
The problem is how to idle the recursive execution (while the user decide what to answer...)
I was thinking to use background-worker/busy waiting, but is it possible to fire events between threads ?
Thanks for help
|
|
|
|
|
And it's a cross post - don't spam the forums, select 1 and wait for a response.
Why do you feel you need to have multiple threads for what is a very simple process.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
then how can i implement it by using single thread ?
|
|
|
|
|
Why would you launch a console app? From the sound of things, you are trying to communicate across PROCESSES, not threads.
|
|
|
|
|
I started with console, i'll move it to class library, and eventually i'll add a dll as a reference.
|
|
|
|
|
First of all, you are not really dealing with multiple 'threads' here. Yeah, each process executes on its own thread, but you are really not writing a multi-threaded application.
You are writing two applications.
Your question is REALLY about how to get the two applications to talk to one another.
There a bunch of ways you can do that. Use sockets, use web services, etc...
But first ask yourself the big question....
WHY are you forcing yourself to use this design?
What is requiring you to set this up in this way?
|
|
|
|
|
what do you mean "why i forcing myself..."
I implemented some algorithm, and now i want to ad an ui...
also i would like to build some data base of users, ans store there their profiles.
so far i have three different projects (for each layer) what wrong with that ?
|
|
|
|
|
You need to go back and look at your wording though...
You state that you main application (you call Thread A) is a windows/wpf application and that it launches 'a console app' (that you refer to as Thread B0 that takes care of some backside processing based upon the answer, but no matter there...
The fact that they are separate processes is a bit concerning because now you are spinning of a completely different application (process) that you have specified as a console application to do processing in the background, when in reality it sounds like what you really want to do is just create a new process that is part of your existing application, throw it up on a new thread so it can run independently of the main thread (not a bad thing) and then do your processing as needed.
In reality, if you use separate physical processes, you ARE creating different threads. Each individual process gets it's own thread of execution... but now you need to deal with inter-process communication options like pipes, web services, sockets, etc...
I would just build a class to contain your additional processing, spin an instance of that up internally and use events to pass data back to the main thread when you need to update something visually. Dealing with an app that has multiple individual PROCESSES can be a real pain to maintain, debug, and extend latter on.
|
|
|
|
|
Thanks for the detailed answer...
First, my logic is not a console app, it started with console, but then i wrote it from scratch as a dll.
AS your advice, i put my logic into additional class, and i use events to pass data, but i still have some problems with the recursion which should be idled when it waiting to the users answer...
|
|
|
|
|
Sorry, I have been away for a while on vacation...
I am a bit confused when you mention recursion... if you are just sitting there waiting for a user to answer a question then you are really not using recursion.... you really just need to let that thread spin on and wait for a request from the client. Just put the processing in your separate thread into a loop that keeps it cycling until it gets a request from the host to perform some processing. Because it is on a separate thread it will not interfere with processing while it is just waiting.
Usually you just wrap everything in your thread function inside a do loop that watches for different flag settings to know when it needs to abort and end or process some data.
|
|
|
|
|
Hi,
When i say recursion, i mean that the flow of the algorithm will repeat it self depending the user input
|
|
|
|
|
We have many windows services on several servers.
How do you suggest to build a silverlight 4.0 application which monitors these services on servers?
I am thinking to have a functionality to check the status of each service on each server every so often i.e. every few seconds...
What are your thoughts please?
Thanks
|
|
|
|
|
You'd have to communicate with a backend web service, which polled these services to see if they were running or not. The Silverlight application would trigger the web service periodically (say every 10 seconds) and the results would be updated in a notifiable object.
|
|
|
|
|
Do you mean like having a timer inside a WCF to monitor changes every so often?
And then use the silverlight to check the WCF?
Please elaborate.
Thanks
|
|
|
|
|
I'd initiate this from the Silverlight side if I were you. Have Silverlight request the information from the service at timed intervals.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
