Tjena! Ponera att man har ett komplext formulär med textboxar, ett par listviews, grid, och lite annat smått och gott som allt relaterar till ett "PersonItem" som finns i en lista av "PersonList". Skapa ett typat dataset som håller din data, gör sedan dina kontroller databundna och använd sedan en bindingmanager för att hålla koll på din data Daniel: Tack för input! Funkar jättebra när det är funktionsbaserad programmering.. Allt befinner sig i objekt här dock så då kan jag inte använda dataset eller adapter =( du måste implementera ibindinglist på dina listor och ieditebleobject på dina objekt. Menar du det? DET måste jag testa. Tack för input ! Hej Robin, det blir INTE "funktionsorienterat" bara för att man använder ett Dataset.. Men det är lättare att det blir funktionsorienterat med datasets.. Ilis >> Men det är lättare att det blir funktionsorienterat med datasets.. Det första är ju redan löst med att objekten har ju sina .HasChanges egenskaper så det kollar man innan man itererar till nästa post. Då frågar man om man vill spara förändringar eller förkasta dem, och det funkar smidigt. >>Däremot vill jag absolut avråda från Databinding, det kostar mer huvudvärk än vad det smakar gott..Arkitekturfråga - när ett formulär förändras
Vid förändring av något av kontrollerna tillhörande PersonItem så sätter jag en flagga, en booleansk PersonChanged variabel. Sedan när man itererar till annan person i denna lista av personer, så utför jag en koll på PersonChanged. Om något är förändrat så stoppas iterering och frågar om man vill uppdatera nuvarande PersonObjekt till databasen först, eller förlora förändringar.
Det jobbiga sättet jag gör detta nu på är en event som tar hand om alla textboxar.TextChanged som finns, och andra event för andra objekt. Det blir alltså en himla massa events, som körs hela tiden. Kan man göra detta på något smartare sätt ? det bör ju vara en tämligen vanlig syssla detta..
Exempel hur det ser ut idag:
<code>
Private Sub btnForward_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnForward.Click
If Me._PersonChanged Then
MsgBox("Spara först!")
Exit Sub
End If
Me.Cursor = Cursors.WaitCursor
Me.intCurrentPersonIndex += 1
Me.fnUpdate_PrevNextButtons()
Me.fnLoadCurrentPerson()
Me.Cursor = Cursors.Default
End Sub
Private Sub PersonChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles txtAdress.TextChanged, txtCO.TextChanged, txtEfterNamn.TextChanged, txtEfterNamn.TextChanged, txtEpost.TextChanged, txtFornamn.TextChanged, txtMobil.TextChanged, txtOrt.TextChanged, txtPnr.TextChanged, txtPostnr.TextChanged, txtTfn.TextChanged, rtAnteckningar.TextChanged
Me._PersonChanged = True
End Sub
'och andra events för andra typer av kontroller...
</code>Sv: Arkitekturfråga - när ett formulär förändras
Läsa, uppdatera data mot databasen gör du med en dataadapter
Lycka tillSv:Arkitekturfråga - när ett formulär förändras
Sv: Arkitekturfråga - när ett formulär förändras
då kommer det funka precis som med datasetsSv:Arkitekturfråga - när ett formulär förändras
Sv:Arkitekturfråga - när ett formulär förändras
Sent svar men kanske kan vara till nytta. Att implementer samtliga interface som behövs för att databinding skall fungera kan vara ganska jobbigt.
Kika på Objectviews, http://sourceforge.net/projects/objectviews/
(Jag tror du får plocka den koden som ligger på cvs'en för att du skall få den senaste versionen)
Har inte själv använt det men det verkar ganska intressant.
Här är en liten forumtråd som också kan vara intressant, http://nhibernate.sourceforge.net/forum/viewtopic.php?t=504&start=15Sv: Arkitekturfråga - när ett formulär förändras
Dataset är objekt, och det är ett utmärkt objektorienterat sätt att hantera data på.
Däremot vill jag absolut avråda från Databinding, det kostar mer huvudvärk än vad det smakar gott..
/OlaSv:Arkitekturfråga - när ett formulär förändras
Håller med om att Dataset kan skapa huvudvärk vid data-bindning. Och att programmera/systemera
objektorienterat och samtidigt använda datasets för annat än ett enkelt sätt att lagra temporär data tror
jag krånglar till det hela.
Som svar på frågan så brukar jag låta objektet ta hand om kontrollen om det är ändrat. Alltså stoppar
man in alla värden från formuläret till t.ex. person-objektet. Sedan kan man fråga objektet om det har
ändringar mot sina orginalvärden, typ Person.HasChanges().
Mvh
PeterSv: Arkitekturfråga - när ett formulär förändras
Eeeh? Det är "alltid lättare" att det bli funktionsorienterat om man inte tänker efter före... :)Sv:Arkitekturfråga - när ett formulär förändras
Det andra är mer en UI fråga, såfort en textbox eller något ändras på detta personformulär vill man ju aktivera "Update" knappen (man vill se att personen har förändrats och förstå att man bör uppdatera den)
Idag så använder jag en funktion som tar hand om alla TextChanged() event och aktiverar den knappen. Och när man tryckt update så gråas den ut igen tills något har förändrats
Är detta rätt väg att gå ?
ex: Function activateUpdateBtn() handles txtName.changed, txtPhone.changed etc etc etc..Sv:Arkitekturfråga - när ett formulär förändras
på vilket sätt menar du att databindning i winforms är besvärligt?