Okay, here's the smoking gun.

Coverage info from the FAST scenario.
(EXE on server share, Windows 7 local)
This is referring to the INIT line of code that calls the AddComboItem 
method.
Line 77 = FOR nnum=1 TO ALEN(tempo)
Line 78 =    thisform.ctGrid.addcomboitem(1,temp.sku)
Line 79 = ENDFOR

    0.000015,form_order,form_order.init,78,\\jock\c\gacs2\gacsutility.vct,5
    0.000009,form_order,form_order.init,79,\\jock\c\gacs2\gacsutility.vct,5
    0.000016,form_order,form_order.init,78,\\jock\c\gacs2\gacsutility.vct,5
    0.000013,form_order,form_order.init,79,\\jock\c\gacs2\gacsutility.vct,5
    0.000016,form_order,form_order.init,78,\\jock\c\gacs2\gacsutility.vct,5
    0.000009,form_order,form_order.init,79,\\jock\c\gacs2\gacsutility.vct,5
    0.000016,form_order,form_order.init,78,\\jock\c\gacs2\gacsutility.vct,5

Pretty much repeats itself (line 78, 79) 23,000 times.

Values range from a
         0.000019
to
         0.000015
with most being
         0.000016

Now, from the coverage log on the SLOW scenario.
(Local EXE file, Windows 7)
Same code, same data

    0.003365,form_order,form_order.init,78,c:\gacs\gacsutility.vct,5
    0.000033,form_order,form_order.init,79,c:\gacs\gacsutility.vct,5
    0.003311,form_order,form_order.init,78,c:\gacs\gacsutility.vct,5
    0.000032,form_order,form_order.init,79,c:\gacs\gacsutility.vct,5
    0.003456,form_order,form_order.init,78,c:\gacs\gacsutility.vct,5
    0.000035,form_order,form_order.init,79,c:\gacs\gacsutility.vct,5
    0.003324,form_order,form_order.init,78,c:\gacs\gacsutility.vct,5

When you go from a 0.000016 to a 0.003365 and you do it 23,000 times, 
you're going to see a slow down.

So, the guilty party is the ctGrid AddComboItem method. But, I knew that.

What makes more sense than anything else is that the Visual C libraries 
on the Windows 7 machine are different releases, dates, sizes, than the 
Visual C libraries on the XP machine.

What doesn't make sense is why running the same code from the network 
share would make it faster. I sincerely doubt that ctGrid is doing 
anything different because of the location it is invoked from. Actually, 
the OCX is the same in both cases...it's in a folder on the local drive 
and registered with REGSVR32. I can't imagine the pain caused by trying 
to register and use an OCX from a network share. Yow.

I'm going to try and summarize this info and send it to DBI in the hopes 
that they'll have pity on me and in consideration for the thousands of $ 
I've sent them they might try recompiling the controls on a newer 
platform. I'm pretty much out of other ideas.

Thanks to all for letting me tap into your brain power! If you come up 
with any other ideas, please share!

The Fox is dead, long live the Fox.

Mike

PS. I'm still hoping that MSoft will need cash someday and will sell the 
Fox rights and source code to someone who will resurrect it. Of course, 
then it would kick VB and Access's rear...

> Mike Copeland wrote on 2011-03-03:
Tracy,
>> I may be misunderstanding your focus, but the AddComboItem loop is in
>> the Init of the form, before the form ever displays. Once the form
>> displays, there are no speed issues and the combo is never loaded
>> again....until a new instance of the form is called for.
>>
>> The code in each of the ctGrid methods and events have to do with
>> recalculating tax (calling a form method) popping up a messagebox if
>> they enter an unknown "off the list" SKU, etc. None of them cause the
>> ctGrid to redraw, adjust, or be modified in any way, either on purpose
>> or not-on purpose.
>>
>> I turned off Windows Themes in the Win7 Control Panel>Personalization,
>> no change.
>>
>> Set sys(2700,1) in the beginning of my MAIN.PRG, and it actually
>> increased the times, on both the FAST and the SLOW scenarios.
>>
>> Bizarre!
>>
>> Mike
>>
> Mike,
>
> No, I think you understood where I was heading. It isn't making sense. There
> was an odd behavior seen once in my application that I've not been able to
> take the time to track down. It is related to VFP 9 SP 2 runtimes on my
> compiled with VFP 9 SP 1. I've not been able to make the time to track it
> down since most clients are not running that configuration. It has something
> to do with a loop process and updating records in tables. No ActiveX
> controls involved, so the scenario is only similar by the SP 2. As I'm
> typing, I recall it was happening on XP workstations too. I don't have any
> more direction.
>
> Since VFP 9, you can capture the coverage profile logging on with SET
> COVERAGE TO... in the runtime.
>
> Tracy Pearson
> PowerChurch Software
>
>
>
>
[excessive quoting removed by server]

_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/profox
OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Reply via email to