kakoisključitiinicijalizaciju DataSet kreiranog u dizajn režimu?

Imam problem da ukapiram kako Visual Studio radi sa bazama u dizajn režimu. Navikao sam an Delphi pristup koji mi izgleda mnogo logičniji pa sa ovim ne mogu da se snađem.

Do sada sam u .NET radio sa bazom tako što bih ručno kreirao konekciju, dataset i sve ostalo i povezivao šta mi je gde trebalo. To pije vodu za neke jednostavne stvari ali čim se stvari malo uslože, to postaje ozbiljno ograničenje.

Odlučio sam da probam da radim preko Dizajnera, jer tada mogu da iskoristim sve pogodnosti dizajn režima za podešavanej izgleda koriničkog interfejsa. Ok, to radi koliko-toliko pristojno.

Međutim, sada imam dva problema koji se u stari svode najedan.

Naime, kada kreiram DataSet udizajn režimu, u njegovom kodu budu zakucani parametri za konekciju na bazu. To je ok ako istoj bazi koju korsitim u dizajn režimu i u runtima, li meni je potrebno da se prilikom pokretanja prograam može izabrati baza i konekciaj izvršiti ka njoj a ne premaonoj koja je korišćenja u razvoju programa. U Delpi+ju je to bilo vrlo prosto, samo se isključi konekcija ka bazi u dizajn režimu i prilikom inicijalizaicje podesi po željii uključi.

Drugi problem je što ako program ima više formi, u dizajn režimu se kreira DataSet za svaku formu posebno. Meni treba da kreiram jedan DataSet koji iniciram na početku programa, a koji će koristiti sve forme.

Jedino rešenje koje vidim to je da na inicijalizaciji programa kreiram DataSet, a zatim prebijem sve ostale DataSet-ove im jednim gde je to potrebno. To će da radi ali imam problem što i dalje sviDataSet-ovi kreirani u dizajn tajmu ostaju živi i pokušavaju da se povežu na bazu pre nego što ih ja ubijem.

Kako se ovo u stvari rešava u .NET okruženju?

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Iako izgleda tako dataset ne nosi konekciju (on je disconnected storage). ONo sto ti VS uradi implicitno je da kreira tableadapter-e koji sluze za filovanje dataseta. U njima iz dizajnera mozes da prebacis ConnectionModifier na public i onda ti je connection string vidljiv spolja i moze da se menja dinamicki.

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Nisam te baš najbolje razumeo ali probaću da istražim na tu stranu.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Kad pogledas tabelu ispod nje je njen tableadapter:



kliknes na header tog adaptera i u properties imas ConnectionModifier koji je po defaultu internal, prebaci ga na public

sad kad punis dataset koristis sledeci princip:

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Kao bivši Delphi programer mogu da ti kažem par (ključnih) stvari u vezi sa prelaskom na .Net:

1. Ne postoji .Net ekvivalent DataModule-u. U Delphiju DataModule je tipično bio živ dok je živa aplikacija (instance mode) i držao je manje-više celu logiku, dok u .Net-u radiš sa dinamičkim instanciranjem DataSet-ova kad ti koji zatreba i posle uništavaš iste. Ovo važi i za sve ostalo (npr. forme). Nije kao da *moraš* tako da radiš (i dalje možeš da čuvaš singleton reference i koristiš ih u celoj aplikaciji) ali te ceo framework nekako "vuče" na tu stranu, što veruj vremenom proizvodi bolji kod . Delphi je uvek propagirao instance-binding u dizajneru (sam ti napravi za svaku klasu, npr. TForm1, odmah i automatsku instancu Form1), dok .Net dizajner skoro da nema pojma šta je to instanca, on dizajnira klasu.

