[delphi] variabele tekstvakken en database

[whitecom]

We zitten hier met een voor ons gevoel redelijk complex probleem.
We zijn een applicatie aan het bouwen en de toekomstige gebruikers dienen bij een bepaald gedeelte van het programma zelf hun tekstvakken aan te maken met de daarbij behorende labels.

Bijvoorbeeld in een PageControl, op een bepaalde tab werkt piet met 5 editvakken
omdat hij 5 dingen dient in te voeren en henk werkt met 10 editvakken en 10 andere labels omdat hij heel andere taken uitvoert en het programma dus net iets anders gebruikt.
Dus dat je zeg maar editvakken kan toevoegen//verwijderen maar dat het programma het ook goed wegschrijft naar de database.

Deze editvakken moeten vervolgens naar een tabel worden weggeschreven,
ik hoef geen complete code (stukjes code die ons op weg helpen zijn handig), maar heeft iemand een naar zijn/haar weten goede manier om dit aan te pakken?
Want wij komen er hier niet uit.

Alvast bedankt

ps. een datagrid is geen optie! het gaat hier om gebruiksvriendelijke aspect en het feit dat het voor de toekomstige gebruikers wellicht moeilijk te begrijpen is

[ Voor 9% gewijzigd door whitecom op 19-02-2004 15:20 ]

[Tomatoman]

Ken je ExpressLayoutControl van Developer Express (www.devexpress.com)? Dat biedt je in ieder geval de mogelijkheid om de gebruikers op een heel gebruikersvriendelijke manier de user interface te laten aanpassen.

Het probleem dat je beschrijft, is daarmee voor wat betreft de user interface opgelost. Nu nog het datadefinitiegedeelte. Daarmee loop je tegen een fundamentele keuze aan, die veel invloed heeft op de complexiteit van het programma. Definieert de gebruiker eenmalig (vooraf) welke velden hij wil gebruiken, of moet het ook achteraf nog mogelijk zijn om de datastructuur aan te passen?

In het eerste geval maak je gewoon een query die een tabel bouwt. Je voegt een ID-veld toe dat als primary key functioneert en vervolgens voeg je voor alle velden in de user interface een extra veld toe. Is het een (DB) edit box, dan voeg je een veld van het type string toe. Is het een datum, dan wordt het een datumveld. Vervolgens run je de query om de tabel te maken. Als derde stap link je alle databasecomponenten en -controls aan elkaar. Ten slotte bewaar je de layout - inclusief alle koppelingen tussen de controls en de recordvelden in de tabel – via de layout control van Developer Express (zoiets als cxLayoutControl.SaveToFile(‘mijnlayout.ini’)).

In het tweede geval wordt het een stuk ingewikkelder, want dan moet je ook eventueel query’s maken die de tabeldefinitie van de al bestaande tabel met gegevens aanpast. Dat is behoorlijk tricky, want als je niet oppast kieper je alle tot dusver ingevoerde data overboord.

[Verwijderd]

Hoe zit de achterliggende database in elkaar? Maakt iedere gebruiker een eigen tabel aan oid, waarom verschilt anders het aantal edit velden.
Kan er uit een beperkte set met namen gekozen worden en hoe wil je de vakken aan de database linken?

Verder is het runtime maken van een editveld en label gewoon hetzelfde als het maken van een ander object, eerst maken en dan de eigenschappen(properties) goed stellen:

NewEditField:=TEdit.Create(..);
NewEditField.top:=....
...


edit: zie ook tomatoman's post

[ Voor 10% gewijzigd door Verwijderd op 19-02-2004 15:46 ]

[whitecom]

Het zit dus zo, in het programma ben je aan het begroten,

alleen heeft iedere begroting andere eigenschappen.
Dus ook een onbeperkte set met namen en kunnen er zoveel labels+editvakken worden ingevuld als nodig is.

Er maken ongeveer 8 mensen tegelijkertijd gebruik van de database, maar ik denk niet dat het de bedoeling is dat ze allemaal zelf eigenschappen aan die begroting gaan geven maar dat dit het werk van 1 persoon is omdat er sprake is van een zekere taakverdeling. Het programma is dus zo en zo multi-user en draait vanaf een server.

Misschien is het zo iets duidelijker

[LordLarry]

Duidelijk genoeg wat mij betreft. De vraag is: Zijn de gegeven oplossing voor jouw duidelijk?

[whitecom]

