 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / Win API / February 2008Need direction on troubleshooting speed issue
Hi, I need someone to point me in the direction to solve the problem below. I have an app I wrote in VB6 that uses the winapi to see text in another application and send keystrokes to it. I've been using this app happily for several years without modifications to the winapi calls since I first wrote it. This past week I installed a new software product required by my employer. Now the time my program takes to do winapi calls has increased from milliseconds to 2 or 3 seconds (the part that ENUMs windows and threads). 2 weeks ago my program performed its task in 1 hour. Now it takes almost 6 hours. Other than getting a different computer, any ideas? 4X <4X@discussions.microsoft.com> schrieb im Beitrag <302288A8-8442-4EA4-AA0F-A2874A3BDA55@microsoft.com>... > I have an app I wrote in VB6 that uses the winapi to see text in another > application and send keystrokes to it. [quoted text clipped - 3 lines] > Now the time my program takes to do winapi calls has increased from > milliseconds to 2 or 3 seconds (the part that ENUMs windows and threads). 2 > weeks ago my program performed its task in 1 hour. Now it takes almost 6 > hours. > Other than getting a different computer, any ideas? Post code.  Signature---------------------------------------------------------------------- THORSTEN ALBERS Universität Freiburg albers@ uni-freiburg.de ---------------------------------------------------------------------- > Hi, > [quoted text clipped - 15 lines] > > Other than getting a different computer, any ideas? Hard to imagine the installation and usage of another program could have that kind of effect. My guess is that it's something else. But since you didn't provide many details, can't say what. Even if this other app creates hundreds of additional windows/threads that your app must now enumerate, I can't see it having THAT drastic an effect (in the terms that you're describing anyway). But, I suppose it's also not out of the realm of possibilities either, depending on exactly what each program does. If you really want help in troubleshooting this, you're gonna have to provide detailed information about each program and what they do (shouldn't be a problem for the one you wrote). But if I were you, I'd be looking into other reasons as to why my program's performance deteriorated so much. SignatureMike Microsoft MVP Visual Basic I installed a fresh copy of XP in a new, bootable partition on the hard drive and installed only the software necessary to run my program. Voila! My program runs great without any recompiling or code changes. If I boot into the old partition it still has the speed issue. Is it possible the last software I installed in the old partition has a subroutine with the same name as one of mine? My winapi calls are in a DLL that I registered myself with regsvr32. My DLL is in a separate directory: C:\program files\MyDlls. >I installed a fresh copy of XP in a new, bootable partition on the hard >drive [quoted text clipped - 7 lines] > registered myself with regsvr32. My DLL is in a separate directory: > C:\program files\MyDlls. Do you send message out to the windows you enumerate? Maybe that app is taking a long time to respond? Otherwise, you'd need to find exactly what call is taking so long. If it's enumwindows which window does it slow down on? > Do you send message out to the windows you enumerate? Maybe that app is > taking a long time to respond? Otherwise, you'd need to find exactly what > call is taking so long. If it's enumwindows which window does it slow down > on? He did not specify that the new program was actually running at the same time. I assumed it was not, you the opposite. My first thought was a "DLL Hell" type problem but if the other program is running at the same time then all bets are off and almost anything could be happening. This should be interesting. Regards Dave O. > He did not specify that the new program was actually running at the same > time. [quoted text clipped - 4 lines] > be happening. > This should be interesting. I think 4X has lost interest in this thread. > Regards > Dave O. Well the next step is obvious, install this other app on this new partition and then see if your app goes slow. If it does you'll need to look at what the new application is installing. It might be worth taking some form of snapshot before installation to find out what's being added on install. The solution might be as simple as installing either the 3rd party thing or your one with ALL of its files in the program folder rather than some in the System32 or DLL folder. If there is a conflict you could rename the conflicting file to eliminate the conflict. However you finally solve this, you must first diagnose what is causing the problem, the clean install is a very good start, now you need to dirty it up a bit! Dave O. >I installed a fresh copy of XP in a new, bootable partition on the hard >drive [quoted text clipped - 7 lines] > registered myself with regsvr32. My DLL is in a separate directory: > C:\program files\MyDlls. I appreciate everyone taking the time to give feedback. I haven't lost interest in this thread but my work schedule has prevented me from working on this problem. It takes me 7 to 10 days to prepare for payroll so that has been preventing me from getting back to this problem. I also support others in this company with their technology so that also gets in the way. The workaround of using a clean partition allowed me to get back to work and make up for the time I lost trying to figure out the problem. The workaround is inconvenient but at least I can work. The program that I am identifying as the culprit is NOT running the same time as my program. I plan to: - copy my working partition and install the problematic software to see if it corrupts again, - copy my corrupted partition and see if uninstalling programs allows it to run fast again, - narrow down my program to the offending line of call to the winapi as opposed to the entry to the subroutine But I won't be able to do this for another week. Thanks again. > Hi, > [quoted text clipped - 13 lines] > > Other than getting a different computer, any ideas? > I plan to: > - copy my working partition and install the problematic software to see if [quoted text clipped - 6 lines] > > But I won't be able to do this for another week. Thanks again. Seems like a reasonable plan of action - let us know how it goes. Good Luck Dave O. > I plan to: > - copy my working partition and install the problematic software to see if [quoted text clipped - 4 lines] > - narrow down my program to the offending line of call to the winapi as > opposed to the entry to the subroutine Download Microsoft Virtual PC, it's perfect for this sort of thing and a lot less hassle (and safer!) than copying partitions around. Michael |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.