[VB6] GUI hangt bij lange verwerkingen

[Verwijderd]

Ik heb hier een oude app die wat aangepast moet worden in VB6. Nu worden er hier enkele langdurende queries in uitgevoert. Dit zorgt ervoor dat de GUI enkele seconden blijft hangen waardoor de gebruiker denkt dat de applicatie crasht, en het ziet er natuurlijk ook een beetje onbeholpen uit op die manier.

Helaas is het geen optie om deze app te porten naar .NET. En aangezien VB6 ook geen multi-threading kent vroeg ik mij af of mensen een andere manier weten om dit probleem op te lossen.

[PhysicsRules]

Kun je wat meer info geven over de queries. Wat voor database is het, wat voor connection gebruik je. Is het een lange database query of is de VB code waarin de query staat sowieso traag?

Als de vertraging in de VB code zit, is DoEvents je vriend.
Als de vertraging in de databasequery zit kun je eens kijken of die een async optie heeft.

[Verwijderd]

PhysicsRules schreef op maandag 20 november 2006 @ 15:49:
Kun je wat meer info geven over de queries. Wat voor database is het, wat voor connection gebruik je. Is het een lange database query of is de VB code waarin de query staat sowieso traag?

Als de vertraging in de VB code zit, is DoEvents je vriend.
Als de vertraging in de databasequery zit kun je eens kijken of die een async optie heeft.

Een Access DB via een ODBC koppeling...

Connectie in vb6:

Set conn = New adodb.Connection
With conn
.Provider = "Microsoft.Jet.OLEDB.4.0"
.ConnectionString = "data source=" & Database
.Open
End With

een query is bv:

INSERT INTO backuptabel SELECT * FROM normaletabel

Dit om een backup te maken voordat weer een ander proces wordt gestart (maar dat is niet relevant opzich)

Deze query duurt ongeveer 5 seconden, maar wel 5 seconden 'hangt' mijn app.

[ Voor 12% gewijzigd door Verwijderd op 20-11-2006 15:54 ]

[urk_forever]

Misschien een idee om je select en je insert te scheiden. Dus eerst een recordset ophalen met behulp van SELECT * FROM normaletabel en vervolgens door die recordset heenlopen en voor elke record een insert into doen. Tussen door kan je dan een DoEvents of een repaint oid doen.

[Verwijderd]

urk_forever schreef op maandag 20 november 2006 @ 16:06:
Misschien een idee om je select en je insert te scheiden. Dus eerst een recordset ophalen met behulp van SELECT * FROM normaletabel en vervolgens door die recordset heenlopen en voor elke record een insert into doen. Tussen door kan je dan een DoEvents of een repaint oid doen.

inderdaad een optie, ga ik even proberen

[PhysicsRules]

Heb je iets aan de adAsyncExecute optie van ADODB.Command.Execute ?

Visual Basic 6:

dim cmd as ADODB.Command
cmd.Execute , , adAsyncExecute
Do Until cmd.State <> adStateExecuting
DoEvents
Loop

(eerlijk gevonden op http://forums.devx.com/archive/index.php/t-145060.html)

[Ciqniz]

Sowieso is het misschien verstandig om de gebruiker te laten weten dat het programma 'bezig' is. Progressbar op je form, en updaten&refreshen bij elke vordering.

Dat zou moeten werken.

Gebruikers zouden dan in ieder geval minder de neiging hebben verder op knopjes te drukken.

Mocht dat toch gebeuren, komen die requests toch alleen maar bovenop de stack. Die worden later dan alsnog uitgevoerd.

Je zou kritische knoppen uit kunnen schakelen en weer in kunnen schakelen als de bewerking voltooid is.

[PhysicsRules]

Ciqniz schreef op dinsdag 21 november 2006 @ 11:02:
Sowieso is het misschien verstandig om de gebruiker te laten weten dat het programma 'bezig' is. Progressbar op je form, en updaten&refreshen bij elke vordering.

Dat zou moeten werken.

Gebruikers zouden dan in ieder geval minder de neiging hebben verder op knopjes te drukken.

Mocht dat toch gebeuren, komen die requests toch alleen maar bovenop de stack. Die worden later dan alsnog uitgevoerd.

Je zou kritische knoppen uit kunnen schakelen en weer in kunnen schakelen als de bewerking voltooid is.

Een progressbar gaat niet werken zolang je query de thread kanabaliseert. Dus TS zal eerst de query moeten aanpakken.

[roy-t]

code:

Screen.MousePointer = vbHourglass
'query
Screen.MousePointer = vbNormal

Lijkt me de netste code, de gebruiker zal nu wel geduld hebben om te wachten, ook zou ik wel proberen de code sneller te maken, maar ga er van uit dat als het programma op verschillende pc's gebruikt wordt, op sommige langzamere pc's er nog steeds vertraging is als je het geoptimaliseerd hebt.

Suc6 met je programma

[Ciqniz]

Ok, zit wat in. Leesfoutje.

Dan zal dat idd niet gaan helpen. Zoals ik al zei, alle vitale onderdelen uitschakelen. Zet ff een label on top met "Please wait", zandlopertje erbij en na bewerking deze dingen weer annuleren.