Page 2 of 2 FirstFirst 1 2
Results 16 to 19 of 19

Thread: TEdit onexit

  1. #16
    Senior Member ErikB's Avatar
    Join Date
    Aug 2010
    Location
    Biddinghuizen
    Posts
    509
    ik denk dat ik begrijp wat je bedoelt.
    stel naast de TEdit is een Tbutton , waar bijvoorbeeld een berekening achter de onclick zit die de gegevens van de TEdit nodig heeft, dan geef je in die onclick eventueel een melding dat de ingevoerde gegevens in de TEdit niet toereikend zijn voor het accuraat verwerken van de berekening. Of als de gegevens van de TEdit in een veld in de database moet komen, zou je dus voor de Post ( in de OnPost ) een melding geven dat de invoer niet correct is.
    Is dat goed vertaald ?
    Erik

  2. #17
    Silly member NGLN's Avatar
    Join Date
    Aug 2004
    Location
    Werkendam
    Posts
    5,133
    Inderdaad, ja. Hoewel je daarbij alleen het perspectief van de programmeur beschrijft, kunnen dat prima implementatiekeuzes zijn, afhankelijk van het programma en de gebruiker.

    Vanuit het perspectief van de gebruiker gaat het simpelweg maar om één ding: gebruiksvriendelijkheid. Wanneer je met code in een OnExit-handler bewerkstelligt dat de gebruiker een control niet meer kan verlaten, in het slechtste geval zelfs niet om de annuleren-knop te bereiken (!), dan is dat simpelweg níet gebruiksvriendelijk. Verplaats jezelf in de gebruiker: je wilt iets verkeerd in mogen kunnen voeren, je wilt ook een fatsoenlijke kans krijgen om dat te corrigeren, en je wilt dat bij voorkeur op een voor jouw geschikt moment. Sluit een gebruiker niet op in een Edit box!

    In het algemeen gesproken:

    Er zijn meerdere manieren om te voorkomen dat er foutieve invoer plaatsvindt, maar voornamelijk en bij voorkeur doe je dat door gebruik te maken van het juiste type control met de juiste instellingen. Mocht er toch foutieve invoer plaatsvinden, dan stop je verdere verwerking door bijvoorbeeld de volgende stap voorlopig uit te schakelen. Hiertoe moet je als programmeur de keuze maken waar en wanneer te controleren op foutieve invoer. Dit kan in OnExit van de verschillende controls, waarbij er bijvoorbeeld in de code een vlaggetje gezet wordt, of dat er visuele feedback op het form plaatsvind, bijvoorbeeld een icoon, balloon, statustekst, rode kleur, whatever gebruikelijk en mogelijk is voor het programma, type control en gebruiker. De controle kan ook plaatsvinden in de OnUpdate van actions, bijvoorbeeld die van de action achter de "Doorgaan/Verder"-knop. De controle kan je ook uitstellen totdat alles is ingevuld en net voordat je definitief gaat opslaan of op OK wordt geklikt, zoals in jouw voorbeelden.
    Last edited by NGLN; 18-Apr-20 at 15:56.
    (Sender as TNLDUser).Signature := 'Groeten van Albert';

  3. #18
    Silly member NGLN's Avatar
    Join Date
    Aug 2004
    Location
    Werkendam
    Posts
    5,133
    Hierbij ter volledigheid enkele quotes uit eerder genoemde verwijzingen naar andere topics betreffende dit onderwerp, welke ik ten zeerste kan aanraden in hun geheel door te nemen:

    Quote Originally Posted by GolezTrol View Post
    Jouw software ga ik niet gebruiken. Wat nou als ik bij nader inzien dit niet wil? Mag ik dan wel op de cancel knop drukken?

    Mijn mening hierover, en ik kan 'm niet vaak genoeg herhalen:
    - Laat de gebruiker zijn waarde invoeren
    - Als je iets wilt afdwingen, doe dat dan met een component dat uberhaupt geen letters toestaat, maar bedenk: dit is alleen een hulpmiddel, net als een mask, een up-down of een calendar/datepicker.
    - Als je een component gebruikt dat wél tekst of andere foutieve invoer toestaat, doe dan gewoon een goede check en geef een melding.
    - Die check hoeft niet direct bij OnExit. Mag wel natuurlijk, maar geef je gebruiker altijd de kans het component te verlaten.
    - Welk component je ook gebruikt, controleer je invoer altijd voordat je deze gaat beperken. Door deze check te doen aan het begin van de procedure die 'echt wat doet met je invoer' kun je nooit een handeling doen op verkeerde invoer, wat er verder ook in je scherm is gebeurd.
    - Nogmaals: Dwing een gebruiker nooit (nou ja, bijna nooit) om in een bepaald veld te blijven en persé iets goed in te vullen. Annuleren zou in principe altijd een optie moeten zijn. Ik moet software kunnen vertellen wat ie moet doen, niet andersom.
    Quote Originally Posted by GolezTrol View Post
    Probeer je eens voor te stellen dat je analfabeet bent, of dat de applicatie in het chinees is gemaakt ofzo. Als je er dan ook nog van uit gaat dat je OK en Cancel knop op de standaard plaats op het scherm staan (rechtsonder en in die volgorde, zoals bij elke zichzelf respecterende applicatie het geval is), en je hebt netjes de 'Cancel' property van de cancel knop aan staan, dan kun je dit proces op een nette manier afsluiten zonder dat je 'ziet' wat je doet. Je drukt gewoon op de Cancel knop (die je zelfs kunt vinden als je de tekst niet kunt lezen) of je drukt op Escape.

    Als je in OnExit dit soort blocking checks doet, dan kan dat niet en loop je het risico dat je een wanhopige gebruiker hebt die via taakbeheer zijn applicatie moet afsluiten of -als dat niet lukt, of de gebruiker dat niet weet te vinden, z'n pc moet rebooten.

    Een extreem voorbeeld natuurlijk, maar het geeft wel een beetje aan waarom je dit soort checks niet blocking moet maken. Uitzondering is misschien een wizard die na een bepaalde stap niet meer terug kan, maar zelfs dat zou je zoveel mogelijk moeten voorkomen.
    Quote Originally Posted by GolezTrol View Post
    Je maakt de fout om bij het invoeren van een editbox niet toe te staan dat iemand de box verlaat bij ongeldige invoer.
    Stel dat je programma gebruikt wordt door iemand die die melding niet goed kan interpreteren, of (minder onlogisch) er is een bug ontstaan waardoor de dataset niet in edit-mode staat en er dus niets ingetypt kan worden?
    In dat geval zou iemand via taakbeheer je programma af moeten sluiten omdat dat de enige manier is om de box te verlaten. Dat kan niet de bedoeling zijn, toch?

    Maar iets concreter: Waarschijnlijk heb je een knop waarvan Default op true staat. Een druk op enter zal naar die knop springen. Dat gebeurt dan al voordat jouw code in werking treedt. Met een druk op tab gebeurt dat blijkbaar niet; die zal juist op een later moment worden afgehandeld.

    De precieze volgorde van afhandeling van dit soort speciale toetsen zorgt nogal eens voor verwarring, evenals het OnExit-event, dat soms niet uitgevoerd wordt, en soms op een onlogisch moment (na de OnEnter van het andere control).

    Al met al zou ik nogmaals willen adviseren om deze controle pas uit te voeren voordat je gaat opslaan en het zeker niet zo hard af te dwingen als je nu probeert te doen.
    Als je al eerder visuele feedback wilt geven, zet dan een plaatje van een vinkje achter een goed ingevulde box en een plaatje van een kruisje achter een fout ingevulde box. Met nog een ander symbooltje kun je aangeven dat invoer verplicht is. Zodoende kan de gebruiker al direct zien waar hij aan toe is, zonder dat hij tijdens de invoer wordt gestoord door blokkerende pop-ups en automatisch verspringende focus.

    Een handjevol voordelen:
    - Je hebt de controle in ieder geval waar je hem altijd hebben moet: op het moment van opslaan
    - Je gebruiker kan direct doorwerken: gebruiksgemak is goed.
    - Ervaren gebruikers storen zich niet aan de kinderlijke 'bescherming' die je toepast
    - Icoon-aanduiding, zoals ik beschreef, is niet blokkerend en stoort niet in het gebruik
    - Icoon-aanduiding kan bovendien op een later moment nog ingebouwd worden --> Voortgang in ontwikkeling.
    (Sender as TNLDUser).Signature := 'Groeten van Albert';

  4. #19
    Senior Member ErikB's Avatar
    Join Date
    Aug 2010
    Location
    Biddinghuizen
    Posts
    509
    ik had ze inderdaad al gelezen. het is heel helder nu.
    als je al weken "opgesloten in het kot" zit zoals onze zuiderburen willen zeggen, dan gaan de grijze cellen ook langzamerhand in slaapstand. Communicatie (het liefst "fysiek" en niet via de media) is toch essentieel voor onze samenleving ( voor mij in ieder geval ).
    Erik

Page 2 of 2 FirstFirst 1 2

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •