|
| |
| Volume
12, Number 2 |
Spring
2002 |
Winchester,
Virginia |
|
|
Unibase
by DMAC, Release 7.4ai, Sneaks Into Existence Quickly |
|
With
several development projects running concurrently, and clients
wanting new features faster and faster, DMAC solved the naming
dilemma by going from Release 7.49i to 7.4ai. Now we can use
7.4bi, 7.4ci, etc.).
DMAC
never changes the first two digits (7.4) unless the persistent
file structure changes. Clients want to load new executables and
go, not upgrade to persistent files. DMAC listens and 7.4ai is
the result.
DMAC
release 8.0 with XML persistent files and backward compatibility
with 7.4xx persistent files was delayed so that some “neat new
features” could reach users this summer. See the new feature
articles in this issue.
BACK
TO TOP
|
|
“Beep”
Goes Unibase For All To Hear, Always |
|
Users
continue to want to get a beep through various operating
configurations regardless of what hardware and operating system
they are using. So DMAC has added yet another way of getting a
beep.
In
Windows NT and Windows 2000 and Windows XP, the exclamation beep
now is also sounded when a Unibase beep is required. On the
windows control panel this beep can be turned off if the user is
content with the Unibase beep controlled by the beep variable in
the unibase.ini environment.
Of
course, if a user puts the “Charge of the Light Brigade” as
the users’ exclamation beep, the place will become noisy.
No
doubt, this feature will change again as users come up with
better ways and less noise.
BACK
TO TOP |
|
Downloadable
Unibase by DMAC Comes to Web |
|
As
hoped and planned, potential users can now download an
evaluation edition of Unibase by DMAC and a basic tutorial
manual from DMAC’s web site. This summer Unibase Imaging and
an imaging tutorial will be downloadable from the web site as
well.
A
lot of issues were resolved to make this happen.
First, DMAC decided that the downloadable version would
run for thirty days on a Microsoft Windows computer on which
Unibase by DMAC had never previously been loaded.
Second,
to upgrade to a version which would last beyond thirty days
requires a download of additional files.
Third,
only the Unibase capabilities necessary for completion of the
tutorial are included in the download in order to make the
download file size as small as possible. Only the most
sophisticated users would be aware of the difference between the
downloadable evaluation edition and the full blown Unibase.
Fourth,
the downloadable version loads onto the “C” drive as a
standalone copy. This made the installation program simple
enough that we had some chance of it working every time on all
Microsoft Windows operating systems (95,98,ME, NT, 2000, XP).
Fifth,
only the 32-bit version of Unibase by DMAC is included in the
downloadable version.
Interested
parties will be able to do a thorough, basic evaluation of
Unibase by DMAC and Unibase Imaging. If they determine that
Unibase is worthy of additional evaluation, more comprehensive
material can be made available.
BACK
TO TOP
|
|
New
Type Fonts Well Received; Unibase Uses Own Font Files |
|
As
most who have upgraded to Unibase by DMAC release 7.49i know,
the type fonts now are the same regardless of which operating
system version is used. Rick spent the time on this and of all
the improvements in 7.49i, this improvement received the most
praise.
DMACI
in the unibase.ini environment controls the fonts. Now SMALL,
MED, BIG, BIG1, and BIG2 each produce a font that is always the
same.
Of
course, users have suggested that the 32-bit version have more
DMACI control over the image resolution – not only internally,
but in how it displays. Look
for this improvement soon.
BACK
TO TOP
|
|
IDC
to DF Creates Empty Data Files Based on IDC |
|
Users
try to keep track of the various utilities that can be lifted
out of context in Unibase by DMAC and Unibase Imaging to be used
elsewhere. A help line call let DMAC know that the executable
idctodf.exe has uses beyond its initial role in the new ParaPort
utility. Go to it. Idctodf.exe takes the information in an image
data control (idc) file and creates a empty data file from that
data.
Since
this is a batch with record formats in exactly the same order as
would have been keyed using the idc and each record is
associated with an image in the data file, voilŕ!
Ok,
we do not give away client secrets, but this client said we
should let others know such a solution might be handy for others
to use. Think now; it will come to you in the middle of the
night.
BACK
TO TOP
|
|
<itag
0;45000> Control Function Gives Tiff Header Tags Access |
|
Unibase
by DMAC, release 7.49i, now being distributed, has a new control
function which allows access to the tiff tag information for an
image. The control function is <itag 0;45000>. The ‘0' represents the channel number of which the current
image with the header is associated. The ‘45000' represents
the tiff tag id.
The
control function can be used in move, build, and output verbs.
So far, no user has come up with an example of where data is to
be put back into the header, so this function is read only for
now.
BACK
TO TOP
|
|
Picklist
Verb Expands AID File Manipulation Capacities in 7.4ai |
|
Unibase
by DMAC, release 7.4ai, now in alpha test, provides a powerful
new support feature in the picklist variation of the get verbs.
Now in the AID language a user can say:
get
&1 picklist “this is picklist title” using “matchkey??”
with “hello” @1;1:1-10@ “ goodbye” @1;2@ into turkey
else pause “failed to pick something”; goto !failed.
The
‘&1' is the channel number.
The
‘this is picklist tile” is a text string for a title.
The
‘matchkey??’ is a key for the index file that can include
wildcards if desired.
The
‘”hello” @1;1:1-10@ “goodbye” ‘ is an output string
which forms the display line in the picklist display.
The
“turkey” is a variable or array into which the selected
output record can be stored.
The
else string is, as always, the way to specify action if the verb
fails.
THE
ACTION:
When the verb is encountered in an AID program, a list box is
shown to the user with the output string displayed for every
record in the index file that matches the match key. In
addition, a line is added to the list box that says “none of
the above”. The user chooses a single output string and the
index file is set to the corresponding record from which the
output string was created.
Many
users helped specify how this verb would behave. DMAC wants to
thank them all
BACK
TO TOP
|
|
Operator
Statistics Package Changes Make It Easier To Use |
|
Unibase
by DMAC release 7.49i, and later, comes with improvements to the
operator statistics package which make it easier to use. The
package now has the more common format of a standard job (opstwf)
and a record format (opstwf). It no longer uses the .i and .t
conventions.
The
package also uses the get next verb instead of the remove verb
for moving through the data. The <top> command has been
replaced with a line counting function. The <top> command
used a top of form command which, surprisingly, is not supported
on some of the newer printers combined with older operating
systems.
The
page headers are output with verbs in a format easier for the
programmer to understand. New .bat files are provided which
facilitate running and modification.
Tina
Kay undertook this at a client’s request.
BACK
TO TOP
|
|
<oprecord>
Control Function Gives User Access to Statistics in AID Program |
|
Unibase
by DMAC, release 74ai, now in alpha test, has a new control
function – <oprecord>. This control function gives read
only access to the current operator statistics for the current
batch in data entry mode. The statistics are identical to those
in the operator record logged in the opst.aid file when a batch
is terminated or interrupted. The data represented by the
control function can be used with a build, move or output verb.
With
the addition of this feature, Tina Kay, of DMAC, has created an
AID program that uses a database based upon operator ID to keep
track of batches in process.
Thus, if the operator terminal locks up, is unplugged or
some similar mishap occurs, the statistics for the operator can
be retrieved for the batch in process. Users no longer need lose
statistics due to locked up terminals.
BACK
TO TOP
|
|
“To
Pan or Not To Pan; That Is The Question” |
|
Sometimes
DMAC adds a feature just so the documentation is easier to
understand. In the past few months, several users asked when can
you pan an image and when can you not pan an image. The users
had logical reasons as to when you should be able to pan an
image and when you should not. They also felt that magnified
snippets should behave in a consistent way.
So
after much discussion we added features for panning that met
user demand when no panning was previously available.
Where panning was previously available we did not change
anything. So now one can pan much more frequently.
Hopefully this will be helpful along with the new
features such as image tabs described elsewhere in this
newsletter.
Everything
now works as the users interpreted the documentation. Let us
know if you think we should do something else. We have more
panning; let us hope it fills user needs.
BACK
TO TOP
|
|
Environment
Variable Protects Prior Keyed Data in Release 7.4ai |
|
Unibase
by DMAC release 7.4ai has an added environment variable, UBPROT=y,
which requires the traditional use of the correct key whenever
the user is on a record which is not the current record and the
user wishes to change the character, field, or record. Several
clients have requested this added level of security.
BACK
TO TOP
|
|
New
Scrolling Fields in 7.4ai Solve Classical Inventory Keying
Problem |
|
One
more solution to the Classical Inventory Keying Problem now
exits. Users from the seventies and eighties know this
problem as the “Sears Inventory Problem.”
Unibase
by DMAC’s newest solution to this classical problem allows the
user to specify fields in a record as scrolling fields. The
fields preceding the scrolling fields in the record are treated
as duplicated information. These non scrolling fields are shown
only once on the screen.
Then
the scrolling fields are shown for as many records as are to be
keyed with the same non-scrolling data. Each time the end of the
scrolling fields group is reached, a new scrolling record is
created and the area for the scrolling fields is scrolled.
As many records can be shown as room on the display
allows. This display area starts with the location of the first
scrolling field and goes to the bottom of the display. Standard
record back and forward can move through the scrolling fields
groups.
When
entering data, a special key indicating the end of the current
scrolling document is used. The record format is flagged as
using scrolling fields also. Other than these two items, nothing
else new need be learned.
BACK
TO TOP
|
|
Completely
Untethered Images; Carolyn Avera’s Dream Reached |
|
Back
in the late 1980's and early 1990's Carolyn Avera, one of
DMAC’s founders, now retired, dreamed of totally untethered
images. With
Unibase by DMAC 7.4ai and Unibase Imaging 7.4ai, that dream has
been fulfilled. Any image jpeg or tiff (with all of its pages
automatically included) mentioned in an image data control file
(idc file) can be viewed at any time the associated batch for
the idc file is open.
DMAC
clients using this powerful feature have not relayed to DMAC how
keyers keep track of what they are doing. More news next time.
Naturally, you have to indicate that the job is to support
totally untethered images. Now the choice on Manual Image
Advance is Tethered, Untethered, and No (T, U, N).
As
this article was being created, another e-mail arrived from a
user requesting just this feature, so it looks like it’s going
to be a popular feature.
BACK
TO TOP
|
|
Tiff
Flavor Detection Gets An Upgrade |
|
A Tiff file
format is a tag-based file format for storing and interchanging
raster images. The current specification is level 6.0. Many
companies provide tiff files that should meet this
specification. When a company provides a tiff file that almost
meets the specification, DMAC tries to figure out what is
different and compensate for that company’s sins of commission
or omission. DMAC calls these differences “flavors.”
To
attack these “flavors,” DMAC uses two totally different
algorithms to decode tiff files; Showi, changei, rfimageg,
rfimagef and snippi use one algorithm and dei and rfmouse use
the other. Normally one algorithm works and the other does not.
Sometimes neither works. The “flavor” almost always fails on
some unique boundary, such as 32568.
Recently
DMAC took all the current “flavors” that were troublesome
and tweaked the code so that images were decoded from them.
What does this mean? If you had a tiff that could not be
read previously by dei (Unibase Imaging) you might try it again.
Many users have found that changei fixes most images so
that dei can read them correctly.
This is an inserted step that might now be eliminated.
If
you find a tiff that cannot be read by one or either and can be
read by something else, send it to DMAC. We will put it in our
“flavor” box and try to fix it the next time we get a
chance.
BACK
TO TOP |
|
|
|