2. U .Net-u imaš DataSetove koji su ništa drugo nego object-model data-modela. Sa DataSet-ovima radiš po use-case načinu (hvala mmix!), tj. imaćeš jedan DataSet za svaku logičku celinu. Na primer, ako je operacija Login tj. prijava korisnika napravićeš Dataset koji sadrži tabelu Korisnici, tabelu History, relacije među njima i stored proceduru za Login. Kad dođe do Logina dinamički kreiraš taj npr. Datasets.LoginDataset, uradiš Login i Dispose-uješ Dataset jer ti nikada više neće trebati u lifecycle-u aplikacije.

3. Što se connection-a tiče o njima ne treba da brineš. Datasetovi sami kreiraju konekciju kada im zatreba (seti se instance-mode vs class-mode ) na osnovu parametara. Parametri su tipično u config fajlu. Kad kreiraš Dataset u dizajneru on te pita za Connection parametre zatim ti ponudi da te parametre snimi u App.Config, koji se propagira u run-time. Kad posle menjaš app.config menjaš i parametre za konekciju. Tipično kad instaliraš program kod klijenta menjaš app.config da pokazuje na njegovu bazu ili server.

Potpis

if it walks like a duck and quacks like a duck, it could be a dragon doing a duck
impersonation.

Potražio sam i na netu inforamcije o ConnectionModifier i u suštini je to je jedna od stvari koja mi treba. Medjutim, nije mi bas jasno sta dobijam ako to koristim i tako postavim svoju konekciju, ako u svakom slucaju konekcija koja je napravljena u dizajneru biva inicijalizovana. Moja konekcija može da je zameni ali neće sprečiti da se ta dizajner konekcija uspostavi. koliko sam video, skoro sve diskusije na netu kje su vezane za ConnectionModifier se upravo svode na očajničke pokušaje da se dobije upravo ovo što i meni treba - što me ne čudi jer je to sasvim normalan i očekivan zahtev. To bi trebalo da radi ovako kako se traži a ne da moramo da se maltretiramo.

DataAdaperi koje je definisao dizajner se svakako incijalizuju prilikom otvaranja forme i ja na to ne mogu da utičem osim da uđem u kod Dizajnera forme i ručno izbacim kod koji ih inicijalizuje a to nije ispravan način da se radi.

no da to i rešim, i dalje imam sutinski problem što se sve inicijalizauje u formi. Meni je potrebno da bude incijalizovano n anivou cele aplikacije. Ne želim da svaki put kada se ue u formu bude kreiran DataSet, učitavani podaci iz baze u DataTable, kreirani dataAdapteri i BindingDataSource. To em je nepotrebno traćenje resursa i usporenje rada programa, em mi uskraćuje potrebnu funkcionalnost - da različite forme dele iste žive podatke uključujući i njihove trenutne statuse.



Znam da .Net nema analogiju za Dephi-jev DataModule. Možda jepotrebno da još nešto pročitam da bihuspeo da ukapira logiku koja stoji iza ADO.NET, ali trenutno ja u njemu ne vidim mnogo logike. Previše tu stvari ima koje moraju da se rade na mučan način, pešački, pa čak i mora da se na neki način "prevari" sistem da bi radio neke stvari koje su očigledno i svakodnevno neophodne. Meni ADO.NET deluje zapanjujuće primitivno.



Ne razumem baš kako može biti bolji kod koji pravi nepotrebnu redundansu ne samo kreiranjem dupliranih objekata nego i duplim učitavanjem jednih te istih podataka za svaku formu. Jedini način koji vidim da može da se izbegne to nepotrebno traženje resursa je da ručno sve kreiram i povezujem u kodu. To mi je, opet, neprihvatljivo u radnom okruženju u 21. veku. Praviti korisnički interfejs peške umesto u dizajneru je možda prihvatljivo za ASP.NET ali za razvoj desktop aplikacije, potpuno je besmisleno da sve mora da se radi ručno i peške da bi se dobio kvalitetan kod.



