[Access 2K] niet wenselijk; parallel tasking bij knop events

[Verwijderd]

Ik heb in de afgelopen twee jaar meerdere applicaties geschreven in Access 97 en 2000. Deze lopen nog steeds zonder veel problemen.

Nu ben ik er de afgelopen tijd tegen een nare eigenschap aangelopen.

Situatie:
De gebruiker drukt op een knop en een functie wordt gestart...... niks aan de hand...

De gebruiker die zo'n lol heeft in zijn werk wil het liefst zo veel mogelijk doen in zo'n kort mogelijke tijd (of hij/zij is ongeduldig ??!!??) en klikt een andere knop aan.

De functie achter deze knop wordt gestart, en het resultaat is niet te voorspellen; de applicatie crashed of verziekt de data op z'n minst

Vraag:
Wie heeft hier ervaring mee, en hoe lossen jullie dit op?

Ik heb er wel een aantal ideeën over, maar ben benieuwd of ik structureel tekortschiet???!?? (het aantal gevallen waarin deze vorm van "parallel tasking" wenselijk is is naar mijn idee minimaal afgezien van on timer events etc.)

[kenneth]

Parallel tasking == concurrency != Access

Wij hebben dit (en andere nukken) opgelost door over te stappen op MSSQL, en voor de frontend ADP-projecten te gebruiken.

[farlane]

De andere knoppen blokkeren tijdens de uitvoering van die taken. En vooral DoEvents niet gebruiken.

[Verwijderd]

kenneth schreef op 09 december 2003 @ 15:30:
Parallel tasking == concurrency != Access

Wij hebben dit (en andere nukken) opgelost door over te stappen op MSSQL, en voor de frontend ADP-projecten te gebruiken.

Dat zou ook een oplossing zijn, maar ik kan de bedrijfspolicy mbt de software niet veranderen.

Ik zou ook liever overstappen op een andere taal (ook al heb ik daar weinig ervaring mee) maar het moet (voorlopig) binnen Access opgelost worden.

[Verwijderd]

farlane schreef op 09 december 2003 @ 16:59:
De andere knoppen blokkeren tijdens de uitvoering van die taken. En vooral DoEvents niet gebruiken.

Ik kan niet alle knoppen disablen, en daarna weer enablen omdat het al dan niet mogen gebruiken (enabled) van de knoppen afhankelijk is van de userrechten.

Dan zou ik op usergroup-niveau moeten kijken wat de rechten van de user zijn, en daarna de betreffende knoppen weer enablen.

farlane schreef op 09 december 2003 @ 16:59:
.......... En vooral DoEvents niet gebruiken.

Waarom dat, deze gebruik ik regelmatig om bijvoorbeeld de vorderingen van langlopende code te tonen mbv checkboxes. Zonder DoEvents worden de comboboxes pas (zichtbaar) aangevinkt op het moment dat de code klaar is of minder load veroorzaakt.

Geeft DoEvents het systeem dan meer "adempauze" dan strikt noodzakelijk is voor het uitvoeren van lopende acties???

[ Voor 53% gewijzigd door Verwijderd op 10-12-2003 09:04 ]

[Crazy D]

Je zou de buttons die de gebruiker niet mag gebruiken invisible kunnen maken, dan kun je gewoon alle buttons disablen en later weer enablen. Je kunt ook de Tag property vullen met iets waarmee je in je code kunt afvangen of een button wel of niet enabled mag worden (hoef je iig niet iedere keer de rechten te controleren om te bepalen of een button wel of niet enabled mag worden).
Je zou ook een boolean 'isbusy' bij kunnen houden, en als er op een knop wordt gedrukt terwijl de busy-vlag true is, direct een exit sub doen.
Of enable/disable de hele form

DoEvents geeft de applicatie de ruimte om andere events af te handelen (bv dat er op een Cancel button geklikt kan worden), maar dat houdt automatisch ook in dat er ook op andere buttons te klikken is.

[Verwijderd]

Crazy D schreef op 10 december 2003 @ 11:24:
Je zou de buttons die de gebruiker niet mag gebruiken invisible kunnen maken, dan kun je gewoon alle buttons disablen en later weer enablen. ..........

Hmmmm hier heb ik al ervaring mee, als de gebruikers geen delete-knop zien gaan ze net zolang zoeken totdat ze iets kunnen wissen Ze kunnen beter een deleteknop disabled zien zodat ze weten dat het niet mag.

Crazy D schreef op 10 december 2003 @ 11:24:
..........Je zou ook een boolean 'isbusy' bij kunnen houden, en als er op een knop wordt gedrukt terwijl de busy-vlag true is, direct een exit sub doen.
Of enable/disable de hele form ............

Dat met die IsBusy boolean is wel een goede oplossing, had ik nog niet aan gedacht wel redelijk tricky bij fouten etc. maar dat is wel te overkomen!! Het gehele form disablen is misschien nog wel de makkelijkste, alleen 1x een enable vergeten, en het geval hangt....

