×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

ReceiveFile method dies

ReceiveFile method dies

ReceiveFile method dies

(OP)
I am trying to transfer a file in myExtra 7.11 from the mainframe to my desktop using VBA in Excel. My first step was to simply use myExtra's macro recorder while I did the transfer. The part of the macro that initiates the transfer is as follows:

    ' This section of code contains the recorded events
    Sess0.FileTransferScheme = "C:\Program Files\Attachmate\E!E2K\Schemes\ENU\Text Default.eis"    
    Sess0.FileTransferHostOS = 1     
    Sess0.ReceiveFile "C:\Documents and Settings\T78384\Desktop\DOWNLOADS\EXPORTED.TXT","T78384.EXP.DATA"    
    Sess0.Screen.WaitHostQuiet(g_HostSettleTime)
    System.TimeoutValue = OldSystemTimeout
    ' This code was added to give VBA something to look for when the macro is done.
    Sess0.screen.PutString "DONE", 10, 1

When I call the above macro through the shell, it works reliably. Now I need to move this code into VBA. I switched out the line that calls the macro with the following code:

    'Sess0 is the same object as in myExtra Basic
    Sess0.FileTransferScheme = "C:\Program Files\Attachmate\E!E2K\Schemes\ENU\Text Default.eis"
    Sess0.FileTransferHostOS = 1
    Sess0.ReceiveFile "C:\Documents and Settings\T78384\Desktop\DOWNLOADS\EXPORTED.TXT", "T78384.EXP.DATA"

For some reason, the same code doesn't work anymore! It doesn't give me any errors compiling or running. I've tried filling it up with all sorts of delays, and that doesn't affect it. Finally, I tried stepping through it with F8. It just gets to ReceiveFile and continues on without any feedback at all.

Any ideas?

RE: ReceiveFile method dies

I'm having a similar issue that I've been unable to resolve. My issue seems to be on a specific users computer. All other users don't have any problem running the code. Additionally, if I step through the code on the culprit computer it works fine.

I wrote this off as one of the quirks of Extra. I moved the code to another user because I had that option.

calculus

RE: ReceiveFile method dies

(OP)
Craziness. :o Sadly, I don't have the same option. :/ Thanks for the response though!

I found a sloppy work-around in the mean time. Basically, I left the macro in Extra Basic, and when I need to transfer a file, I simply call that macro from the commandline. There are two down sides though:

1. Because I send the data for the transfer to the macro by writing to the screen in VBA and having the macro read it from the screen, there's extra code. It doesn't run as fast or as pretty, but it's adequate.

2. The only way I've found to detect when the macro is done (so VBA can continue) is to have the macro signal back somehow. I have the macro log out when it's done, and have VBA patiently wait for that screen.

Unfortunately, that brings up a related problem I've been having. -_- Some of the users have startup macros. Since I didn't write the startup macros, I have no way of knowing when myExtra is done running them! I've looked over every property and method I could find - and I just can't find a way!

It would be so much easier there was a collection like "Sess0.activeMacros" so I could get a count, or just an integer like "Sess0.MacroStatus". But there isn't.

Any ideas? :)

RE: ReceiveFile method dies

When I run an Extra macro it displays in the processes as ebrun or ebmngr depending on how they were launched.  You should be able to count the number of those process and if you want/need terminate them.  It'd also be a more effective way for determining when the VBA can continue.  When your ebrun process is finished, then continue with VBA.

For your issue where you drop the information on the screen, you could drop it in a file and have the EB read the file.  I'm not sure how important this is though.  You also have the option of sending arguments to an EB macro.  See the Command[$] function.

RE: ReceiveFile method dies

(OP)
Do you have any suggestions on how to detect whether ebrun/ebmngr are running?

I'd rather not deal with any more code in Extra than I have to, since it's less than friendly to debug and the code I have now works AOK. Sending the arguments on the command line isn't something I'd considered; if I get some time in between projects, I'll go back and try that.

Incidentally, I finally got this project up and running! Woohoo! I really appreciate the advice you both gave me. Also, I hope NEVER to deal with Extra again after this. ^_-

RE: ReceiveFile method dies

You can run this in VBA.

CODE

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
  & "{impersonationLevel=impersonate}!\\" _
  & strComputer & "\root\cimv2")
Set colProcesses = objWMIService.ExecQuery _
  ("Select * from Win32_Process Where Name = 'ebrun.exe'")
For Each objProcess in colProcesses
  MsgBox objProcess.CommandLine
' To Kill
' objProcess.Terminate
Next

RE: ReceiveFile method dies

(OP)
Thanks, Skie. That code works great! Of course, it turns out that everyone in my office has a startup macro that types two characters and enter. And it takes a relatively long time to start and resolve. By the time the code runs to end the process, the macro may or may not have gone off, and it just makes for an annoying problem.

So I'm gonna sweep this solution under the rug and use the problem as an excuse to get them to deactivate that inane startup macro. Still, I'm keeping this code for later. I'm sure it will come in handy.

Thanks again!

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close