Meni treba upravo suprotna stvar. Da na početku inicijalizujem jedan DataSet i taj jedan te isti DataSet koristim sve vreme dok se aplikacija ne zatvori. ne vidim logiku da za svaku formu taj DataSet pravim nanovo, ne smao sa aspekta traćenja resursa, nego i zato što mi je potrebno da statusi u DataSetu budu vidljivi svim formama. Ne mislim samo na DataSet klasu, nego na sve što napravi DataSet Designer, pa i na BindingSource koji su vezani na tabele.



Ali ja ne želim da oni prave konekcije kad im zatreba nego da im ja napravim konekciju ada tu jednu koriste. Konekciju pravim u letu, na osnovu podataka koji su mi u tom trenutku dati. Ne treba mi da to čuvam u konfig datoteci koju će program da učitava. Na kraju krajeva, kada radiš u Compact okruženju, App.Config se čak i ne koristi - pretpostavljam da nije ni podržan.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Za svoje specificne potrebe koje se ne poklapaju sa ustaljenim nacinom rada je mozda najbolje da napravis klasu sa statickim property-em ili singleton (sto mu dodje na isto) i u njega smestis dataset i onda mozes pristupiti odakle hoces.
Inace, mogu reci da neke od stvari deluju konfuzno u tvom postu. Npr. kakve veze dataset ima sa pravljenjem korisnickog interface-a? Ako u kodu radis sa dataset-om, to nije pravljenje GUI-a u kodu...

Potpis

Nebojsa Milanovic:
-Trumpa smatram vrhunskim predsednikom i voleo bih da živim u državi na čijem je on čelu
-Rusija ne laže, ne vodi osvajačke ratove
-Trump je svetla tačka u USA blatu
-Elon Musk, možda najpametniji i najtrezveniji Amerikanac

Tako sam i radio do sada, i to je ok za neke sitne poslove.

Međutim kada se radi nešto krupnije, neprihvatljivo je da se sve radi u kodu, a najpre da se podešava korisnički interfejs. Za to je potreban dizajner. On definiše DataSet klasu na osnovu baze koja mu se da, instancira je, ucita žive podatke i onda to koristi da bi automatski popunjavao gomile propertija koji povezuju elemente korisničkog interfejsa i bazu kao i da bi omogućio podešavanje svih tih propertija i drugih elemenata grafičkog interfejsa. programer tu dobija u komforu jer vidi šta radi - ne samo kako korsinički interfejs izgleda nego vidi i učitane podatke u njemu.

Problem se javlja jer dizajner insistira da svaka forma ima svoj DataSet objekat i to baš na osnovuklase koju je kreirao a ne omogućava da se programski na to utiče. Tako,kada se pokreneprogram on se poveže na istu bazu koja je korišćena za dizajniranje, a po pravilu za dizajniranje se koristi testna baza a u stvarnom radu se treba povezati na neku drugu bazu.

U Delphi-ju je to jednostavno rešeno. U Dizajneru se pravi DataModul koji predstavlja nešto slično DataSet-u i ADO.NET (mada je DataSet primitivniji), s tim da Delphi i instancira sve database objekte u DataModulu i korsiti ih kako u dizajn režimu tako i u runtime. Programer ima mogućnost da u procesu instanciranja DataModulapristup njegovim proertijima i izmeni sve što mu je potrebno, uključujuči i parametre konekcije. Navikavši na taj komfor mučim se jer ADO.NET insistira na insanciranju objekata na svoj način ne dozvoljavajući programeru da taj proces kontroliše.

Jasno mi je da je u ADO.NET ovo problem jer su database objekti raštrkani. DataSet sadrži tabele i vezemeđu njima, ali su DataAdapteri, BindogSources i drugiobjekti poptuno nezavisni. U takvim uslovam zaistaje teško omogućiti jasnu i jednotavnu kontrolu. Da ADO.NET iam nešto kao što je Dephi-jev DataModul problem bi bio rešen, jer bi DataModul sadržavao sve i preko njega bi se sve lako moglo kontrolisati.