Het zou misschien nog iets preciezer omschreven kunnen worden;
Het koppelen tussen de db en de variabele editvakken is nu het moeilijke gedeelte
het lukt inmiddels om editvakken toe te voegen // verwijderen

We maken per begroting een database en we houden een tabel aan voor alle variabele velden dat is de opzet tenminste

[ Voor 30% gewijzigd door whitecom op 19-02-2004 16:48 ]

[LordLarry]

Je zal bij het aanmaken van de edit m ook meteen moeten vullen met de juiste waarde uit je tabel. Dat kan door naar het juiste record te 'lopen' (Next, Locate, First) en de waarde te lezen met bv FieldByName('Veldnaam').AsString.

Wanneer je de gegevens op wilt slaan loop je weer door alle edit's heen en zoekt het juiste record er weer bij op. Daarna schrijf je de waarde uit de edit in het juiste veld (ook weer met FieldByName, maar vergeet de Edit en Post functies niet).

[koli-man]

whitecom schreef op 19 februari 2004 @ 15:52:
Het zit dus zo, in het programma ben je aan het begroten,

alleen heeft iedere begroting andere eigenschappen.
Dus ook een onbeperkte set met namen en kunnen er zoveel labels+editvakken worden ingevuld als nodig is.

Er maken ongeveer 8 mensen tegelijkertijd gebruik van de database, maar ik denk niet dat het de bedoeling is dat ze allemaal zelf eigenschappen aan die begroting gaan geven maar dat dit het werk van 1 persoon is omdat er sprake is van een zekere taakverdeling. Het programma is dus zo en zo multi-user en draait vanaf een server.

Misschien is het zo iets duidelijker

Dus als ik het goed begrijp, dan kunnen ook meerdere mensen met dezelfde functie/rechten dezelfde tabel wijzigen.
Dan zou ik wel nog even aandacht geven, aan het probleem als meerdere personen hetzelfde record gaan wijzigen.

[whitecom]

koli-man schreef op 20 februari 2004 @ 09:18:
[...]


Dus als ik het goed begrijp, dan kunnen ook meerdere mensen met dezelfde functie/rechten dezelfde tabel wijzigen.
Dan zou ik wel nog even aandacht geven, aan het probleem als meerdere personen hetzelfde record gaan wijzigen.

klopt, wat LordLarry zegt is logisch en te begrijpen, maar het kan idd voorkomen dat mensen met dezelfde rechten dezelfde tabel wijzigen

ik ben iig al een stuk op weg geholpen; ik ga me nu eerst focussen op het wegschrijven en ophalen van de db; het probleem met meerdere users tegelijk kan ik denk ik wel oplossen d.m.v. record locking

[koli-man]

whitecom schreef op 20 februari 2004 @ 09:25:
[...]


klopt, wat LordLarry zegt is logisch en te begrijpen, maar het kan idd voorkomen dat mensen met dezelfde rechten dezelfde tabel wijzigen

ik ben iig al een stuk op weg geholpen; ik ga me nu eerst focussen op het wegschrijven en ophalen van de db; het probleem met meerdere users tegelijk kan ik denk ik wel oplossen d.m.v. record locking

Dat kan, als het goed is wordt recordlocking door de database zelf gedaan. Maar stel je voor, iemand is aan de diarree en moet regelmatig naar de wc en staat toevallig op dat record. Iemand anders wil dit wijzigen. Als mensen met een goede stoelgang op het bedrijf werken, gaat je dit best veel geld kosten

[alienfruit]

Hmm. Dit is een bekend probleem, waar ik een paar jaar geleden een framework voor heb geschreven. In principe werd het gebruikt om vanuit een XML achtige taal dialogen te definieren. Maar dit kan natuurlijk ook worden opgeslagen in de database.

Als je het in een database gebruikt moet je zorgen dat je record/tabel locked tijdens het edit-en. Ik zal erg in ieder geval wel voor zorgen dat er maar een iemand de dialogen kan edit-en anders krijg je ongelofelijk veel gezeik (trust me ).

Overigens is ExpressLayout inderdaad een goed alternatief, alleen bevat de control nog behoorlijk wat bugs. Wat het toch meer wat minder maakt om het te gebruiken.

Mijn framework is een standard interface die je aan een control kan toevoegen, vervolgens heb je een X aantal standaard velden nodig namelijk: type, positie, grootte en z-index en parent. Dit is dan ongeveer een record in een tabel "items". Ik heb er tot nu veel plezier mee, aankomende vakantie ga ik het dmv. DataAbstract database onafhankelijk maken.

[koli-man]

