Tracy,

Hey, I'm no fan of dancing bears or FLASH! Wait, those are mutually 
dependent...If you want to totally screw up the usefulness of a web 
page, just start adding flash...

Okay, the form is actually one of three that are similar but have subtle 
differences. I'd be happy to send you a screen snap off list. Heck, I'll 
even set up a remote access to the machine I'm testing on!

In the app, there is a QUOTE form, an ORDER form, and a SALE form. 
Obviously to handle the three steps in a sales scenario. There will also 
be a CREDIT, aka RETURN form, but that's irrelevant. All the forms are 
similar, but with different requirements, therefore the different forms. 
In a previous incarnation I had one form that was tweaked and modified 
on the fly depending on the function...pain in the rear!

The forms have no pageframes, the ctGrid is sitting in the center of the 
form, on the form. Hence the code "thisform.ctGrid.addComboItem()

The only other OCX on the ORDER form is ctTOOLBAR, also from DBI. BUT, 
The QUOTE form does not use the ctTOOLBAR OCX, yet. And the QUOTE form 
is also slow to load.

Also, I am seeing the same slow load with the ctMEDIT OCX control on the 
SKU Edit form, which also loads the same 23,000 SKUs in the INIT event 
of the form. Same speed...78 to 80 seconds.

Important to note that my timing only involves the combo load...not the 
data manipulation or retrieval.

Observation: I think it's relevant that I do see SLOWER speeds when 
attempting the same routine repeatedly. The first time, slow or fast is 
X and the second and subsequent executions are X+.
Explanation: Open the ORDER form on the slow setup. Takes 78 seconds.
                        Close, and then re-open the ORDER form on the 
slow setup. Takes 80 seconds.
                        Close, reopen, over and over and it takes 80 
seconds each time.

                         Open the ORDER form on the fast setup. Takes 
.52 seconds.
                         Close, and then re-open the ORDER form on the 
fast setup. Takes .57 seconds.
                         And so on.

Again, seems to be a memory management issue.

There is code in other events of the ctGRID...
     AfterCellExit
     AfterCellWrite
     BeforeCellEdit
     CellDblClick
     CheckClick
     FirstDraw
     LostFocus
     RightClick

I would welcome any suggestions on where to locate, or otherwise 
reconfigure the event coding. I'm not aware of any of the above events 
getting their toes stomped by using the AddComboItem method.

I've been in touch with DBI, but, understandably, they can't recreate 
the problem and when I created a simple form with nothing but the grid 
and a DBF file to load from, it was fast (in the SLOW scenario.) 
Obviously this means that the form has to be part of a larger 
application to cause the gagging to happen.

I opened Debug in the VFP IDE on the Win7 machine, clicked to load the 
form, and it finished about half way through this email. Slow is not the 
word for the thrill of watching your code execute in the debug tracer 
window!

Since I have a machine that can be totally hosed if necessary, I have 
even been tempted to copy some of the older versions of the Visual C 
runtime files from Windows XP to Win7. Any thoughts on that?

Mike

> Mike Copeland wrote on 2011-03-03:
>> Tracy,
>>
>> Many thanks!
>>
>> Yes, I tried the Firstdraw event as that is a pretty common issue with
>> DBI components. And, I was surprised that it made no difference at all.
>> I also tried a few other form events and ctGrid events...I forget
>> which ones now because it was in the wee hours a few days ago. No effect.
>>
>> I'll try dumping the eye candy, although that's going to negatively
>> impact my satisfaction in using my computer! (Don't you realize how
>> important glowing buttons and transparent borders are!!!!)
>>
>> Thanks again! I'll report any improvements.
>>
>> Mike
>>
>>> Mike,
>>>
>>> Move the code to a new method on the form. Then call it from the
>>> ctGrid.FirstDraw event. See if turning off the fancy Windows 7
>>> graphical themes with SYS(2700,0).
>>>
>>> Tracy Pearson
>>> PowerChurch Software
> Mike,
>
> I'm told time and again about eye candy. I'm suggesting a test to see if the
> speed is due to the eye candy.
>
> Explain the full structure of the form this is on. Is the ctGrid object on a
> page in a pageframe, in a container, are other ActiveX controls on the form,
> is there other code associated in events of the ctGrid that might be
> redrawing the control as it is getting loaded?
>
> > From what I've seen the IDE handles memory and UI things a little
> differently than the IDE.
>
> Open the Debug window, then launch the form on the Windows 7. You'll
> probably see it crawl and take over 2 minutes.
>
>
>
> 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