Ovako, kada u .NET kreiraš formu, moraš da instaniraš DataSet, pa onda sve pripadajuće DataAdaptere za tabele, pa Binding Source za tabele gde je potrebno da se radi navigacija po slogovima, pa čak i na zatvaranju tabele moraš da radiš update nad Tabelema da sačuvaš izmene. I tako za svaku formu posebno. E sad,kada je potrebno da se forsira koenkcija kroz program, u sve to na inicijalizaciji forme treba svakom DataAdapteru ponaosob promeniti konekciju, opet na svakoj formu.

U Delphiju to nije potrebno, jer svaka forma vidi jedan te isti DataModul koji je istanciran na početku i svu funkcionalnost ima obezbeđenu kroz njega. Na formi samo treba povezati elemente korisničkog interfejsa sa odgovarajućim elementima baze podataka.

----

mmix, probao sam ovo što si predložio. To radi, ali i dalje aplikacija prvo pokušava da se zakači na testnu bazu, a na onu koju mu zadam programski se zakači tek na inicijalizaciji forme.

Čini mi se, da bi se ovo popravilo neophodno je da se menja sam Dizajner jer su neophodne izmene u kodu koji on generiše. Pretpostavljam da je to izvodljivo, ali to je posao za nekog ko je ekspert za Visual Studio.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Ok, za pocetak savet, zaboravi Delphi. Nije bolji, samo drugaciji. AKo hoces da radis .NET onda moras da prihvatis i neke promene paradigmi koje su u medjuvremenu nastupile. Ja iskreno nikad nisam voleo te monstruozne Delphieve datamodule sa milion nacickanih ikonica koje zive tokom cele aplikacije i jos drze aktivne konekcije na bazi i ko zna kakve lockove, to se vrlo lako otme kontroli. Ako nista, .NET te je bar doveo u poziciju da se namucis ako hoces da ske*jas bazu :) Ako se boris protiv vetrenjaca napravices los program, umesto toga promeni filozofiju dizajniranja svoje aplikacije i preorijentisi se na use-case filozofiju i tako dizajniraj svoje aplikacije, bice ti mnogo lakse a i imaces zaokruzenije forme i modele lakse za odrzavanje.



Ja pretposvaljam sta si ti uradio, drag&drop svog typed dataseta iz toolboxa, d&d bindingsource-a, povezao binding source na dataset i onda ti je on napravio instancu table adaptera na formi. POgledaj sors forme i nacices event handler nalik na ovaj:



pre Fill-a promeni konekciju.

Pokusacu da ti odgovorim na neke tvoje zabrinutosti (izvini ako nesto rpeskocim)

1. Statusi. Nista tebe ne sprecava da imas data cache, cak postoje posebna podrska za kesiranje podataka. Kad instanciras svoj dataset merguj statuse iz kesa i sacuvao si jedan SQL query.
2. All RAD. Nema nista od toga, ako si zbog toga dosao na .NET neces se mnogo leba najesti. KOriscenje dizajnera ce te dovesti samo donekle i folzoifija koju oni koriste za full RAD je u najmanju ruku veoma zatucana, pravolinijska i rigidna sto ocigledno i sam vidis. Za bilo sta drugo moraces da zasuces rukave i iskucas bar po koju liniju koda.
2a. Onaj kod gore mozes potpuno da izbacis i da preuzmes kontrolu nad tim kako se dataset popunjava, a da na formi zadrzis tipizirani dataset koji preko bindingsource-a pruza metadata informacije kontrolama. Tako se uglavnom radi
3. Velike aplikacije. Itekako moze u .NETu, samo ne kako si ti naumio (tj moze ali je to nocna mora za odrzavanje)
4. app.config je podrzan svuda gde ima .NETa. Sam tableadapter cuva svoju konekciju u app.configu
5. pokusacu da ti nadjem link na diskusiju koju mo imali o datasetovima, organizaciji podataka i slicno (borise ako imas pri ruci okaci), mozda ti to pomogne
6. nemoj mnogo da brigas o rasipanju resursa ako nije u pitanju sam SQL upit. Interno pretabavanje i kreiranje objekata je kao dobar dan, sam frameowrk ih kreira i unistava u obimu od par hiljada po sekundi cak i kad tvoja aplikacija idle-uje. GC vodi racuna o tome. Nisu 90e, kompjuterima se memorija meri gigabajtima, nema potrebe da budes ludit i da optimizujes O(1) operacije. To dal ces ti za dve forme da kreiras jedan glavni umesto dva dataset-a je stvano teranje maka na konac sa kojim neces postici nikakve vidljive prednosti a sebi pravis problem.

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