Crazy D schreef op 10 december 2003 @ 11:24:
.........DoEvents geeft de applicatie de ruimte om andere events af te handelen (bv dat er op een Cancel button geklikt kan worden), maar dat houdt automatisch ook in dat er ook op andere buttons te klikken is.

Maar als je geen DoEvent gebruikt voert ie de code toch uit nadat ie met het huidige klaar is??? Dus eigenlijk maakt het niet zoveel uit, behalve dat ie niet middenin andere code erdoorheen knalt met alle gevolgen

[Verwijderd]

Is er geen manier om mbv te bepalen of er code uitgevoerd wordt, en dan het geheel te disablen, dit is een algemene oplossing die niet verweven hoeft te worden met de applicatie!!!

Kijken naar de algehele load van de processor is geen optie, geeft niet de info of de load veroorzaakt wordt door de betreffende applicatie.

Kijken naar de specifieke load die de applicatie veroorzaakt kan een optie zijn, maar die zou de continu bekeken moeten worden, en als de load omhoog gaat moeten de actieve forms gedisabled worden..... niet echt haalbaar...

Zit maar een beetje te brainstormen, ik kan zelf niet op een structurele makkelijk implementeerbare oplossing komen?!? Terwijl deze er wel moet zijn volgens mij

[ATS]

Wat voor sommige situaties kan helpen is het tonen van een modal progress dialog. Aan de ene kant geeft het de gebruiker informatie over het feit dat de database bezig is, en aan de andere kant verhindert hij dat de gebruiker iets anders kan doen tussendoor, zonder dat je ingewikkelde constructies hoeft te maken. Je kan natuurlijk wel gewoon een Cancel button ofzo op de progress dialog zetten, zodat je je taak eventueel kan onderbreken (als dat mogelijk is in jouw geval).

Mijn ervaring is dat dit soort oplossingen goed werken. Ze maken gebruikers geduldiger (ze zien dat er wat gebeurd), en ze voorkomen ongewenste input van de gebruikers.

[Verwijderd]

ATS schreef op 10 december 2003 @ 12:03:
Wat voor sommige situaties kan helpen is het tonen van een modal progress dialog. Aan de ene kant geeft het de gebruiker informatie over het feit dat de database bezig is, en aan de andere kant verhindert hij dat de gebruiker iets anders kan doen tussendoor, zonder dat je ingewikkelde constructies hoeft te maken. Je kan natuurlijk wel gewoon een Cancel button ofzo op de progress dialog zetten, zodat je je taak eventueel kan onderbreken (als dat mogelijk is in jouw geval).

Mijn ervaring is dat dit soort oplossingen goed werken. Ze maken gebruikers geduldiger (ze zien dat er wat gebeurd), en ze voorkomen ongewenste input van de gebruikers.

Klopt, daarom laat ik ook vaak zien mbv vinkjes hoever gevorderd is, maar bij het opslaan van gegevens etc. is dit niet relevant omdat dit maar een paar seconden duurt...... maar die paar seconden zijn wel genoeg om ff om een andere knop te timmeren.

[Crazy D]

Verwijderd schreef op 10 december 2003 @ 11:55:
Hmmmm hier heb ik al ervaring mee, als de gebruikers geen delete-knop zien gaan ze net zolang zoeken totdat ze iets kunnen wissen Ze kunnen beter een deleteknop disabled zien zodat ze weten dat het niet mag.

Da's waar Daarom gebruikte ik ook meestal de tag property om aan te geven of een control enabled mag worden ("ignore" en dan default op disabled, en m'n enableform functie enabled die control dan niet). In combinatie met een IsBusy vlag trouwens, want als je niet heel de form disabled kun je nog wel op het kruisje drukken om de form te sluiten (waar ik dan de IsBusy vlag check en een melding geef dat het programma bezig is met het 1 of ander).

Dat met die IsBusy boolean is wel een goede oplossing, had ik nog niet aan gedacht wel redelijk tricky bij fouten etc. maar dat is wel te overkomen!! Het gehele form disablen is misschien nog wel de makkelijkste, alleen 1x een enable vergeten, en het geval hangt....

Ik heb altijd een enableform functie die ook meteen die vlag zet, aangezien de controls toch weer enabled moeten worden wordt die vlag dan ook meteen weer teruggezet.

Maar als je geen DoEvent gebruikt voert ie de code toch uit nadat ie met het huidige klaar is??? Dus eigenlijk maakt het niet zoveel uit, behalve dat ie niet middenin andere code erdoorheen knalt met alle gevolgen

Dat weet ik niet zeker, maar daar zou je weleens gelijk in kunnen hebben (maar aangezien ik altijd met een IsBusy vlag werk heb ik dat nooit getest of last van gehad).


Voor langer lopende akties is een progressbar inderdaad een goede oplossing, al is het wel grappig want vaak duurt het daardoor iets langer, maar gevoelsmatig juist korter