Slechts één Veld zichtbaar in doorlopend formulier.

Status
Niet open voor verdere reacties.
J

jbusser

Gebruiker
Lid geworden
23 feb 2007
Berichten
147
Ik vrees het antwoord op mijn vraag al wel te weten, maar niet geschiten is altijd mis!
Helaas is het niet mogelijk om in een formulier te groeperen want dan was deze vraag niet nodig geweest :mad:

Met een knop kan ik een veld uit een tabel zichtbaar maken (Verzender.visible = true)
Echter, dan worden natuurlijk alle verzender-velden zichtbaar in het doorlopend formulier
Is er een manier om uitsluitend het veld behorende bij het te bewerken record zichtbaar te maken?
 
Het nut hiervan ontgaat me eerlijk gezegd (nog) een beetje. Waarom moet je een extra handeling verrichten om iets zichtbaar te maken wat je mag zien?

Je opmerking dat als je zou kunnen groeperen het probleem niet zou bestaan schreeuwt ook om toelichting. Die snap ik echt niet. Bij zo'n opmerking ben ik hooguit geneigd te denken aan een ontwerpfout.
 
Je kan via een knop een apart formulier als dialoogvenster tonen met de naam van de verzender op het actieve record.
 
Ik begrijp de vraag van Peter wel maar die heeft te maken met het oneerbiedig klinkende huf***proof maken van een uitgifteformulier.
Er hoeft namelijk maar één product van een levering gevuld te worden om de hele levering compleet te krijgen, alle producten worden dan namelijk op hetzelfde moment aan dezelfde client geleverd.
(vandaar dat in dit geval groeperen wel makkelijk was geweest)
Bij het klikken op een knop wordt er een controle-veld zichtbaar om te voorkomen dat een levering aan een verkeerde afdeling geleverd gaat worden.
Als in dat geval alle controlevelden geopend worden schiet het zijn doel voorbij...
Bij het vullen van het controleveld en het correct bevinden daarvan worden velden als afgiftetijd, afgiftelocatie en wat meer data gevuld en is de handeling klaar.

Wat NoellaG voorstelt heb ik ook geprobeerd maar dan krijg ik bij het sluiten van het dialoogvenster de melding "Iemand anders heeft het formulier bewerkt terwijl u...."
Hierna kun je kiezen tussen "opslaan" (wat geen geen resultaat geeft) of "op klembord bewaren" waarna de velden gevuld worden.
Dit euvel heeft, mermoed ik, te maken met het feit dat de velden worden gevuld vanuit het dialoogvenster.
 
Laatst bewerkt:
en werken met een split form? Dan heb je steeds een lijst met alle records, maar ook een gewoon single form waarop je de verzender al of niet kan tonen
 
Split form heb ik geen ervaring mee, zal er eens naar kijken, kom er op terug...
 
Ik heb het anders opgelost, inderdaad wél met een dialoogvenster!
Om de foutmelding te voorkomen en de data correct op te slaan heb ik na het openen dialoogvenster het bronformulier laten sluiten. In het dialoogvenseter (met dezelfde dataset) worden de benodigde velden na controle aangepast.
Daarna wordt het bronformulier weer opnieuw geopend en het dialoogvenster gesloten.
Is wat bewerkelijker maar werkt wel goed!
 
jbusser zei:
Er hoeft namelijk maar één product van een levering gevuld te worden om de hele levering compleet te krijgen, alle producten worden dan namelijk op hetzelfde moment aan dezelfde client geleverd.
Klik om te vergroten...
Dit versterkt alleen maar mijn vermoeden van een ontwerpfout. Als een of meer velden van de orderregels binnen een order dezelfde waarde(s) moeten hebben, dan hoort dat veld of horen die velden thuis in de order en niet in de orderregel.
Als je dat zo bouwt heb je vanzelf je "groepering" en is het ook monkeyproof, want kan niet fout gedaan worden.
 
jbusser zei:
Is wat bewerkelijker maar werkt wel goed!
Klik om te vergroten...
Precies!
Als je dit omslachtige gedoe (voor ontwikkelaar én gebruiker) wilt voorkomen, moet je het probleem bij de bron aanpakken. Dit soort "oplossingen" maakt je applicatie alleen maar moeilijker te onderhouden en gebruiken. Bovendien is het wachten op het volgende probleem. Als je dat dan weer op zo'n manier probeert recht te breien, wordt de ellende alleen maar groter.
 
Laatst bewerkt:
Ik ben met Peter. Ik vermoed dat je database in dit geval slecht, of zelfs niet genormaliseerd is. In een order of bestelling heb je een tabel met de order/bestelgegevens, en een gekoppelde tabel met de artikelen. In een formulier zie je dat terug als hoofdformulier en subformulier. Jouw oplossing (TS) is zinloos en verwarrend, en totaal niet nodig. Los het op de juiste manier op :).
 
Het is niet dat we hier in een bedrijf zitten om professionele software uit te rollen en de wil van de projectleider wet is. Als de oplossing goed is voor de vraagsteller en het werkt, wie zijn wij dan om te zeggen dat het anders moet. ;)
 
Wij zijn om te HELPEN. Een vragensteller is niet gebaat bij een slechte oplossing. Als hij (m/v/x) bereid is te luisteren naar welgemeende adviezen, leert hij er nog wat van ook.
 
Laatst bewerkt:
Ben het weer eens met Peter. Slechte oplossingen zou je gewoon niet moeten aanbieden. Je helpt een persoon daar echt niet mee.
 
Daar kan ik me alleen bij aansluiten. Alleen ga ik niet zover om te zeggen : de enige goede oplossing is mijn oplossing, en ik vind de oplossing van de vraagsteller een valide oplossing. En ik heb ook geen behoefte om mensen op te voeden en te doen bijleren. Dat heb ik met mijn drie kinderen gedaan en dat is voor mij voldoende :D.
 
Ik dank jullie allen voor de input. Leer iedere keer wat bij, en daar gaat het mij uiteindelijk om :thumb:
Het lijkt inderdaad zo alsof de database niet aan geldende regels voldoet maar de oorzaak daarvan ligt iets genuanceerder.
Even voor de geïnteresserden:
Heeft alles te maken met AVG.
In het verleden hadden we een bestelling met een aantal producten, voor een persoon.
In de bestelling-tabel zit een leverdatum aan die persoon en wanneer die datum is gevuld is de bestelling voor ons klaar.
Wij zochten altijd op de besteller maar dat mag niet meer :confused:
Nu mogen wij alleen nog maar zoeken op de productcodes en niet meer op personen (heeft alles met AVG en ISO normeringen te maken).
Hiervoor moet ik de product-tabel aanpassen om aan te kunnen geven of het PRODUCT geleverd is om dan, als alle producten geleverd zijn, de bestelling af te ronden.
Op zich allemaal geen probleem maar dat kost wel tijd (heb nog meer projecten lopen) en ik moet voor nu een snelle oplossing hebben en dat is bovenstaande voor nu even voor mij.

Nogmaals: bedankt Allemaal!
 
Het zal wel, maar ik denk dat hier iemand is doorgeschoten in de uitleg van de AVG. Dat je bij het leveren van goederen aan een klant geen gebruik zou mogen maken van klantgegevens kan ik me niet voorstellen. Benieuwd hoe jullie verzendlabels er uitzien :p
 
Ik denk ook dat jullie de ‘spelregels’ voor de AVG nog eens door moeten lezen.

De Algemene verordening gegevensbescherming (AVG) schrijft geen concrete bewaartermijnen voor. Het uitgangspunt is dat u persoonsgegevens niet langer mag bewaren dan noodzakelijk. Wat noodzakelijk is hangt af van de situatie. Vandaar dat u zelf moet vaststellen wat in uw situatie passend is.


  • Hoe lang heeft u de gegevens nodig voor het doel waarvoor u ze verwerkt? Kijk hierbij ook naar uw bedrijfsbeleid. Zo kunt u bepaalde gegevens bijvoorbeeld nog nodig hebben voor de controle op openstaande facturen.
Klik om te vergroten...
Het is waar dat je persoonsgegevens maar een bepaalde tijd mag bewaren, maar die tijd moet lang genoeg voor jullie zijn om een bestelling af te ronden. Is die dat niet, dan denk ik niet dat ik ooit iets bij jullie ga bestellen :).

Sowieso snap ik niet waarom je je Product tabel moet aanpassen; in je bestelling gebruik je als het goed is alleen het ProductID (in de tabel OrderRegels), en dat zal niet veranderen. En in je tabel Orders heb je als het goed is één verwijzing naar je KlantID staan. Dus ik zou je oplossing in die hoek zoeken.
 
Sorry,
Had er niet bij stilgestaan bij de initiële vraag dat het type "klanten" van belang kon zijn, Discussie ging andere kant op....
De "klanten" hier, betreffen "Patienten"
 
Laatst bewerkt:
Ik kan het niet nalaten nog een laatste keer te reageren, al heeft dat eigenlijk geen zin; het is trekken aan een dood paard.

De AVG heeft ook te maken met de vraag waarom je bepaalde gevens vastlegt (doel) en met het delen van gegevens met derden (niet tenzij). Bovenal heeft het te maken met bewustwording. Dat je bepaalde gegevens mag zien betekent nog niet dat je die maar met iedereen mag delen of anderzins gebruiken.
Het doel van het vastleggen ėn inzien is hier duidelijk: zorgen dat een patiënt de juiste spullen krijgt. Juist in dit geval is dat van levensbelang, dus te rechtvaardigen. Als ik medicijnen af ga halen moet ik mijn naam en geboortedatum noemen om er zeker van te zijn dat de juiste pillen naar de juiste persoon gaan.

Je werkwijze via artikel begrijp ik ook niet echt. Hetzelfde artikel kan toch bij meerdere orders nog geleverd moeten worden? Hoe vind je dan de juiste order?
 
Klanten of patiënten maakt voor een database uiteraard niet uit. Wij moeten het doen zonder enige informatie, dus we gebruiken een fictieve case (bestellingen) die lijkt aan te sluiten bij jouw vraag. En dat maakt hier dus m.i. inderdaad niets uit. Ik denk zelfs dat je in deze situatie gegevens echt wel langer mag bewaren.
 
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan