Putting some feelers out there for the best way to launch a 2nd, 3rd... ATE session from with in a running ATE. (I think its possible and some of you guys have done so).

For example:
* Click on ATE icon on PC Desktop and Launch the first session with a menu.
* From this 'menu' they select a program this then launches another ATE and runs the selected program (leaving the original Menu/ATE running wht they could toggle too) this then can occur x times more from the menu/first session.

So looking for:
* ATE/Unix (not Windows)
* Best XCALL ATE launch command to use.
* Uses the same ATE profile as the first.
* Can we use some type of parms to pass info from the original to the newly launched ATE. Like PPN, program to run. etc.

Well hopefully you got the jist of it.

Thanks.

The ATE sessions would not know about each other so there would be no interactivity between the 2. Plus, launching a new ATE session would be pretty slow and anything over 3 instances from the same computer would use a new A-Shell license.

Is your goal to run multiple programs at once? If so you might be able to accomplish that by creating new instances on the server-side which would share an ATE instance?

As for the Profile, you can get the profile by use AG_GETENV, and retrieve %ATEPROFILE%. You probably want to use MX_AGWRAPPER for this call.

Hi Stephen, Thanks for the input, Yes they my initial thoughts too (especially speed).

We currently use XCALL HOSTEX,"$ASHELL -e -q to launch a temporary instance but this hold the current program up til they return.

Instead we looking to allow users to easily launch multiples programs in different windows, I thought this way may be better otherwise I think i'll end up with a can of worms with what controls and xtrees are currenty on the ATE screen while the customer runs off to another program and comes back x time later. (if that makes sense) I would also need to allow the 'menu' option from every program too somehow.

Sounds like you are reading my mind...

I have been toying around with this idea with Jack for a few months.. sort of to give the user the ability to task around different sessions from within the same ATE/Menu session. In fact, some of my new logic is working towards populating a pseudo-taskbar on the main screen that shows launched programs.

The trick is to control how the user can switch between tasks or end them. Since the challenge here is to send an exitcode that can be seen across completely unique sessions. I think Jack added something a little while ago like the old MULTI feature but I haven't researched that.

Launching new ATE sessions could take a few ticks like Stephen said. But that would give them the ability to swap and not have the programs stack like we and you are currently doing. There is something to be said for this because it does control what the user can do concurrently, however, its not a real windows task switcher.

I will stay tuned to this bat-channel to see what transpires!

One problem with running multiple server-side sessions sharing a single ATE connection is that ATE itself doesn't know one from the other. It might be possible for the server-side sessions to manage switching between them by clearing/saving and restoring/rebuilding all the GUI controls when switching between the sessions, but this is likely to be unsatisfying (too complex, slow, prone to error, impossible for the user to see more than one screen at a time, etc.)

At the opposite extreme, having entirely separate client-server pairs (i.e. a separate instance of ATE and a separate connection for each server-side instance) suffers from being a bit slow to initiate (each new connection/login typically takes a few seconds). But once they are set up, you can quickly toggle between them with the grave accent (as well as the Windows ALT-TAB), and you can even view two or more simultaneously. So if you're going to have the session running for more than a few seconds, having to wait for the initial connection is probably worthwhile.

As for passing it launch arguments, it's a bit tricky, since the command line being passed is really the ATE TELNET command line. Beyond that, the commands passed to the eventual new session on the server would be those from the login section of the ATE profile. For example, this would launch another session using the current profile:

Note that if you add any additional arguments beyond "$ATE", you'll need to specify the profile you want. Otherwise it uses the default profile which as Stephen noted is %ATEPROFILE%.

The problem is that any additional stuff on the command line is coming to be consumed at the wrong level, i.e. by TELNET.LIT, not by the new server session. For example:

The above is equivalent to the previous example (since "$ATE" by itself expands to "$ATE -ate telnet %ATEPROFILE%", and since the additional part of the command line "\nCMD2" is never going to get processed because TELNET.LIT is not looking for any further input beyond the profile.)

So to actually pass a new command line to the new server session, you'd need to either build a new profile in the client registry, or, change the server-side login profile to contain a new launch command. Actually, if using that approach, it would be better to adjust your standard login profile to execute a startup command from some other shell script that could be more easily changed on the fly. But even then, it would be tricky to manage multi-user access, unless every user had a unique login (which they should) and a unique shell script tied to it.

In that case, for example assuming user 'steve', you would modify the steve-startup shell script prior to launching another session, which would then execute that shell script to customize the ashell launch. A bit convoluted perhaps, but probably workable.

Otherwise you'd need to use some kind of inter-process communication scheme whereby the new session was able to query the main session to find out what it was supposed to do. Practically speaking, the easiest solution to that would be a common disk file named after the user (or with records keyed to user logins), so that each new job could check to see if it had any special startup marching orders. If not, just proceed with the normal main menu, otherwise do whatever the orders dictate (and immediately reset the file/record to the default for the next login). This would work as long as you wouldn't have overlapping/asynchronous logins for the same user. The gray area would be if the user launched two new sessions so quickly that the 1st one hadn't yet logged in (and picked up its startup commands) before the second one was configured (i.e. clobbering the first session's startup commands before it could read them). But you could easily handle that by just delaying any new session launch until either the startup command for that job had been cleared, or some timer expired (suggesting that the launch didn't succeed).

As an aside Frank has been working on a hybrid solution to this kind of problem, which uses a single ATE session, and XCALL HOSTEX to launch programs from the menu which position themselves in a borderless dialog within a TAB panel within main window. The goal is to end up with something like you have in a tabbed browser, with one main window, and several independent sub-windows. But it's requiring a fair amount of program redesign, not to mention a lot of bleeding at the edge, so I wouldn't recommend undertaking it lightly. (I guess our posts crossed.)

That's true, forgot about opening up a new program in its own tab. It looks very clean and seamless, and is a great option as long as you are ok with the stacked application idea. Although, i suppose you could be really smart and check for tab clicks from within any application and do the appropriate tab-pane switching.

One thing i learned in approaching our new UI is that populated ATE/GUI controls that are on the screen are potentially available to any programs running them. So, for instance, if you create this tabbed idea, and code the panel exitcodes such that your global answer/eventwait routine understood the exitcode you could handle your own task-switching. Killing the primary parent program however would also kill the child processes. But perhaps this is not a heavy price to pay for providing this feature.

Currently the way i use this is to open a child process which the user muse exit before returning to the parent program. The child process opens in a new tab which gives the illusion of a windows-tabbed session, like IE.

It is a little bit of a challenge if your code is older, like ours, getting all the object and parent id's in order, but works like a champ if all i's are dotted and t's are crossed. Jack has even added save/restore panel option which keeps recent screens in memory so upon returning from the child process its easy to repopulate the active panel w/o actually re-writing each field from scratch.

PS: When i get a few minutes i will post some before and afters with using some of the new controls.

Thanks Guys for all the input here, i'll have a play over the next few days.

The following command of:
did launch another ATE nicely, but will need to play with it a bit, the speed was not too bad (and im currently not in the office and working over a VPN)

Maybe the unique key here is the IP Address (but may have see if thats true still under Terminal Severs etc)

Once logging on I could lookup as you say Jack a common disk file/INI File named after the user or ip address and then decided what to do from then..

Thanks, i'll have a play and report back...

Thinking about it could create a unique key in the PC Registry when the first ATE session is launched and they all use this instead of ip address/user name.

Two questions:

1) when launching with xcall MIAMEX, MX_AGWRAPPER should ATE still read and use the profiles ash settings for window position? - I ask as my ATE is running on my 2nd PC monitor and when I launch one with MX_AGWRAPPER it popup half the size on the main monitor. (not like launching ATE from its icon)

2) After launching with MX_AGWRAPPER the original ATE have the focus moved back to it and you have to toggle or click on the newly launched session. (Im sure per design, but any switch to stop this?)

Thanks.

OK make this a 3rd question:

Is it possible to have a new built in ATE menu option (Next to File, Edit, Settings, Help) and when clicked will call xcall MIAMEX, MX_AGWRAPPER, AG_WINEXEC, "$ATE", RESPONSE (or something on those lines) similar I guess to the print screen. This way its a fast way to launch another ATE and also no need to modify a zillion programs.

Or better still have a bunch of menus like so with a list of pre-define menu options that launch and automatically writes a small INI file to say c:\ATE folder (or PC registry) with the selected option, then this can be read by the newly launched session and know what to do.

Anyway, just thoughts and thinking out loud.

Hey Steve - when you launch a new ATE session, are you just having the user use the windows taskbar to switch sessions?

Are you closing this session automatically or how does it end after the new process is complete?

Hi Frank,

The user can toggle and switch between ATE sessions them self, and the session its launched from would continue running what ever program it was in as usual. (so really its becoming a fast way to launch another ATE windows and straight into a program)

1) Yes, it should use the .ash profile from the original ATE session, but it depends on the command line being "just right". Otherwise it will revert to the A-Shell default profile. (You can verify which profile it used by going to the File > Save dialog, which shows the name of the profile that it loaded from.) See answer to question #2 for more...

2) AG_WINEXEC tries to get the focus back (yes, by design). Seems like there should be a command modifier to control that, but I don't see one. However, you can switch to MX_SHELLEX , which does support such an option (waitflag=0)...

Several notes about this command:

- Double-quoting of the %ATEPROFILE% needed to avoid tokenization errors if the profile name contains spaces.

- We're using the special command name $ASHELL. (In theory $ATE would work the same, but there is a slight glitch getting in the way of that; will be fixed in 1341.3 but $ASHELL avoids the issue.

- The "C" flag forces MX_SHELL to operate on the client (ATE) side, rather than the server.

