Opgelost Me.Form.TimerInterval = 1

Dit topic is als opgelost gemarkeerd

Sanders69

Gebruiker
Lid geworden
24 mrt 2018
Berichten
200
Ik doe vast weer wat verkeerd ,-)
Als een formulier geopend wordt en een paar listboxen moeten gevuld worden komt het voor dat het 5 tot zelf tien seconden duurt.
Toen dacht ik , zet een Form.TimerInterval op 1 en zodra deze geactiveerd wordt toon ik een label dat een statuspercentage weergeeft waar het ophalen van de gegevens staat.
Alleen de Form.TimerInterval = 1 neemt zelfs 8 seconden eer dat deze in deze event terechtkomt.
Als ik alleen de form_load gebruik dan ziet men niet de progressbar lopen want eerst moet de formulier geladen worden en dan zijn de listboxen ook inmiddels gevuld.
Weten jullie een ander event dat na form_load komt en dan zichtbaar wordt dat deze statuspercentage weergeeft?
 
Misschien eerst even kijken of je het ophalen van de gegevens kan versnellen:
bekijk de onderliggende queries en
- kijk of je geen index kan creëren die het ophalen versnelt
- in een FE/BE situatie: kijk of het de query of de connectie is die de traagheid veroorzaakt
- kijk of je het aantal gegevens in de lijst niet kan beperken
 
Dankje voor de tip alleen is dat geen optie. Begrijp gewoon niet dat ze beweren Me.Form.TimerInterval = 1 één milliseconden zou moeten duren en prompt duurt het ruim 8 seconden. Hopelijk is er een andere methode om de statuspercentage te weergeven nadat de formulier is geopend.
 
Elke procedure die je extra op een formulier zet, en die processortijd 'weghaalt' zal je proces vertragen. Dus ja, dan wordt 5 seconden al snel 8 :). Niet doen dus, en ik zou eerst maar eens kijken of je iets aan de dataset kan doen, zoals noella ook al zei.
En kijk eens hoe lang het duurt als je de onderliggende query opent. Normaal gesproken hoeft een formulier daar niet zoveel vertraging aan toe te voegen, dus als de query wél snel opent, dan zit er een probleem in je formulier dat je dan eerst zou moeten oplossen.
Zelf heb ik nog nooit een progress bar gezien die het formulier níet langzamer maakt. Typisch gevalletje dus van 'paard achter de wagen spannen' :D.
 
Pfff, dat is het probleem niet heb het vertrouwen dat ik weet wat ik doe. Bij form_load zit er geen procedures en ik wacht gewoon 8 seconden op niets.
De ophalen van de dataset gaat snel alleen haal ik overal gegevens op om de gebruiker meer van informatie te voorzien en dat kan misschien 1 max 2 seconden schelen maar de 8 seconden gaat nergens op.
Dus jullie weten ook geen event dat na form_load de scherm weergeeft en dan ik dan een label kan vullen met de status van ophalen.
 
niets dat de situatie niet erger gaat maken, dus misschien toch maar proberen de oorzaak van het probleem aan te pakken.
 
De ophalen van de dataset gaat snel alleen haal ik overal gegevens op om de gebruiker meer van informatie te voorzien en dat kan misschien 1 max 2 seconden schelen
Geen idee wat je hier zegt. Je formulier heeft, neem ik aan, één gegevensbron. Dat is ofwel een tabel, ofwel een query. Iets anders kan ik niet verzinnen. Ja, een hoofdformulier met verschillende subformulieren, waarbij elk subformulier dan uiteraard zijn eigen gegevensbron heeft. En elk subformulier moet ook weer geladen worden. Dus je zult dan al die queries apart moeten draaien en timen, anders vergelijk je één appel met een hele doos met peren.

Nogmaals: als een recordset (of een combinatie) ingewikkeld is, dan duurt het laden wat langer. Daar is dan weinig aan te doen. Een progress bar gaat je daarbij niet helpen, want die gaat toch pas lopen als de andere taken gedaan zijn. Of ervoor. Je ziet er dus als gebruiker niets aan. Veel beter is het om even een label op het formulier te zetten met de tekst "Even geduld aub terwijl de data wordt ingeladen...". Dan snapt de gebruiker echt wel dat er even niets gebeurt op het scherm.

Of, in het geval van subformulieren, kun je ervoor kiezen om die nog niet te laden, maar pas bij het activeren van het subformulier. Onder het motto: 'waarom zou je alles laden als je dat tóch nog niet kan gebruiken?'

Kom je uit Rotterdam, dan is de maximale wacht (lees: irritatie)tijd overigens 2,3 seconde, dus dan snap ik wel dat men met spullen gaat smijten :D.
 
Nee ik maak een rowsource aan voor een lisbox waar ik veel informatie uit andere tabellen vandaan haal. Hoe meer gebruiker en hoe vaker men hiervan gebruik maken des te langer het duurt.
Ik programmeer 30 jaar dus weet echt wel hoe je je database, tabellen en indexen alleen is daar geen winst te halen.
Ik stel een vraag over forms events en krijg alleen antwoorden over wat anders.
Geef niets maar verwacht dan ook dat ik daar wat over kan melden.
En ja ik kom uit rdam, kan je het horen dan ,-)
Ik blijf het vreemd vinden dat wanneer je de timer op 1 milliseconde zet dat het 8 seconden duurt.
Er is geen datasource ingesteld in formulier en in de syntaxis van form_load staat eigenlijk iets van 8 regels code wat de tekstvakken en listboxen leeg maakt.
Daarom hoopte ik dat er evt een ander form event is waar ik dan mijn lisbox kan vullen.
Dat is mijn vraag of dat je me kan vertellen waarom het 8 seconden duurt eer de form_timer event geactiveerd wordt met de instelling: Form.TimerInterval = 1
 
