|
One word. INotifyPropertyChanged. Have a look at this little puppy - it can be your best friend.
|
|
|
|
|
AHHH!
I wish i knew about that 4 weeks ago
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Tristan Rhodes wrote: I wish i knew about that 4 weeks ago
Sorry. I only just read this thread last night.
|
|
|
|
|
No worries. I don't think that it's suited for the problem i had, but it definitely has some uses is some other stuff i was working on.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
To be honest, I'm having a little trouble picking up the problem domain from this thread. I'm not sure why you need the XML and why you can't use properties.
|
|
|
|
|
Well, i'm trying to route all events through a single root object, only wiring up a hierachy of observable lists, trees and properties to do that will be an absolute nightmare as the model is growing almost daily.
Additionally, i need to be able to run XPath queries on any part of the model and define some kind of schema to validate against. Which i couldn't do with objects.
It's a desktop app if that makes any difference, and the XML would be the state of the solution and everything pretty much revolves around changing that and keeping display parts synchronized with it.
Not sure how to describe it beyond that.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
Short of hashing the different observable portions and then periodically checking to see if the hash has changed, tricky. Although if you implemented this with MVC, then it would be less tricky.
|
|
|
|
|
Pete O'Hanlon wrote: INotifyPropertyChanged
That appears to be new in 3.5, yes? I haven't been there yet.
led mike
|
|
|
|
|
It's been around since 2.0.
-------------------------------
Carrier Bags - 21st Century Tumbleweed.
|
|
|
|
|
led mike wrote: That appears to be new in 3.5, yes?
.NET 2.0. I've used it to manage Dirty states in classes - it's rather neat.
|
|
|
|
|
I still can't find the 2.0 Reference to this puppy?[^]
System.ComponentModel.INotifyPropertyChanged<br />
Finally! Geez, apparently I have been implementing the IAmAnIdiot interface Last modified: 45mins after originally posted --
led mike
|
|
|
|
|
led mike wrote: Geez, apparently I have been implementing the IAmAnIdiot interface
No fair. I copyrighted that one.
|
|
|
|
|
hii,
pls send uml diagrams for unicode optical unicode character recognition using artifical neural network.its very urgent,pls send
as soon as possible
|
|
|
|
|
|
WOW !!!!
All the good keywords are here :
PLS
SEND
VERY
URGENT
AS SOON AS POSSIBLE
Yeah Right...
|
|
|
|
|
pls send uml diagrams as early as possible
|
|
|
|
|
Tell me/us why would someone do your work for free for you ?
|
|
|
|
|
Why?
Are you too lazy, or too stupid to do them yourself?
Paul Marfleet
"No, his mind is not for rent
To any God or government"
Tom Sawyer - Rush
|
|
|
|
|
pmarfleet wrote: Are you too lazy, or too stupid to do them yourself?
That's a given. He was too lazy and stupid to get the responses when he first posted this. He needs an IQ upgrade just to reach single digit figures.
|
|
|
|
|
This thread is so awesome it almost deserves to be stickied.
I mean... How to sticky thread in XML and Web2.0 using AI? Plz send codes as soon as possible? URGENT!!!!
|
|
|
|
|
Mark Churchill wrote: How to sticky thread in XML and Web2.0 using AI? Plz send codes as soon as possible? URGENT!!!!
|
|
|
|
|
OK, I am going to say it again...
Nice
Second
Message
Get a clue... this site does not exist to do work for people. It exists to help.
Big difference.
|
|
|
|
|
Hi All,
I am trying to develop desktop sharing application like VNC .
In VNC there is use of hooks to capture changes. I want to know that is there any way to get screen updates other than hooks?
Thanks,
Ravi.
|
|
|
|
|
We have the standard Production, QA and Dev environments on our web site. We use them for the obvious purposes. What we want is to use Team Foundation Server to do source control.
I just started here and I have been tasked with figuring out how to do this correctly. Currently, we have three different projects in the source control, which represent each of the environments. I do not think this is correct. I have read a lot of literature about this and nothing seems to make sense. We do not publish the entire application to the web servers, instead we put up individual pages when they are changed. We need to support the following standard things:
1. Ability to know what is in the three environments at any given time
2. Ability to roll back to previous (tested and correct) versions of the web site in any environment
3. Ability to know what changes are tested and verified in QA and Dev, so we can promote code
4. We need to ensure that changes are not made in production until they are tested in the QA environment.
5. We need to sync the source control with the versions on the servers, so that developers will be able to pull a copy of the 'server version' from source control directly. Right now, to do that, you have to pull the source control version and then update the files from the web server... which is stupid because they should always be the same.
Standard stuff... I think?
I have read so many articles about this it's making my head spin. Certainly this is not hard enough to justify 500-page documents???
http://www.codeplex.com/TFSGuide/Release/ProjectReleases.aspx?ReleaseId=6280[^]
What is the simple way to do this? My proposal is to eliminate two of the current project repositories, and only have one, which we would make a branch from, do development on the branch, and then merge the development back into the main branch when it's done, apply a label to the result after the merge, and promote that label to production when it has been tested in QA... but I think I'm missing something with that.
I want this to be simple, or nobody will do it. We want to avoid making changes directly in production. We should be able to eliminate all temptation to do that. People requesting changes will just have to deal with the new policy of reviewing the changes in QA before they are put to production.
|
|
|
|
|
I think you are getting it a bit backwards. Generally you do the bulk of your development on the trunk.
If you have a smaller project then you can just take a release, version it and push that thru QA and release.
On a larger project you might choose to branch off a release, and only apply "serious" fixes to the current release branch (still doing QA on the fixes), merging that back into the trunk.
Having multiple source control systems is just going to lead to disaster.
|
|
|
|