



The February WAMADA meeting was held a week late to avoid conflicting with MADACON. As a result, members who traveled to San Diego had a chance to report on the latest news from the conference. It will suffice to say that no one leapt for the phone to change their current development plans. The expected release of another MacApp update was the piece of news most immediately useful to our members. Component Software seems to be off to a good start with their plan to involve third parties in the enhancement of Component Workshop™. This could become a key weapon in their upcoming battle for market share with Symantec's Think C++. Bedrock is still on the horizon, and the viability of a single framework which provides a "native" look and feel on more than one platform remains barely tested. At the 50,000 foot level (a common Apple metaphor for "the big picture") the concept of writing frameworks to encapsulate your application's knowledge is the latest programming paradigm. Dave Wilson was the most public advocate of this idea, Taligent the most subtle.
Phil Flack of McDonnell Douglas Aerospace showed his code which provides event handling while the mouse is held down in controls. This was used to allow the monitoring of real-time devices which can transmit data to the Mac at any time. Phil overrode Button, CheckBox and Radio controls to set the control's action proc to a function which calls PollEvent during tracking. The key "trick" to making this work is to call Focus after PollEvent has returned. If the routine which is calling PollEvent is performing drawing, you need to also save off and restore the visRgn, clipRgn, and state of the fUpdating flag during the call.
Phil and coworker Mark Gerl also showed some code for a TEventHandler class called TTimedHandler which serves as an intermediary for TBehaviors on the application's idle chain. Since TBehaviors are not descended from TEventHandler, they can not directly be part of the idle chain. By using a TTimedHandler, a TBehavior can indirectly add itself to the idle chain. The TTimedHandler just passes the DoIdle call through to the TBehavior. Lastly, they described how the use of a state machine within idle methods can be used to break up processing of lengthy tasks without destroying the responsiveness of the user interface.
In the case of MV the functionality provided is the ability to recognize the arrival of messages and associated data from remote machines (usually mainframes) and then call your code to handle the message and its data. Its primary market is people who need to use "legacy" applications (all those mainframe COBOL applications which communicate with hardwired terminals) on their micros. Dan explained that MV views the remote system as a non-sequential, non-deterministic state machine and attempts to linearize the complexity of moving between states. MV works asynchronously (hmmm, I see a trend here!). It accepts input from a variety of communication services (SNA, TCP/IP, etc.) examines the "presentation" of the data (sort of a generalized terminal emulation) and matches incoming patterns with pre-built messages which it then sends to you. MV is able to update itself on the fly, from information provided by the sender, if a new configuration is needed to handle changes in the presentation.
To support MacApp, Mitem provides several C++ classes, along with code which is installed in your application as resources. The MV communication objects are not part of the target chain. This allows interactions with the remote machine to work in parallel with user interface activity. When MV recognizes a pattern it sends your code a message in the form of a message name. This name is turned into a method call by way of a registration table which your application builds. The result is that your application becomes a sort of way station between two users: the person running it, and the remote machine sending in data.
In combination with the previous month's discussion of handling asynchronous I/O, I found the asynchronous nature of MitemView its most interesting feature. Dan showed that responding to messages from MV in the proper order can improve response time, by taking the remote machine's processing time into account. As operating systems (including the Mac's) move towards providing multi-threading and multi-processing services, those of us who long ago became comfortable with event-based programming will have to take the next step to working with these new services. Thinking back to MADACON, I don't recall many vendors touting multi-threading as a factor in the design of their frameworks (SmalltalkAgents is the only exception that comes to mind). Let's hope this changes as fast as the new OSs change.
If you're in the D.C. area, and interested in object oriented programming, give WAMADA a visit. We meet every third Wednesday at McDonnell Douglas in Tyson's Corner, Virginia, beginning around 7:15 p.m. For a map, send a message to JEFFRIES.L on AppleLink, or call Leslie at (301) 340-5126 during business hours (EST).