mmix, radim za Compact platformu i veruj mi na rec, tu itekako mora da se pazi na resurse. Tu se lako vidi da grabage collection ne radi bas tako kako ga reklamiraju.

Delphi mi je reper, jer je to platforma koja se dokazala kao dobra. To naravno ne znači da očekujem da .NET radi kao Delphi, ali neki principi su univerzalni i ne bi trebalo da budu problem.

Eto na, primer, ova promena konekcije u runtime, to je ocigledno skrljano u .NET jer mi je nepojmljivo da je to toliki problem a radi se o stvari koja je neophodna u praktično svakoj aplikaciji koja radi sa udaljenom bazom.

Konekciju sam uspeo da uvalim, slično kao što si ti i opisao i to radi, ali i dalje apliakcija prvo inicijalizuje konekciju definisanu u dizajneru a tek nakon toga je ja zamenim svojom. Pošto radim sa SQLLite bazom koja senalazi uz exe, to niej problem, pošto to učitavanje nepostojeće baze traje kratko i bez prijavljivanja greške pa se ne primeti. Ali šta da se povezuem na udaljenu SQL bazu, pa moram prvo da čekam timeout nepostojeće baze pa tek onda da uspostavljam konekciju sa onom na koju apliakcija stvarno treba da se poveže?

Na to se nadovezuje da je neophodno da svakom DataAdapteru zasebno moram da uvaljujem drugu konekciju. Kako to može biti dobra filozofija? Kako može da bude dobra filozofija da se jedan isti posao, koji je rutinski, mora nanovo kodirati na više mesta, umesto da se to sve lepo uradi na jednom mestu i koristi u celoj aplikaciji?

S druge strane, na Compact platformi, ucitavanje tabele od jedno desetak ili dvadeset hiljada slogova traje i to primetno, a ideja da to mora da se radi svaki put kada se otvara neka forma kojoj ta tabela treba mi je zaista neprihvatljiva. Ja želim da te podatke ucitam jednom i koristim tokom rada cele aplikacije. Ne vidim sta je pogrešpno u toj "filozofiji".

To sam uradio ručno pišući kod ali sam zbog toga morao ama baš sve da radim ručno, što mi je, opet, nepojmljivo da mora da se radi u 21. veku. Zato sada i nastojim da iskoristim dizajner da sebi dam malo komfora u radu. Pravljenje grafičkog interfejsa kroz kod je zaista naporno,a da ne pričamo kako izgleda ručno inicijalizovanje data objekata.... Delphi pominjem upravo u tom kontekstu - koliko je rad komforniji i koliko on pomaže programeru umesto da ga sputava.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Nista nije pogresno. Da bi to postigao, potrebno ti je 4 linije koda



I u formi gde ti je dataset u page load stavis MyDataSets.MyDataSet = DataSetIzForme;
Na dalje pristupas preko te staticke promenljive.
Isti princip mozes da primenis i za ostale.

Mozda ima neka sitna greska (bitan je princip), jer nisam radio sa dataset-ovima kreiranim u designer-u, brzo sam preskocio na linq2sql a sa dataset-ovima sa kojima trenutno radim radim iz koda iz nekih sasvim drugih razloga.

Edit (za one kojima stize na mail): ne znam zasto sam napisao kod u vb.net-u...

Potpis

Nebojsa Milanovic:
-Trumpa smatram vrhunskim predsednikom i voleo bih da živim u državi na čijem je on čelu
-Rusija ne laže, ne vodi osvajačke ratove
-Trump je svetla tačka u USA blatu
-Elon Musk, možda najpametniji i najtrezveniji Amerikanac

To sam probao, ali mi nije radilo. Forma je videla samo DataSet koji je stavljen na nju i DataSet koji je dizajenr kreirao.

DataSet na drugim formama ili u nekoj drugoj klasi koju sam napravio (sve u istom namespace) nije videla. Probacu to jos za slucaj da sam nesto pogresno radio, jer je to resenje koje mi sasvim odgovara.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

To je zbog toga sto si zamenio instancu u referenci dataset11 (npr) ali je dizajner vec bindovao bindingsource na staru vrednost. To je ono sto sam ti rekao sa "ogranicenoscu" RAD razvoja, ti mozes da iskoristis formin dataset da bindujes iz dijzanera ali ako hoces da koristis eksterni (u ondosu na formu) dataset onda moras da

- izbacis datadapter sa forme (ovo ne sprecava binding source da preuzme metadata iz dataseta)
- preuzmes kontrolu nad ucitavanjem podataka (taj tvoj centralni dataset koji mozes recimo da strpas u signleton i kreiras pri prvom pristupu)
- sve bindingsource komponente koje se povezuju na dataset u inicijlaizaciji forme prebacis na tvoj dataset (npr bindingSource1.DataSrouce = mojDataSingleton.glavniDataSet;)

tako neces imati inicijalnu inicijalizaciju konekcije u formi ( posto je to deo datadaptera koji si izbacio) a forma ce vuci podatke iz centrlanog dataseta. Binding source je i predvidjen za ovakve scenarije, ako promenis DAtaSrource na novi izvor a taj novi izvor imas istu shemu kao zamenjeni onda ce binding source i sve vizuelne komponente koje vuku preko njega jhednostavno prebaciti prikaz na novi source bez ikakvih problema.


i nije skrljano nego ti jednostavno imas prevelika ocekivanja od RAD alatke. MOras da napravis deo u kodu.

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Ok, spremio sam ti mali quick-fix sample da vidis

podtrazi |"* PEDJA *" u kometnarima za dve stvari koje omogucavaju ceo princip

dizajn sm obavio sa praznom Pocetna.sdf bazom a program vuce podatke iz Kranja.sdf koja ima istu shemu ali i podatke.

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Jasno mi je to sve. Upravo tako sam i pokušao da uradim, doduše ne sa singletone nego sa obišnom klasom, a mislim da to i nije tako bitno. Singleton je bolji izbor jer obezbedjuje samo jednu instancu, što mi i treba.

Problem je što u dizajneru forme, ako uklonim DataSet ili BindingSource koji su automatski stavljeni kada samo grid zakacio na tabelu u dizajniranom DataSet-u, sva podešavanja na kolonama u gridu se obrišu. Čak i ako izmenim neke propertije na kolonama, dakle imam custom podešavanja, svejedno sve bude izgubljeno. Time gubim upravo ono zbog čega i koristim dizajner.

Kako sam te razumeo ti kažeš da treba da uklonim samo DataAdapter, jer ću koristiti svoj a da DataSet i DataBindingSource ostaju na formi. I to sam probao i tada grid zadržava podešavanja ali je i dalje vezan na lokalni BindingSource, a meni treba veza na BindingSource koji sam ja napravio kao globalni za tu tabelu.

Pošto u tvom primeru ne mogu da otvorim formu u dizajneru (VS prijavljuje grešku), ne mogu da vidim kako si je podesio. Međutim u Form1.Designer.cs u InitializeComponent() vidim liniju:

this.mojDataSet1 = new PedjaSample.Data.MojDataSet();

Kako si ovo izveo? To je deo koda koji je dizajner generisao, dakle nekako si uspeo da ga nateraš da dizajner vidi tvoju DataSet klasu i poveže se na nju? To je upravo ono što ja želim da izvedem ali mi ne uspeva.

Još mi je važnije da mogu DataGrid da zakačim na svoj BindingSource u dizajneru jer bi tako ostala sačuvana sva podešavanja na kolonama.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

Znam šta ti smeta, Delphi je imao TTable i TQuery koji je predstavljao objektni model tabele ili upita, i tamo si mogao za svaki Field da definišeš širinu, caption, itd. Kada taj TTable povežeš sa Grid kontrolom ona preuzme podešavanja kolona iz TTable-a. Činjenica je da su ta svojstva deo "presentation" dela aplikacije i da nemaju šta da traze u delu aplikacije koji se bavi podacima. Taj coupling prezentacijske i storage logike mi je smetao cak i kad sam radio u Delphiju, i iako na prvi pogled olakšava stvari u stvari te ograničava.

U .Netu sve kolone i njihova svojstva su snimljena (serijalizovana) zajedno sa gridom. Kolone i property-i nisu ni u DataTable-u ni u BindingSource-u. Svakako možeš da napraviš svoju klasu-metod koja će za zadati grid da generiše kolone i property-je ali to moraš da uradiš IZ KODA. Najlakše je da podesiš grid vizuelno u dizajneru i onda copy/paste-aš linije koda iz InitializeComponents.

Link koji je mmix pominjao je ovde, dosta je rečeno na temu Delphi ADO vs .Net ADO (ah kako sam bio mlad i glup, prosto me sramota ), obrati pažnju na poslednji post.

Potpis

if it walks like a duck and quacks like a duck, it could be a dragon doing a duck
impersonation.

Pa parciojalno si u pravu, ali pored toga sto grid cuva svoj layout, svakio iole pristojan grid moze da dinamicki generise kontrole na osnovu izvora, bilo runtime, bilo kao inicijalno podesavanje grida (sto je pretpostavljam ono sto Pedja hoce).

Pedja pazi ovako, cisto da neke zabune izbegnemo

DataSet je detached (otkacen od izvora) multi-table multi-row memorijski storage za podatke. Ako je tipiziran nosi runtime informacije o svojoj semi (ovo je vazno za tebe)

Da bi neka kontrola mogla da prikaze podatak iz dataseta mora da postoji komponenta koja ce da mu doda nedostajuce funkcije (iteraciju, pamcenje pozicije, itd). Tu funkciju obavlja BindingSource. Binding source pored toga ima i dosta drugih uloga koje tebi za ovo nisu vazne, ali jedna od stvari koje ti mogu biti korisne je da binding source moze da konzumira sijaset razlzlicitih vrsta izvora podataka (od kojih je dataset samo jedna) i da prema kontrolama prikaze te izvore na unfiorman nacin. Grid (ili bilo koja druga kontrola) moze da iskoristi binding source da runtime ili design time otkrije shemu izvora podataka. Dakle za ono sto ti hoces minimum (a i maksimum) je neophodno da na formi postoji dataset i bindingsource i da su povezani, sve ostalo je visak.

Dataadapter je uprosceno kombinacija vise TQuery objekata za razlicite CRUD operacije plus za sve custom oepracije koje defines. Sam VS i pomaze tako sto za dataset koji prevuces iz baze sam generise kod za tipizirani dataadapter u kojem automatski generise sve CRUD query-e i mapiranja izmedju kolona Sql(Ce)Command-a i dataset table polja. pored toga ima jos funkcija (npr asinhrone metode, tako da korisnici ne cekaju blokirani da se izvrsi dugacak query)

