Controls - Progressbar slow / General request

Print Page | Close Window

Progressbar slow / General request

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Controls
Forum Description: Topics Related to Codejock Controls
URL: http://forum.codejock.com/forum_posts.asp?TID=16459
Printed Date: 22 November 2024 at 7:29am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: Progressbar slow / General request

Posted By: fuxi
Subject: Progressbar slow / General request
Date Posted: 16 March 2010 at 8:43am

hi dear codejock team,

i've noticed an issue with the progressbar control:
it seems to slow down the app speed dramatically (vb6) without any cause.

just try:

    progress1.Max = 1000
    For i = 1 To 1000
        DoEvents
        progress1.Value = i
    Next

with a default progressbar (from the ms common controls) it takes < 1 sec
and using the codejock progressbar it almost takes 3 seconds!

what could it be?

2nd - as a satisfied codejock costumer i'd like to ask if it's possible to split up the controls into extra ocx?
when using only ONE control of the whole collection it takes several seconds to load it and really bloats little apps.
i hope you could do this also because there's a subclassing bug in the tabstrip control which causes lots of crashes.

thanks in advance

Replies:

Posted By: pate
Date Posted: 24 March 2010 at 4:14pm

Can someone at CodeJock please respond to this, I'm seeing the same thing. With 3000 items it is the diffference in 1/2 second for the stock MS progress bar and close to 20 seconds for the CodeJock progress bar. And I do NOT have DoEvents in my loop, just updating the value. Unusable as it is.

For J = 1 To 3000
ProgressBar1.Value = J
Next J

Thanks,

Melvyn Pate

registered and on support

Posted By: jpbro
Date Posted: 24 March 2010 at 5:27pm

What other settings are you using on your CJ progressbar? Are you using the SkinFramework as well? What OS?

I'm trying to reproduce the problem, but while the CJ is a bit slower (particularly when using Office2007 mode), it is not nearly as slow as you are seeing.

-------------
Product: Xtreme SuitePro (ActiveX) version 16.2.6
Platform: Windows XP - SP3

Language: Visual Basic 6.0 SP6

Posted By: pate
Date Posted: 24 March 2010 at 5:53pm

http://forum.codejock.com/uploads/20100324_174904_prog_bar_issue.zip -

uploads/20100324_174904_prog_bar_issue.zip

Thanks for the reply. No, completely stripped down VB 6 project, see attached file. And I have seen this on multiple computers at different locations, so it is not tied to just one computer. Using VB6 SP6 on Windows XP.

Not sure why the text is underlined it is doing it by itself.

-Melvyn

Posted By: jpbro
Date Posted: 24 March 2010 at 6:00pm

Maybe you could try only updating the ProgressBar value if 1) The new value is different than the current value, and 2) the new value would actually move the position of the drawn value.

To do this, you could calculate the Max value based on the width of the ProgressBar instead of your real maximum value. Something like:


   Dim l_Count As Long: l_Count = 3000

   Me.ProgressBar1.Max = Me.ScaleX(Me.ProgressBar1.Width, Me.ScaleMode, vbPixels)
   For i = 1 To l_Count
      l_Value = i * (Me.ProgressBar1.Max / l_Count)
      If l_Value <> Me.ProgressBar1.Value Then
         Me.ProgressBar1.Value = l_Value
      End If
   Next i

-------------
Product: Xtreme SuitePro (ActiveX) version 16.2.6
Platform: Windows XP - SP3

Language: Visual Basic 6.0 SP6

Posted By: jpbro
Date Posted: 24 March 2010 at 6:38pm

So there's no question that the CJ ProgressBar is slower than the VB bar, although for me it isn't nearly as slow as it is for you (not sure why).

It seems that the problem likely has to do with how the CJ PB draws the control - my guess would be that the CJ PB completely redraws the control when the Value property is set, even if the new value wouldn't change the appearance of the control. My other guess is that the VBPB is optimized to only redraw itself if the change in value would result in a change of appearance, hence the performance discrepancy.

I've added this to the http://forum.codejock.com/forum_posts.asp?TID=16446 - SuiteControls TODO list .

-------------
Product: Xtreme SuitePro (ActiveX) version 16.2.6
Platform: Windows XP - SP3

Language: Visual Basic 6.0 SP6

Posted By: jpbro
Date Posted: 24 March 2010 at 6:46pm

Also fuxi, what's the subclassing bug you mentioned in the TabStrip? Could you start a new thread with some more information on this (or point me to an existing thread) so that I can add it to the TODO list?

Thanks a lot.

-------------
Product: Xtreme SuitePro (ActiveX) version 16.2.6
Platform: Windows XP - SP3

Language: Visual Basic 6.0 SP6

Posted By: pate
Date Posted: 26 March 2010 at 2:10pm

Thanks, that certainly is a lot better. Still a little slower than the stock MS control, but not unusable. I really hope CJ takes the time to look at little stuff like this bug. I''ve seen it on at least 2 computers (three I think) and the other user reported it, so it is definitely an issue. Just seems like the most basic of controls like this just ought to work and not even have to think about them. Then other times they produce incredible controls like the Docking control, which is simply a thing of beauty,

-Melvyn