alienfruit schreef op 20 februari 2004 @ 09:35:
Als je het in een database gebruikt moet je zorgen dat je record/tabel locked tijdens het edit-en. Ik zal erg in ieder geval wel voor zorgen dat er maar een iemand de dialogen kan edit-en anders krijg je ongelofelijk veel gezeik (trust me ).

Maar dat is eigenlijk het punt, van die iemand met die goede stoelgang. Die persoon die iets wil/moet wijzigen op dat moment kan dat niet. Dat kan vervelend zijn, want hij kan niet door met zijn/haar werk. Dat zal in de praktijk nooit voorkomen, maar Murphy ligt altijd op de loer

[ Voor 4% gewijzigd door koli-man op 20-02-2004 09:45 ]

[whitecom]

koli-man, wat is je suggestie dan? ik wil dat probleem toch op kunnen vangen in het programma.
Wat zou ik dan moeten doen, want verder dan record-locking komt ik niet

Het lukt me nu wel al om runtime velden toe te voegen // verwijderen nu moet ik me nog even bezig houden met de koppeling tussen velden en db (ms sql server)

[koli-man]

Tja, dat is ook tevens het lastige punt. Je kunt het wel opvangen, maar of het vriendelijk werkt voor degene die jouw applicatie gaan gebruiken dat moet je zelf maar beslissen.(Je kunt het wel vriendelijk maken natuurlijk )
Dit kan een oplossing zijn, misschien niet supernetjes, maar alla...

Zodra iemand een post doet, zorg je dat de exactie tijd bij dat record wordt weggeschreven, dat zit volgens mij ook in de database d.m.v. timestamps of iets dergelijks.

Als iemand een record wil aanpassen haal je tevens dat tijdveld binnen en houdt je vast.(Je gaat in dit geval niet direct in de tabel schrijven want anders lock je nog de tabel)

Als diegene het record na aanpassing weer doet posten controleer je of de datum die jij hebt opgehaald nog hetzelfde is als de datum van het record wat in de tabel staat.
Als deze overeenkomen, kun je met een gerust hart posten.
Komen deze niet overeen, zul je met iets anders moeten komen. En dat iets anders kun je in principe naar eigen wens invullen.

[ Voor 3% gewijzigd door koli-man op 20-02-2004 10:15 ]

[alienfruit]

Hoe vaak zou je nieuwe schermen willen maken? Ik neem aan niet elke dag?

Je kan natuurlijk ook dee gegevens in een INI files/registry op slaan voor die gebruiker specifiek. Verder zou je kunnen kijken of het mogelijk is om de GUI data in het geheugen (memory dataset?) op te slaan en alleen in de database als er echt (grote) wijzigingen zijn of alleen bij het afsluiten. Verder zal ik zulke GUI settings koppelen aan de gebruiker.

[ Voor 28% gewijzigd door alienfruit op 20-02-2004 10:25 ]

[whitecom]

stel je voor dat je group-boxes kunt toevoegen en verwijderen en dat vervolgens alle ingevoerde gegevens naar een database wegschrijft.
Per begroting houden we graag vast aan een database; het liefst stoppen we toch alle gegevens van deze voorbladgegevens in één tabel

Misschien krijgen jullie zo een beter beeld van de situatie.

We krijgen hier alles voor elkaar, we kunnen zelfs al redelijk complexe begrotingen creëren met ons programma alleen dit krijgen we dus niet draaiend ....

[alienfruit]

Alles op slaan in een database/tabel qua gegevens is natuurlijk geen probleem. Alleen het opslaan van de velden e.d. wordt denk ik wat lastig, omdat je dan allemaal gegevens op moet slaan die niet echt tot de voorblad info behoort.

Het generen van groupboxes, buttons, editboxes is natuurlijk niet zo moeilijk als je een parent opslaat in je opslagmedium

Wil je de UI per gebruiker aanpasbaar maken of per "voorblad" of algemeen in het programma? Want je kunt natuurlijk een apart tabel maken op deze gegevens op te slaan bijv.

tbl_controls
id autoinc,
name string
type integer/enum (kan natuurlijk ook field van voorblad db pakken)
field_name (koppeling naar veld in tabel)
database (welke db?)
tablename (welke tabel?)
left
top
width
height
parent (welke control is de parent? (voor groupboxes e.d.)
caption (leuk voor omschrijving voor de label langs de control ibj een edit -type)

zoiets heb ik ook in de XML formaat e.d.

[ Voor 46% gewijzigd door alienfruit op 20-02-2004 11:01 ]