help desk software
+(800) 286-4232 info@ratchetsoft.com

In most cases, Ratchet-X works fine when used to
integrate applications that are running on a remote desktop like Citrix’s
XenApp, VMWare’s ThinApp or Microsoft’s App-V. In these cases, it’s common to
deploy Ratchet-X itself on that remote desktop along with the target
application to be integrated. To the end user, he would never even know that
either application is deployed remotely. The Ratchet-X Commander icon still
appears in its usual spot in his windows system tray. Interacting with it
seems to be the exact same experience as if it were installed locally. However, it’s important to remember that Ratchet-X
is deployed remotely and only has access to other apps running on the same
remote desktop. Applications running natively on the actual desktop cannot be
accessed by the remotely deployed Ratchet-X Commander or visa versa. Or can they?
We’ve been using a technique that allows us to
bridge this gap. For example, imagine there’s a line of business application that
is deployed as a Citrix XenApp. We want to place a magic button on that XenApp
when the user navigates the application into a certain state (e.g. Invoice
Summary Window). We define a RegWin for that window and save it into an
appspace that we register with Ratchet-X running on the remote desktop. That method
handles the screen recognition and appearance of magic button. When the magic
button is clicked, Ratchet-X runs the action on the remote desktop that needs
to (somehow), load an application on the actual workstation and do some
navigation (we call this the Jump2 pattern). Now this is  where the problem lies. Although we currently we have no direct way
to communicate between these two desktops (though we’ll soon have an elegant
solution that universally addresses this problem across all remoting desktop
solutions without being vendor specific), we do have a pretty clever integration
technique that can be used as a stand in. The technique involves the passing of
this data from the remote desktop to the local desktop using a built-in feature of our
Action API.  
When called, the method WaitForScreenDataTransfer, found on the ActionContext object, loads
a window on the desktop which displays text data you pass it. This window loads
offscreen (not visible) or center screen (visible), and simply waits until the
user closes it (click window close button). This proves to be an effective way
to transfer some limited data (up to 4K), from the remote desktop to the actual windows
desktop. It works because the remoting software (XenApp, etc..) faithfully
copies the titlebar text over to its virtual window running on the local desktop.
Now this window titlebar text data can be seen from Ratchet-X running on the
local desktop. We simply need a RegWin on the local desktop’s Ratchet-X which
we can register as an “Auto-Run” and associate it with a local
action. That local action simply reads the titlebar text from the RegWin that
auto-ran and goes about its business as usual – accessing any resources it
needs on the local desktop.  
To summarize, here are the high points of this
integration:
From the User’s Perspective
Behind the Scenes
User
loads his accounting application and navigates to the Invoice Summary window
and the magic button displays on the titlebar.
Ratchet-X,
running on the remote machine detects a known RegWin and displays the magic
button.
User
clicks the magic button.
Ratchet-X
running on the remote machine starts to run an action on the remote desktop
which calls WaitForScreenDataTransfer and passes in an invoice number. This
displays a window (virtualized and available on the local desktop but not
visually seen because its loaded off-screen. Then, Ratchet-X running on the
local machine detects the ScreenDataTransfer RegWin and auto-runs another
action on the local desktop. That action reads the invoice number from the
ScreenDataTransfer RegWin and loads a local document management executable to
display the appropriate document on the user’s local desktop.
User
sees invoice document appear.
If you want to try this yourself, take a look at a sample appspace that ships with Ratchet-X demonstrating this technique. In
Sample Appspaces, register the RatchetX.ScreenDataTransfer appspace. This appspace
contains a RegWin that matches the window created by the ScreenDataTransfer
window. In the field, you’ll need to make your own RegWin that matches the
window as displayed by your remoting provider.