Ik stel een vraag over forms events en krijg alleen antwoorden over wat anders.
Dat klinkt een beetje als een argument van de grootste PP van dit moment :). Die accepteren namelijk ook nooit dat iets gewoonweg niet kan. Met een argument als 'ik bén beleid' wordt dat dan verdedigd....

En die timer waarde zegt natuurlijk helemaal niets: het gaat er om dat je een extra actie hebt ingebouwd die, in jouw geval, dus continue wordt uitgevoerd (hoe lang denk je dat 1 milliseconde duurt). Vermoedelijk werkt het formulier met een waarde van 1000 zelfs een stuk sneller. Want in die 'vrije' 999 milliseconde kan de processor weer wat anders doen.
Nogmaals: ik heb in het verleden meermaals geprobeerd om een Progress bar aan de praat te krijgen, maar dat lukt gewoonweg niet bij het openen van een formulier. Bovendien: waar moet die PB mee rekenen? Wil je een zinvolle PB hebben, dan wil je dat die de tijd laat zien die verstrijkt tussen begin van een proces en het eind van een proces. Op basis van die berekening kan de PB dan een verloop laten zien. Maar jij weet alleen de begintijd, niet de eindtijd. Dus dat ding doet maar wat. Nutteloze informatie op het scherm. (wat dan ook wel weer bij de eerder genoemde PP past ;)).
 
Dat is mijn vraag of dat je me kan vertellen waarom het 8 seconden duurt eer de form_timer event geactiveerd wordt met de instelling: Form.TimerInterval = 1
Volgens mij heb je die vraag zelf beantwoord met:
ik maak een rowsource aan voor een lisbox waar ik veel informatie uit andere tabellen vandaan haal. Hoe meer gebruiker en hoe vaker men hiervan gebruik maken des te langer het duurt.
De timergebeurtenis wordt pas voor het eerst geactiveerd als het formulier volledig is opgebouwd. Eerder heeft geen zin omdat gegevens die mogelijk wilt gebruiken in de gebeurtenis nog niet beschikbaar zijn. En zoals herhaaldelijk gezegd, elke millisecond iets doen gaat de zaak echt niet versnellen.
 
Nogmaals: ik heb in het verleden meermaals geprobeerd om een Progress bar aan de praat te krijgen, maar dat lukt gewoonweg niet bij het openen van een formulier.
Daarom laad ik eerst de formulier en daarna
 
Okay luister en huiver. Als ik niet de Form_timer inschakel is de formulier binnen 3 seconden gestart en is voornamelijk bezig de rowsource aan te maken.
Toen dacht ik, ik laad eerst de formulier en daarna schakelt de timer aan binnen 1 milliseconde en kan je via de pb zien dat er iets gebeurd ipv via form_load waar je tegen een zandloper aan zit te kijken.
Het vage is dan dat als ik de form_timer instel opeens 8 seconden nodig heeft.
Ook heb ik getest als ik de rowsource niet vul en ook de form_timer niet laat starten dan is de form_load binnen een seconde geladen. Ik begrijp totaal niet waar ie opeens 8 seconden blijft wachten.
Hoop dat ik meer duidelijkheid heb kunnen scheppen.
 
NOGMAALS: een timer die je draait naast een andere activiteit (het laden van een keuzelijst) zorgt per definitie altijd voor vertraging. Omdat de processortijd verdeeld moet worden tussen de activiteiten. Als dat al op een correcte manier gebeurt (wat ik dus niet denk). Daarnaast heeft een insteltijd van 1 ms alleen maar tot gevolg dat het proces van de timer nóg meer tijd inpikt van de rest, en dus wordt de tijd langer en niet korter.
Wat je doet met een Timerinterval (van 1 ms) is op de ingestelde tijd code uit laten voeren. En dat dan, in jouw geval, in een razend tempo. Met een interval van 1000 doet-ie dat elke seconde, wat overigens voor een PB meer dan genoeg is.
 
Laat maar, ga hier geen energie meer in stoppen. Vaak kom je met de beste adviezen maar nu wil je telkens niet lezen wat ik meld en het is goed zo. Ik zal iets anders moeten verzinnen want het kan dus niet. Prima
 
Ik lees prima wat je meld. Het kan natuurlijk zijn dat we langs elkaar heen denken, en dat ik je niet snap. In dat geval kun je je afvragen of dat aan mij ligt (ken jouw situatie niet immers) of aan jou, doordat je het dan blijkbaar toch niet goed uitlegt.

Begin op zijn minst dan eens met je code te laten zien die je gebruikt om in de timer. Want ik heb uiteraard ook niet zo'n zin om te moeten blijven gokken.
 
Ik programmeer 30 jaar dus weet echt wel hoe je je database, tabellen en indexen
Kunnen programmeren heeft weinig te maken met database design of tuning. Zoals Octafish vraagt, even je code en misschien ook de queries en database structuur laten zien, dan kunnen we misschien wel helpen.
 
Lief van jullie echt maar heb de timer uitgeschakeld en mijn verlies geaccepteerd. Heb wel een ander probleem getackeld waardoor het vertraagde en dat was DoEvents. Toen ik dit weggehaald had ging het veel sneller. Iig dank voor het meedenken!
 
Nou mag jij nog even bij jezelf nagaan waarom wij dus altijd om de complete code vragen.... Of denk je dat we dit soort vertragende codes uit de lucht kunnen plukken? Dit soort 'meedenken' is vermoed ik net zo nuttig als Faber vragen om politiek advies :D.
 
Terug
Bovenaan Onderaan