[futurebasic] Re: [FB] [FB^3] Appearance Manager

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : November 1999 : Group Archive : Group : All Groups

From: Ken Shmidheiser <kshmidheiser@...>
Date: Sat, 6 Nov 1999 00:56:30 -0500
-Derek wrote

>Actually there are some trap words to the call under the 68k version, but
>I guess it can be ignored. Both Jon Hull and I have sent the appearance
>definitions to Staz in the past, so I can only assume it will be in
>release 1 (I'm fairly sure the current beta has them already).
>
>I can't get to my Mac just now, but I'll send you the toolbox file that I
>have when I get home. Any other takers can email me privately.
>
>By the way, all that assembly stuff is long gone now. You should lookup
>the docs on the TOOLBOX [FN] keyword.


Derek,

I'm looking forward to getting the file. Are the docs you're talking 
about referring to FB, or are you talking about Inside Macintosh?

Thanks,

Ken


Meanwhile, Joe Wilkins wrote:

>Maybe we need to encourage the guy(s) at Morrison Designs to encorporate the
>Appearance Manager Objects into their Future Frames; then we would almost ALL
>certainly be inclined to use their product - at which I have just peeked for a
>moment or two, but which looks promising.


That's exactly what I thought when I first saw Future Frames.

It's ironic, but my guess is that John Morrison used RealBASIC to 
develop Future Frames, hence its Appearance Manager compliant feel. 
(The ID 132 and 133 PICT resources in Future Frames are the legacy 
PICTS of buttons and controls from RealBASIC which hang around in RB 
apps similar to the way apps generated in FB carry the ANDY (... and 
now STAZ) resource.

As its stands in version 1.0, Future Frames only mildly outstrips the 
functionality of the 1994 FlashWindows, but it sure is a lot prettier.

It's not my intention to re-open an FB-RB debate, or to knock Future 
Frames (which I probably will buy). But RB does offer some attractive 
controls, albeit not necessarily fully Appearance Manager compliant 
due to RB's cross-platform nature.

(For some reason, RB apps look and feel, for lack of a better word, 
"chunky" to me. Kinda like FileMaker Pro or VisualBASIC projects. You 
can tell one the minute you open it. Now I've seen some pretty poor 
FB programming-- much of it here on my own desktop-- but I've also 
seen some really neat things that, for all purposes, could have been 
written as commercial apps in C or C++.)

With FB^3's fast and elegant core code structure, it would be so nice 
have access to current features that make MacOS great. Otherwise I 
fear we will remain stuck in the early 1990s when others have moved 
on to a fresher and better interface.

I feel that with each iteration, FB^3 is drawing further and further 
away from the crippling aspects of BASIC and closer and closer toward 
the power of C, while maintaining the capability of being understood 
by mere mortals such as me. (Every time I see "void" in C, I wonder 
if it refers to what the code before it does.)

It would take just a little stretch to expand FB^3's vocabulary to 
access Appearance Manager functions and procedures, and I hope it 
becomes a priority on the Wish List.

Ken

p.s. In the meantime, any and all suggestions about rolling your own 
FB routines to access Appearance Manager are welcome. I have a small 
(about 500K) app that demos each of the new AM features. Running it 
is like peeking over the mountain... it's hard to look back. E-mail 
me if you'd like to see it.