Richard,

I don't have V9.x on any of my machines. None of my customers have moved to it yet so my statements apply to my experiences with V8.x.

I guess we'll have to disagree about the icons. I think they're barren looking, color challenged, lack depth, don't pop, no shadowing...

Your observations are appreciated regarding what AF lacks in the development area. As a developer, you might not see any value in themes but there are a lot of users who think aesthetics are important.

I come from a Delphi development background so I'm biased when I see an IDE that is so well integrated. I would love to see SAS adopt or develop a better integrated development environment for AF.

I would also like to see better written documentation for new developers who want to start developing AF projects. I think the lack of real world guides is a major hindrance for those who are just starting to learn. A few years ago, SAS offered a CD of AF and EIS examples demonstrating some of the techniques available. That was a great and valuable bit of information for me. They should develop a whole library of these things.

This thread started out discussing and demonstrating the merits and ease of using a .NET framework with SAS. I think Alan Churchill is doing us a favor by firing a shot across the bow in the world of SAS GUI development and letting us know what is right around the corner. I'm pretty active in the Central Ohio Technology Council and when I talk to the contract firms at the meetings, they tell me that about 75% of their contractor requirements is now for .NET and JAVA developers.

As a consultant and developer, I see a lot of work and activity revolving around .NET. Perhaps we'll see the role of SAS being the heavy lifter for processing data on the backend and .NET being the interface into these systems. Being able to integrate SAS and .NET will be valuable. It would be nice to have another tool in my arsenal that I could use.

Finally, I don't think many people understand that .NET is not just an MS language platform supporting Basic, C#, VB.Net, and C++. Borland's Delphi 2005 and V8 is .NET ready. There is also support for legacy tools such as COBOL, FORTRAN, and even (this is for you David!) PERL.

Phil Rack MineQuest, LLC 1939 Queensbridge Dr. Columbus, OH 43235-2018 Tel: (614) 457-3714 Fax: (614) 777-3714

http://www.MineQuest.com E-Mail: PhilRack@MineQuest.com

-----Original Message----- From: Richard A. DeVenezia [mailto:radevenz@IX.NETCOM.COM] Sent: Sunday, January 23, 2005 10:41 AM To: SAS-L@LISTSERV.UGA.EDU Subject: Re: simple gui with SAS

Phil Rack wrote: > Hi Mike, > > It wasn't an impression that the Institute put out on AF development, > it was the party line. I first heard the statements at the Futures > forum at SUGI in San Diego. It was suggested that we don't write new > apps in AF but move to the newer technologies like SAS/Intrnet and > Integration Technologies/Java. I've heard the same party line at > other conferences as well. All these statements were from SAS > employees. > > Here are two things I would like to see the Institute work on: > > 1) AF might be considered mature by the Institute, but it doesn't > have to look old. SAS/AF would be much more acceptable if it would > at least try to be aesthetically pleasing. I've never seen an AF > application that looked like anything else running on a Windows > Platform. That's not a compliment. How about some nice looking > icons, controls, and gauges?

I think the icon art is very good. Controls and gauges... I think the last newest AF controls were ETS and Scatter Control (dynamic graphs similar to the activex/java graph controls for excel/html). In Windows you can use ActiveX components via AF OLE object. However, since OLE interaction development has not continued, it is not as easy as it is in other app dev systems such as Delphi or VisualBasic.

Treeview and Listview Controls work, but languish as experimental. There is no Splitter Control (sigh, can emulate this myself). AF never was a 'painting' OOT, so there is not a way to create our own Control with totally unique visualization rendering (fish eye lensing, gradient paints {I don't like the simplicity of Range}). AF never had true Timers nor Threads (maybe because the core of AF laid in 93/94 was never enhanced for this?)

Wishful thinking: The entire internal AF design (messaging(send/receive/broadcast),semaphore,layout/attachments,composites,i nheritance models/disparate method coding schemes, runtime binding and mutuable objects, SCL lists, etc..) could be re-realized in Java (and maybe webAF is finally catching up to that). If Java can be more tightly integrated with DMS / supervised by the hidden SAS session executor/manager tasks perhaps one day we will be able to have Proc JDISPLAY cat=... JBUILD lib.mem.ent.frame This might only be possible if the whole MVA idea, implemented using SAS internal C and MVA stubbing compiler technologies are redone in Java. (SAS inhouse likely has enough expertise to write their own java compiler with extensions that make SAS SAS) I have a feeling that despite speed improvement to Java, 'pedal to the metal' still makes C underpinnings desirable.

> 2) Better more standard window/frame behavior. I feel that I'm always > fighting frame navigation. It's just not intuitive to me anyway. I'm > always glad to see questions on this on SAS-L because then I know I'm > not alone.

Part of the impression of AF is 'old' is that many of the vertical niche SAS applications and products developed in SAS/AF were never re built using newer visual controls. A few have um, err, uhh, deplorable UI. I don't run XP or 'theme' my Windows 2000 machine (over concern about the "I must tweak the look and feel down to the pixel" is non-productive waste of time { as opposed to productive wastes of time -- like Golf ;) }.

SAS/AF applications can absolutely look 'Office'like. An adherence to a standard GUI design and action initiation motif is what is required. Much of the problem has to do with the success of backward compatibility. If product P has matured on version V, and when P is successfully backward compatible in version V+1, then justification of upgrading/testing/qa releasing P* (which is P with look/features of V+1) is difficult when product Q is begging for development. I'ld make a bet an argument was made that the cost of ensuring backward compability for all the AF dependent product sets was less than the cost of refacing all the product sets.

The fact that v6 AF apps run unchanged (or nearly so) in version 7+ is a tribute to the hard work, good planning and testing done by the unsung heroes in development.

-- Richard A. DeVenezia http://www.devenezia.com/

-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 1/19/2005

-- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.7.1 - Release Date: 1/19/2005