On FOCUS

by Mike DeVoe

For those of us who have worked in FOCUS, we know MEDITECH will fire up and close multiple instances of the FOCUS client as we navigate through the system.  The sign-on process and main menu navigation is one instance of the FOCUS client; if you launch into an application, MEDITECH starts a second instance of the FOCUS client.  This reminds me of an old technique in the very early days of personal computing called “chaining.”  I’ll date myself here; Applesoft BASIC, Commodore 64 BASIC and IBM BasicA all offered a “Chain” command.  You’d chain programs together to conserve memory and give the user the impression they were running a single application.

Although MEDITECH doesn’t need to worry too much about conserving memory, they probably still want to give the user the impression of a consistent, single application.  Aside from cluttering up the taskbar, I can see how this helps them “chain” together different technologies.  For example, B/AR is still a C/S application in 6.0, so your FOCUS client launches the C/S client application and it appears to be one continuous session to the user.  I suppose savvy users can take advantage of this by signing on once and then branching all over the place with multiple child sessions.  However, I think the typical user sees this as a single application and doesn’t go branching off in multiple directions.

Keeping track of all of these sessions can be a real headache for those that develop scripting tools.   Just following the application as it chains from one instance to the next is quite a trick.  Since I don’t even want to think about branching off in multiple directions, I don’t.   The scripting tool works just like the typical user sees the MEDITECH session.  It drills in and then backs out.  Inside the scripting tool, FOCUS behaves as a single application where we’re simply stacking windows as we go in, and then removing them from the stack as we back out.  It doesn’t matter if those windows go across different applications; the scripting tool presents it to the script programmer as a single application.

This is consistent with the role of a scripting tool.  The idea is to take something inherently technical, such as following an application as it chains to multiple instances of itself, and boil it down to an idea of stacking and un-stacking windows.  Sure, we lose the ability to branch in multiple directions, but I can’t imagine why I’d want to do that in a script and I certainly don’t want to think about what that script code might look like.  I’m content to let the scripting tool work the chain gang for me and I’ll stick with writing scripts.

Related Posts

• March 19, 2010 -- We Ain’t Afraid of No Mice (0)
• March 17, 2010 -- The ForUpdate Mutex (1)
• November 25, 2009 -- It’s a MAD, MAD, MAD, MAD World – Part I (6)
• November 9, 2009 -- FOCUS: When/Where (1)
• November 4, 2009 -- Perspective on Scripting in FOCUS (1)