On VMS, there was an office package called ALL-IN-1 which ran on VT
terminal with menus, word processor etc.
Included in this was the ability to quickly build small database
applications by simply creating a form (think Interface Builder for VT
terminals , it was called FMS) with fields matching data in an indexed
file (think ISAM database). ALL-IN-1 had all the logic in itself to map
the form fields to the indexed file and grant access to the file
(including record locking etc etc)
You could "actions" to be triggered wherever the cursor entered the
field, left of the field, or special keys. You could validate fields
against another database (for instance, encure you entered a valid
province code) etc etc. These actions were included inside the form
definition (called "named data" in FMS).
There were also index forms that allowed you to essentially create the
equivalent of a SELECT statement and the index form would then list all
records matching the search criteria and you could scroll through them.
(think an NSTableview which, when you click on a record, a new form
appears with that record's information).
Now, I have plenty of questions:
-Is is still the case that Applescript still has no ability to make
MySQL queries ? I kinda like the applescript simplified approach to
handling events and it allows me to program at a much higher level.
-Does PHP have the ability to use .NIB files to create GUI applications
that interface with MySQL databases ?
-Has anyone succesfully programmatically built .NIB (in their text form)
files ? (I was thinking of converting the FMS forms (I already have a
parser) to .NIB files to match the layout, field lengths etc). Or would
this be considered a major undertaking and it would be easier for me to
manually rebuild all the forms I have to convert over to the mac ?
-Are there any open source GUI client frameworks to access MySQL on a Mac ?
-Or is the recommended/easier way for me to write C programs that
perform all of the GUI stuff and SQL access ?
Finally, I still have my old "Inside Macintosh" volumes 1 to 4. (Back in
the days of the 68k macs :-). But since then, I had focused on VMS and
didn't keep up with the Mac for programming.
Are there any reasons why one would develop new applications with
"Carbon" ? Is it correct to state that Carbon is there for compatibility
with older applications ? Or are there still brand new applications
being built for it, with no end in sight for support of Carbon apps ?
James W. Walker - 19 Mar 2008 07:40 GMT
> Are there any reasons why one would develop new applications with
> "Carbon" ? Is it correct to state that Carbon is there for compatibility
> with older applications ? Or are there still brand new applications
> being built for it, with no end in sight for support of Carbon apps ?
I can't answer your other questions, but I'll take a whack at this one.
The "writing on the wall" was the announcement at WWDC 2007 that Carbon
would not be supported for 64-bit applications. I expect that Carbon
apps will continue to run for years to come, but new APIs and
enhancements will be elsewhere. So, creating a brand new application
with Carbon now would be a very questionable decision.