Object lifetime, ovo je za bivse delphi programere najvaznije da svare. Komponenta koju si stavio na formu nije isto kao objekat koji se nalazi u njenoj referenci. Zvuci zbunjujuce pa cu probati da malo objasnim.

- recimo bacio si dataset i bindingsource na formu i povezao (dataadapter koji ti je designer onda napravio si obrisao, ne treba nam)
- VS designer to serijalizuje kao seriju instrukcija u form.designer.cs fajlu, nesto nalik ( pogledaj i sam)



taj kod se izvrsava u visual studiu tokom dizajniranja forme (sto ti omogucava da u gridu design time vidis polja) i izvrsava se u runtime u InitializeComponentes() kroz form_init. U tom trenutku se u dataset1 varijabli nalazi dataset (nazovimo ga ds000) u bindingsource1 se nalazi bs000 i bindingsource1 .DataSource == instance(ds000)

Ako ti sada posle init uradis dataset1 = mojSingletonDataSet; sta se desava?
dataset1 == mojSingletonDataSet ALI
bindingsource1 .DataSource == instance(ds000)

dakle ti si promenio dataset1 referencu ali su SVI bindingsources VEC povezani na ds000 i zato ti ne vidis rezultat. Samim tim sto si promenio referencu dataset1 NE ZNACI da je ds000 nestao, on i dalje zivi kroz bindingsource1.DataSource i uredno servira svoje podatke kontrolama zakacenim na binding source. Da bi postigao ono sto hoces moras u runtime-u potpuno da izignorises dataset1 (on je odradio svoje, pomogao ti je u designu da namestis grid) i direktno upucas novi dataset u binding source:

bindingsource1 .DataSource = mojSingletonDataSet;

bindingsource ima event koji puca kad se promeni DataSource, gridovi SVI ako icemu valjaju kace se na taj event i bivaju obavesteni da je izvor promenjen i odmah rade reload/repaint.

Sve to imas u onom solutionu sto sam ti okacio u prethodnoj poruci. Jesi pogledao to?

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Sve to znam i nema taj problem. Stvar je što ja pored DataSet-a kreiram i BindingSource za svaku tabelu u DataSet-u. Tako je meni BindingSource na formi nepotreban jer vec imam to napravljeno u runtime pa taj svoj BindingSource povezujem sa gridom. Zato meni nije toliko bitno da imam DataSet na formi, jer mi na formi DataSet i ne treba - u runtime kreiram DataSource i njega koristim, a preko njega postoji i veza sa mojim DataSetom.

Uklanjanjem generisanog DataAdaptera sa forme rešen je problem sa dizajn knekcijom. E sad, na formi mi ostaju kao višak DataSet i BindingSource komponente, ali za toliko se da tolerisati.

Potpis

http://pedja.supurovic.net - http://wireless.uzice.net - Besplatni .RS domeni - Mikrotik uputstva - YT9TP - OpenStreetMap Srbija

A iz kog razloga dinamicki generises binding sources?

Manje vise kad imas samo jedan grid ali ako imas vise kontrola (npr grid + details) onda bi morao svakoj kontroli da promenis biding source umesto da vec imas bindingsource na formi da samo njemu upucas novi dataset.

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Pa pretpostavljam da je mislio na ColumnWidth, ColumnCaption, ColumnAlignment, Visible, itd., što se ni u kom slučaju ne snima nigde drugde osim u Grid. U Delphi-ju si takve stvari mogao da definišeš u TTable-u i automatski svi gridovi koji koriste taj TTable preuzmu njegove property-je za kolone, dok .Net DataTable takve property-je nema, to se definiše i snima samo u Gridu, tako da ne vidim zašto sam parcijalno u pravu

Potpis

if it walks like a duck and quacks like a duck, it could be a dragon doing a duck
impersonation.