Sendkeys problem

Hi,

I inherited an old MS Access 2.0 application which uses Sendkeys to print reports through Acrobat PDF Writer.

At one point in time last year this application stopped working. I managed to get it working again only by deleteing and recreating my user profile located in C:\Documents and Settings\ but which unfortunately meant I had to redo all my ODBC connections and tweak some files and restore the registry of the original user as it must all be as the original user was due to the work involved, hence a lot of hassle. The point was that I managed to get the Sendkeys functioning again by recreating the user.

Just last week the Sendkeys stopped working again. If I login with a different user the application works a treat, and the Sendkeys work perfectly without giving any problems indicating that the application and OS are fine and compatible. This is indicating a profile limitation to me as since I use the application daily and sendkeys hundreds of times a day I must have hit some max limit or size on a file or a count somewhere for this user.

I do not wish to delete and recreate the user as I did last year, but rather would like to pinpoint which file is causing this abrupt interruption so as to maintain it programatically. I cannot find any code workaround for Sendkeys in MS Access 2.0 to perform what I require, so neither is avoiding Sendkeys an option. Neither is changing the application or environment an option.

Any suggestions which file is causing this abrupt interruption to Sendkeys (if my suspicion is correct), or if there is some sort of counter per user which i can reset? I've searched using MSDos for hidden files under the user's profile that could be the cause of this, but to no avail.

Cheers and Thanks in advance,
FrancisP

Unfortunately I don't have much for you here... I've seen profile corruption on small scale before that prevents certain things from functioning, including an issue with PowerPivot that I reported to Microsoft. (I'm hoping that they can figure out what causes the issue I saw.)

I'd be really surprised to find out that there is a sendkeys counter. I think corruption of the registry key or windows setting is far more likely. The challenge is that it's most likely a registry key flagged wrong, but finding it may be almost impossible.

The best advice I can give you is to search google/bing for similar issues. You may be lucky enough to stumble on someone who has seen and fixed it.

I wish I could give you more help here, as I know how frustrating this can be!

Hi Ken,

thanks for taking the time to answer. I'll take up your advice and search for probable registry settings or windows setting as maybe the culprit. Both seem plausable causes to be honest and I've seen such things too in the past. This Sendkeys problem has me stumped of course, as it's hard to identify the root cause.

As a matter of fact, I tried a workaround. I created a VBScript that gets launched through a BATFile (since MSAccess 2.0 does not launch .VBS files). The idea was to have the VBScript grab the MSAccess report and Sendkeys to MSAccess so as to ouput the report to PDF writer. It works if I manually open one report and manually launch the BATFile. But when I execute it through MSAccess the whole things does not execute smoothly since MSAccess continues through it's looping.

I may try creating a VB6 executable that does the same (since MSAccess may launch an .exe created by VB6) but the results in VBScripting didn't look too promising a solution.

Best bet would be to identify the culprit as you suggested.

Thanks and Regards,
FrancisP

Wait... so you can trigger SendKeys via other methods and it still works?

Have you tried putting in a one or two second pause in front of the Sendkeys line? Maybe the system isn't quite ready for the input? I've seen this happen with other programs where Excel executes code faster than the system can actually execute other code...

Hi Ken,

Yes I tried pausing with the same line of thought as you presented. It didn't work. The problem here seems to lie in the fact that MSAccess 2.0 continued with it's code execution irrelevant of other applications current state. Consider the time pause as code execution. This does not seem to allow the VBScript to interact smoothly with MSAccess and since I am looping to generate the data to create the reports then MSAccess is always processing.
After my trials, I'm very sceptical about using external Sendkeys with MSAccess in this context, though if I were to change the whole concept I would get MSAccess to generate and open ALL the reports and once it's processing is complete (and MSAccess is in an idle state) I would be able to loop through the Sendkeys, interacting with each open report to print to PDF (first starting with the last report opened as it will be the one 'on top'), and closing each report in the process. But that would take a hefty bit of recoding, so I'll keep such a possibility as a last option for now.

Regards,
FrancisP

So... I'm curious. Can you edit the code in the vbScript file? Maybe you could create a temp file from there, and then run a do/loop to effectively pause your code until it shows up, then delete it once it does and continue on?

This did cross my mind, but, from what I saw and know, then, whilst MSAccess is in a paused state (do/loop), then MSAccess is still effectively processing code and cannot be interacted with so as to print the report to PDF via the sendkeys.

Yesterday I did a comparison (similar as Unix Diff command) of the 2 User Registries so as to maybe note some thing different.
No luck though

Yes, that would be correct.

I guess installing a different PDF writer (free one) would be out of the question? I'm just thinking that, if you could do that, there are code examples to automate printing PDF's using PDFCreator on this site from VBA. You'd be able to avoid SendKeys all together and have control of the app.

The issue, though, would be that you'd need to either install PDFCreator on all user machines, or write some code that checked for a PDFCreator install and defaulted back to SendKeys if PDFCreator wasn't found.

I get the impression from your first post that this probably won't fly, but figured I'd ask, just to make sure.

Yep you're correct, unfortunately that's out of the question here.
I do have knowledge of creating PDF files via Excell VBA as well as a module in MSAccess '97 which prints to PDF via solely a coding procedure without the use of Sendkeys but, for MSAccess 2.0 the story is completely different as it's pretty primitive compared to the others (or maybe my knowledge of MSAccess 2.0 is limited).

At the moment I can live with relogging another user so as to get the reports generated and sent, but it's risky, as if I ever forget to relog back the proper user then I would risk missing out the night's scheduled tasks which would then require a good 6 hours work to recuperate.

FrancisP

I'd be guessing that the Access 2.0 optionsa are the part that's primitive. Sorry I couldn't offer up any better options. Sounds like a real challenge, this one!