- This combination also results in it loading the proper ATE settings file so the new window should end up in exactly the same position as the current window started in.

3) Yes, you could put the launch command on the menu. The MBF_SHLEXC menu handler is rather limited, so I would suggest going with the MBF_CMDLIN mode, i.e.

Arguably, the macro $ASHELL should work here instead of %MIAME%\bin\ashw32.exe but for some reason it doesn't. (Perhaps that will be fixed in 1341.3 as well.)

Thanks Jack for info and help, Both the xcall MIAMEX, MX_SHELLEX as well as adding it to the menu worked great and both look like they using the current ATE settings/profile and pop up over the top nicely.

I've had a play and a proof of concept that looks like it would work well.

Now im not sure how possible this is, but I think the ideal way would be adding several programs to the menus, for example:



But as they all execute the same ATE launch code but just have different 'descriptions' im not sure the best way would be to write a to a small INI file or PC registry to say what item was selected so the newly launched ATE knows where to go... :rolleyes: - possible? or shell I look into another solution?

But I am also s-l-o-w-l-y talking myself into have just one menu option of Launch New Session what then launches a new ATE and display a selection of menu choices in a XTree. (I guess its just one more click) but less technical as we not need to pass the menu option clicked across. :rolleyes: :rolleyes:

It does seem that it ought to be easier to customize the ATE startup via additional keyboard characters without having to jump through so many hoops.

I think I have it worked out to allow you to append keyboard characters to the end of the telnet command line, i.e.

where the leading "^m" would be interpreted by TELNET as the end of the configuration profile name and the start of type-ahead, with the remaining "OD^m", "OCD^m", and "SD^m" forced into the keyboard buffer after all of the startup commands contained in the connection profile (and with "^m" converted to ). Your startup menu program could then input them and proceed to the desired option without troubling the poor beleaguered user for so much as a click. (To really make the startup clean, your program could use something like TINKEY or GETKEY(0) to check for the typeahead before even displaying the menu.)

This is going to require an update to ashw32.exe and telnet.lit; probably in 6.1.1343.0 (in the not-too-distant future).

Now that's very much talking me back towards the ATE menu route again that's sure useful, thanks...ill keep an eye out for the update.

Thanks Jack for posting 6.1.1343.0 (and a full ATE update/install) - I'll have a play...

Jack your change is working well Thanks.

One thing (there always is one more thing eh)

This could well be my following syntax nut its picking up the default ATE profile not the one its launch via.

It sending: A B D perfectly as well as keeping the previous session running with the $ command.

Would you have a suggestion why TINKEY does not capture the keyboard buffer, but if I use ACCEPT it works fine.

I'll be happy keep using ACCEPT but as it stops and wait it need a C/R or something from the user to move it on. (Is GETKEY() a function rather than a xcall as I never got this command to work at all)

To answer your last question first, here's a test program to play with:

To test tinkey, I added RUN TINKEY to the end of the START.CMD in the directory where my default connection startup leaves me, and then added a menu to launch a new connection with:

And here is what I see:

(The only key I hit was the ESC at the end, after waiting 3 seconds, but you can see from the time stamps that the other characters were all in the buffer ready to pluck.)

As for it picking up the default.ash, I'm not seeing that problem. (My File > Save dialog shows current settings loaded from %APPDATA%\ATE\Jack Test.ash, and Jack Test is the name of my profile.) What you're seeing would be consistent with you not ever having saved an %APPDATE%\ATE\RS6000.ash. (A-Shell and ATE will use the default.ash unless there is one more specific to the current launch configuration/profile. Go ahead and save it as RS6000.ash and then try your test again.)

* Well your example worked here too! so must be operator error (Steve slaps himself) and will compare logic.. (Thanks)

* Regarding the profile I have the following under Save Settings:
%APPDATA%\ATE\rs6000.ash on the main ATE, when I launch aniother session this is what it shows: %APPDATA%\ATE\default.ash (see screen shot above)

My launch code is :

I was able to reproduce the default.ash problem on your system using your launch code. Not yet sure what the difference is between it and the very similar test/code on my system where it works, but I'll study it later today and hopefully have a fix by tomorrow.

OK, glad it was not my imagination.

btw, I think it was the xcall NOECHO (or lack off) messing my TINKEY. - But it works now.

OK, the problem is just a missing space in your command line. (You need a space after the name of the profile, e.g. ""%ATEPROFILE%%" and the appended character string "^m+STEVE4+^m".)

Admittedly the syntax here is starting to take on a Byzantine flair, but the main ashell command line parser is simply tokenizing based on space delimiters, so without the space it thinks your ^m etc. is part of the profile name token. That's messing up the search for the .ash profile even though TELNET (which is looking for the "^") is able to sort it out and thus make the connection.

I'll update the doc to clarify the need for the space.

Well spotted! and after adding the space it works great. Thanks for all the help.