|
|
 | | From: | Randy Herbison | | Subject: | Re: simple gui with SAS | | Date: | 21 Jan 05 20:42:11 GMT |
|
|
 | Alan,
Yes, I'll send screenshots. I can send you the SAS/AF application if you
like.
It's not really the type of application I would typically build with SAS/AF.
It duplicates capabilities already present in the SAS DMS environment. I
built it to "specs" just having fun competing. It doesn't resemble what I
would do if I was trying to sell SAS/AF. On the other hand, it does (I
hope) demonstrate how easy it is to use SAS/AF to build GUI's for
SAS-centric applications.
-Randy
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Alan
Churchill
Sent: Friday, January 21, 2005 1:29 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: simple gui with SAS
Randy,
Can you post a screenshot on the web or, better yet, make a few for me and I
will post on a Savian page for review. It would be nice, outside of having
fun here, to illustrate to people their choices and how to get started.
Thanks,
Alan
Savian
"Bridging SAS and Microsoft Technologies"
?
nntp://news.qwest.net/comp.soft-sys.sas/
Correction, I should've typed: (as opposed to SCL-only programs which can
execute without a DMS environment)
-----Original Message-----
From: Randy Herbison
Sent: Friday, January 21, 2005 12:48 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: simple gui with SAS
Alan,
Using SAS/AF, we don't really need to add any controls to accept the user's
code or display the log; SAS/AF applications with displays (as opposed to
SCL-only programs) execute in the DMS environment where the SAS log, PGM
editor, and Enhanced Editor are already available.
But, just to even up the competition I created a SAS/AF application using a
frame, textpad control to accept the user's code, an external file viewer to
display the log, and a pushbutton. It took less than one minute to point and
click, set properties, and perform region attachments (so that the frame and
controls all resize nicely when the window containing the frame is resized
by the user).
Here's the SCL behind the frame:
dcl char(1024) line;
init:
rc=filename('SASlog',' ','temp');
return;
btnSubmit:
efvLog.fileRef=' ';
do i=1 to listlen(txpPgm.text);
line=getitemc(txpPGM.text,i);
submit;
&line
endsubmit;
end;
submit continue;
endsubmit;
call execcmdi('log; file SASlog');
efvLog.fileRef='SASlog';
return;
term:
efvLog.fileRef=' ';
rc=filename('SASlog',' ');
return;
RandyHerbison@westat.com
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Alan
Churchill
Sent: Thursday, January 20, 2005 11:50 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: simple gui with SAS
Any folks who have never coded in either, please let us know your experience
if you try both.
I don't think there's a comparison, especially on .NET's turf...Windows, but
I think we would be interested in feedback.
We could, ummm, have a little head-on-head competition for SAS interface
tools...AF, Java, and .NET (any other factions are fine as well). Fewest
lines of code, fastest, easiest interface. One textbox to take code, 1
textbox to display log output, 1 table to display resulting dataset, and a
submit button. It would have to be on Windows and I will quickly concede
that point. Give me 10 demerits to start ;-]
Just a thought...
Thanks,
Alan
Savian
"Bridging SAS and Microsoft Technologies"
?
nntp://news.qwest.net/comp.soft-sys.sas/
Alan Churchill wrote:
> For the download:
>
> http://lab.msdn.microsoft.com/express/
I can't let Alan and .NET get away without mentioning Java. Download
Netbeans, also free. http://www.netbeans.org/downloads/
--
Richard
[comp.soft-sys.sas]
[comp.soft-sys.sas]
|
|
| | From: | Michael L. Davis | | Subject: | Re: simple gui with SAS | | Date: | 22 Jan 05 15:11:05 GMT |
|
|
| Hello Friends,
At 03:39 AM 1/22/2005 +0000, Alan Churchill wrote in part:
>On the latter, it is my understanding that SAS does not do any AF
>development currently. AF still works as Randy has shown and can be used.
I had a telephone conversation about three weeks ago with some folks at SAS
about the future of SAS/AF. They initiated the telephone call. Part of
the message that they passed to me was that despite the impression
sometimes given at the SUGI and NESUG SAS Future forums, SAS's commitment
to maintain SAS/AF is very solid and that worries about its future should
not figure into the decision to use it verses alternative technologies.
They also advanced the notion that one of the reasons why we don't see much
in the way of new SAS/AF features is because the product is mature and has
many of the features that other technologies might need to add. There was
also the hint that if folks on SAS-L had ideas about missing SAS/AF
features, the SAS R&D folks would entertain adding them.
Now that I mention it, I have one. I'd love to see an SLIST catalog entry
editor/viewer.
In the context of this thread, I'd like to share something that I think is
missing. Cost. The simple GUIs suggested may cost little or no money for
the client development tool. On the other hand, they do need relatively
expensive SAS server software (e.g., Integration Technologies) for the SAS
application to work on PCs without SAS installed.
On the other hand, you only need one PC with SAS/AF to create and compile
the client. That license is often bundled in Enterprise desktop
packages. In environments with copies of SAS readily available on the user
desktops, SAS/AF may be a worthwhile alternative.
- Michael "Mad Doggy" Davis
Michael L. Davis
Ambler PA
E-Mail: michael@bassettconsulting.com
Web: http://www.bassettconsulting.com
|
|
| | From: | Phil Rack | | Subject: | Re: simple gui with SAS | | Date: | 23 Jan 05 14:27:03 GMT |
|
|
| 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?
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.
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: Michael L. Davis [mailto:michael@BASSETTCONSULTING.COM]
Sent: Saturday, January 22, 2005 10:11 AM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: simple gui with SAS
Hello Friends,
At 03:39 AM 1/22/2005 +0000, Alan Churchill wrote in
part:
>On the latter, it is my understanding that SAS does not do any AF
>development currently. AF still works as Randy has shown and can be used.
I had a telephone conversation about three weeks ago with some folks at SAS
about the future of SAS/AF. They initiated the telephone call. Part of
the message that they passed to me was that despite the impression
sometimes given at the SUGI and NESUG SAS Future forums, SAS's commitment
to maintain SAS/AF is very solid and that worries about its future should
not figure into the decision to use it verses alternative technologies.
They also advanced the notion that one of the reasons why we don't see much
in the way of new SAS/AF features is because the product is mature and has
many of the features that other technologies might need to add. There was
also the hint that if folks on SAS-L had ideas about missing SAS/AF
features, the SAS R&D folks would entertain adding them.
Now that I mention it, I have one. I'd love to see an SLIST catalog entry
editor/viewer.
In the context of this thread, I'd like to share something that I think is
missing. Cost. The simple GUIs suggested may cost little or no money for
the client development tool. On the other hand, they do need relatively
expensive SAS server software (e.g., Integration Technologies) for the SAS
application to work on PCs without SAS installed.
On the other hand, you only need one PC with SAS/AF to create and compile
the client. That license is often bundled in Enterprise desktop
packages. In environments with copies of SAS readily available on the user
desktops, SAS/AF may be a worthwhile alternative.
- Michael "Mad Doggy" Davis
Michael L. Davis
Ambler PA
E-Mail: michael@bassettconsulting.com
Web: http://www.bassettconsulting.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
|
|
| | From: | Richard A. DeVenezia | | Subject: | Re: simple gui with SAS | | Date: | Sun, 23 Jan 2005 10:40:38 -0500 |
|
|
| 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/
|
|
| | From: | Phil Rack | | Subject: | Re: simple gui with SAS | | Date: | 23 Jan 05 17:42:02 GMT |
|
|
| 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
|
|
| | From: | Alan Churchill | | Subject: | Re: simple gui with SAS | | Date: | Sat, 22 Jan 2005 03:39:54 GMT |
|
|
|
Randy,
Thanks for taking up the AF challenge.
I do think that several issues should be considered when weighing front-end development environments. Some that spring to mind are:
1. Ease and cost of deployment
2. Cost of IDE and development ease
3. Commonality of training and skillsets in the marketplace 4. Available resources including newsgroups, 3rd party components, etc.
5. Support both today and tomorrow
On the latter, it is my understanding that SAS does not do any AF development currently. AF still works as Randy has shown and can be used.
I will try and summarize the development needed to make this work and get it posted up on the website. I will work with Randy to get that code posted as well.
Thanks,
Alan
Savian
"Bridging SAS and Microsoft Technologies"
Here is my final c# code:
#region Using directives
using System;
using ADODB ;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Data.OleDb ;
using System.Drawing;
using System.Windows.Forms;
using SAS ;
using SASWorkspaceManager ;
#endregion
namespace SASDemo
{
partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private object[] SubmitSASCode(string sasCode, string
returnSASDataSetName)
{
object[] sasResults = new object[2];
string ErrorMessage;
WorkspaceManager wsm = new WorkspaceManager();
Workspace ws =
(Workspace)wsm.Workspaces.CreateWorkspaceByServer("",
SASWorkspaceManager.Visibility.VisibilityProcess, null, "", "", out ErrorMessage);
SAS.ILanguageService ls = ws.LanguageService;
ls.Submit(sasCode);
ls.LineSeparator = "\r\n";
string log = ls.FlushLog(1000);
log = log.Replace("\f", "");
sasResults[0] = log;
try
{
System.Data.OleDb.OleDbDataAdapter da = new System.Data.OleDb.OleDbDataAdapter("select * from " + returnSASDataSetName , "provider=sas.iomprovider; SAS Workspace ID=" + ws.UniqueIdentifier);
System.Data.DataSet ds = new System.Data.DataSet();
da.Fill(ds, returnSASDataSetName);
sasResults[1] = ds;
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
//Delete pool
ws = null;
}
return sasResults;
}
private void button1_Click(object sender, EventArgs e)
{
object[] sasBits = SubmitSASCode(tbSASCode.Text, tbDataSetName.Text);
tbSASLog.Text = (string)sasBits[0];
dgSASData.DataSource =
((System.Data.DataSet)sasBits[1]).Tables[0];
}
}
}
-----Original Message-----
From: Randy Herbison [mailto:RandyHerbison@westat.com]
Sent: Friday, January 21, 2005 1:42 PM
To: 'Alan Churchill'; SAS-L@LISTSERV.UGA.EDU
Subject: RE: simple gui with SAS
Alan,
Yes, I'll send screenshots. I can send you the SAS/AF application if you like.
It's not really the type of application I would typically build with SAS/AF.
It duplicates capabilities already present in the SAS DMS environment. I built it to "specs" just having fun competing. It doesn't resemble what I would do if I was trying to sell SAS/AF. On the other hand, it does (I
hope) demonstrate how easy it is to use SAS/AF to build GUI's for SAS-centric applications.
-Randy
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Alan Churchill
Sent: Friday, January 21, 2005 1:29 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: simple gui with SAS
Randy,
Can you post a screenshot on the web or, better yet, make a few for me and I will post on a Savian page for review. It would be nice, outside of having fun here, to illustrate to people their choices and how to get started.
Thanks,
Alan
Savian
"Bridging SAS and Microsoft Technologies"
?
nntp://news.qwest.net/comp.soft-sys.sas/
Correction, I should've typed: (as opposed to SCL-only programs which can execute without a DMS environment)
-----Original Message-----
From: Randy Herbison
Sent: Friday, January 21, 2005 12:48 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: simple gui with SAS
Alan,
Using SAS/AF, we don't really need to add any controls to accept the user's code or display the log; SAS/AF applications with displays (as opposed to SCL-only programs) execute in the DMS environment where the SAS log, PGM editor, and Enhanced Editor are already available.
But, just to even up the competition I created a SAS/AF application using a frame, textpad control to accept the user's code, an external file viewer to display the log, and a pushbutton. It took less than one minute to point and click, set properties, and perform region attachments (so that the frame and controls all resize nicely when the window containing the frame is resized by the user).
Here's the SCL behind the frame:
dcl char(1024) line;
init:
rc=filename('SASlog',' ','temp');
return;
btnSubmit:
efvLog.fileRef=' ';
do i=1 to listlen(txpPgm.text);
line=getitemc(txpPGM.text,i);
submit;
&line
endsubmit;
end;
submit continue;
endsubmit;
call execcmdi('log; file SASlog');
efvLog.fileRef='SASlog';
return;
term:
efvLog.fileRef=' ';
rc=filename('SASlog',' ');
return;
RandyHerbison@westat.com
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Alan Churchill
Sent: Thursday, January 20, 2005 11:50 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: simple gui with SAS
Any folks who have never coded in either, please let us know your experience if you try both.
I don't think there's a comparison, especially on .NET's turf...Windows, but I think we would be interested in feedback.
We could, ummm, have a little head-on-head competition for SAS interface tools...AF, Java, and .NET (any other factions are fine as well). Fewest lines of code, fastest, easiest interface. One textbox to take code, 1 textbox to display log output, 1 table to display resulting dataset, and a submit button. It would have to be on Windows and I will quickly concede that point. Give me 10 demerits to start ;-]
Just a thought...
Thanks,
Alan
Savian
"Bridging SAS and Microsoft Technologies"
?
nntp://news.qwest.net/comp.soft-sys.sas/
Alan Churchill wrote:
> For the download:
>
> http://lab.msdn.microsoft.com/express/
I can't let Alan and .NET get away without mentioning Java. Download Netbeans, also free. http://www.netbeans.org/downloads/
--
Richard
[comp.soft-sys.sas]
[comp.soft-sys.sas]
|
|
| | From: | Datametric | | Subject: | RE : simple gui with SAS | | Date: | 23 Jan 05 10:28:08 GMT |
|
|
| ok, ok.
But AF solution requires SAS/AF licence. We started with the hyp. That we
only use SAS/Base (stat, ets...). Otherwise, we can take SAS App Dev studio
too.
* Alan : what's the SAS requirements for .NET ? Richard : What's the
requirements for Netbeans ? It's SAS/IT ?
* Absolutely all of I need in the .NET or netbeans is free ?
Thx,
Stéphane.
-----Message d'origine-----
De : SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] De la part de Alan
Churchill
Envoyé : samedi 22 janvier 2005 04:40
À : SAS-L@LISTSERV.UGA.EDU
Objet : Re: simple gui with SAS
Randy,
Thanks for taking up the AF challenge.
I do think that several issues should be considered when weighing front-end
development environments. Some that spring to mind are:
1. Ease and cost of deployment
2. Cost of IDE and development ease
3. Commonality of training and skillsets in the marketplace 4. Available
resources including newsgroups, 3rd party components, etc.
5. Support both today and tomorrow
On the latter, it is my understanding that SAS does not do any AF
development currently. AF still works as Randy has shown and can be used.
I will try and summarize the development needed to make this work and get
it posted up on the website. I will work with Randy to get that code posted
as well.
Thanks,
Alan
Savian
"Bridging SAS and Microsoft Technologies"
Here is my final c# code:
#region Using directives
using System;
using ADODB ;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Data.OleDb ;
using System.Drawing;
using System.Windows.Forms;
using SAS ;
using SASWorkspaceManager ;
#endregion
namespace SASDemo
{
partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
private object[] SubmitSASCode(string sasCode, string
returnSASDataSetName)
{
object[] sasResults = new object[2];
string ErrorMessage;
WorkspaceManager wsm = new WorkspaceManager();
Workspace ws =
(Workspace)wsm.Workspaces.CreateWorkspaceByServer("",
SASWorkspaceManager.Visibility.VisibilityProcess, null, "", "", out
ErrorMessage);
SAS.ILanguageService ls = ws.LanguageService;
ls.Submit(sasCode);
ls.LineSeparator = "\r\n";
string log = ls.FlushLog(1000);
log = log.Replace("\f", "");
sasResults[0] = log;
try
{
System.Data.OleDb.OleDbDataAdapter da = new
System.Data.OleDb.OleDbDataAdapter("select * from " + returnSASDataSetName ,
"provider=sas.iomprovider; SAS Workspace ID=" + ws.UniqueIdentifier);
System.Data.DataSet ds = new System.Data.DataSet();
da.Fill(ds, returnSASDataSetName);
sasResults[1] = ds;
}
catch (Exception ex)
{
MessageBox.Show(ex.ToString());
//Delete pool
ws = null;
}
return sasResults;
}
private void button1_Click(object sender, EventArgs e)
{
object[] sasBits = SubmitSASCode(tbSASCode.Text,
tbDataSetName.Text);
tbSASLog.Text = (string)sasBits[0];
dgSASData.DataSource =
((System.Data.DataSet)sasBits[1]).Tables[0];
}
}
}
-----Original Message-----
From: Randy Herbison [mailto:RandyHerbison@westat.com]
Sent: Friday, January 21, 2005 1:42 PM
To: 'Alan Churchill'; SAS-L@LISTSERV.UGA.EDU
Subject: RE: simple gui with SAS
Alan,
Yes, I'll send screenshots. I can send you the SAS/AF application if you
like.
It's not really the type of application I would typically build with
SAS/AF.
It duplicates capabilities already present in the SAS DMS environment. I
built it to "specs" just having fun competing. It doesn't resemble what I
would do if I was trying to sell SAS/AF. On the other hand, it does (I
hope) demonstrate how easy it is to use SAS/AF to build GUI's for
SAS-centric applications.
-Randy
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Alan
Churchill
Sent: Friday, January 21, 2005 1:29 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: simple gui with SAS
Randy,
Can you post a screenshot on the web or, better yet, make a few for me and
I will post on a Savian page for review. It would be nice, outside of having
fun here, to illustrate to people their choices and how to get started.
Thanks,
Alan
Savian
"Bridging SAS and Microsoft Technologies"
?
nntp://news.qwest.net/comp.soft-sys.sas/
Correction, I should've typed: (as opposed to SCL-only programs which can
execute without a DMS environment)
-----Original Message-----
From: Randy Herbison
Sent: Friday, January 21, 2005 12:48 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: simple gui with SAS
Alan,
Using SAS/AF, we don't really need to add any controls to accept the user's
code or display the log; SAS/AF applications with displays (as opposed to
SCL-only programs) execute in the DMS environment where the SAS log, PGM
editor, and Enhanced Editor are already available.
But, just to even up the competition I created a SAS/AF application using a
frame, textpad control to accept the user's code, an external file viewer to
display the log, and a pushbutton. It took less than one minute to point and
click, set properties, and perform region attachments (so that the frame and
controls all resize nicely when the window containing the frame is resized
by the user).
Here's the SCL behind the frame:
dcl char(1024) line;
init:
rc=filename('SASlog',' ','temp');
return;
btnSubmit:
efvLog.fileRef=' ';
do i=1 to listlen(txpPgm.text);
line=getitemc(txpPGM.text,i);
submit;
&line
endsubmit;
end;
submit continue;
endsubmit;
call execcmdi('log; file SASlog');
efvLog.fileRef='SASlog';
return;
term:
efvLog.fileRef=' ';
rc=filename('SASlog',' ');
return;
RandyHerbison@westat.com
-----Original Message-----
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Alan
Churchill
Sent: Thursday, January 20, 2005 11:50 PM
To: SAS-L@LISTSERV.UGA.EDU
Subject: Re: simple gui with SAS
Any folks who have never coded in either, please let us know your
experience if you try both.
I don't think there's a comparison, especially on .NET's turf...Windows,
but I think we would be interested in feedback.
We could, ummm, have a little head-on-head competition for SAS interface
tools...AF, Java, and .NET (any other factions are fine as well). Fewest
lines of code, fastest, easiest interface. One textbox to take code, 1
textbox to display log output, 1 table to display resulting dataset, and a
submit button. It would have to be on Windows and I will quickly concede
that point. Give me 10 demerits to start ;-]
Just a thought...
Thanks,
Alan
Savian
"Bridging SAS and Microsoft Technologies"
?
nntp://news.qwest.net/comp.soft-sys.sas/
Alan Churchill wrote:
> For the download:
>
> http://lab.msdn.microsoft.com/express/
I can't let Alan and .NET get away without mentioning Java. Download
Netbeans, also free. http://www.netbeans.org/downloads/
--
Richard
[comp.soft-sys.sas]
[comp.soft-sys.sas]
|
|
| | From: | Richard A. DeVenezia | | Subject: | Re: simple gui with SAS | | Date: | Sun, 23 Jan 2005 09:29:41 -0500 |
|
|
| Datametric wrote:
> ok, ok.
>
> But AF solution requires SAS/AF licence. We started with the hyp.
> That we only use SAS/Base (stat, ets...). Otherwise, we can take SAS
> App Dev studio too.
>
> * Alan : what's the SAS requirements for .NET ? Richard : What's the
> requirements for Netbeans ? It's SAS/IT ?
>
> * Absolutely all of I need in the .NET or netbeans is free ?
>
> Thx,
> Stéphane.
The discussion seems to have become Simple GUI _without_ SAS :) !
Consider
Thing X, and
Thing SAS.
With SAS/IT communication between Things X and SAS are a pretty easy two way
street. Without SAS/IT, things can be a not as easy two way street, or a
somewhat easy bandaid one way street (using temporary files, etc...)
All of netbeans is free.
As always, there are things you can buy to plug or add to it's features.
But, out of the download, netbeans is as complete as you need it.
I believe the java classes needed to easily connect to and interact with a
SAS
session are part of SAS/IT.
[ You can use .NET controls in Java (and probably conversely) by using JNI .
http://www.codeproject.com/dotnet/javanet.asp ]
I believe controlling SAS as a DDE server is part of Base
http://support.sas.com/documentation/onlinedoc/91pdf/sasdoc_91/base_hostwin_6974.pdf
You can use java classes from DATA Step using SAS Component object JavaObj.
http://www.devenezia/papers
[ There is no SAS Component object for dealing with Windows COM Objects. ]
Here is an idea I recently suggested to SAS, ideas in part contributed by
this and similar threads.
-----------------------------------
The POSTMESSAGE command displays a dialog with an OK button.
I recommend the development of a POSTDIALOG command for displaying
a message and accepting input.
{ POSTMESSAGE looks like Win32 api MessageBox, POSTDIALOG would
thus be equivalent of Win32 DialogBox }
There would be two modes of use:
Mode 1. POSTDIALOG "string" macro-var
A single text entry is create after the string. The value of the
macro var appears in the text entry. An OK and CANCEL button are
in the dialog. Edits to the text entry become the new value of
the macro-var if the OK button is clicked.
Mode 2. POSTDIALOG window-name
Look for a previously defined macro window created with the
%WINDOW statement. If it exists, render the window using the
look and feel of a system dialog (i.e. same look as POSTMESSAGE),
instead of the look and feel of a DMS text window. The dialog
window would populate macro variables (upon OK) in the same manner
as %DISPLAY.
Here is another interesting idea.
Suppose I wanted to process an HTML form submission
within the DMS session. HTML forms can be used as an input
GUI that many people can comfortably work with.
POSTHTML "html-file"
Through some creative arrangement and configuration of
applicable technology (nothing new), the html file is displayed
using the DMS clients default browser, and the submit
button of the form would return the form parameters
back to the DMS session in macro variables (similar to how
SAS/Intrnet delivers form values to a cgi SAS session) .
If working within the ecology of Windows and Internet Explorer,
you could create a special program, display.exe, that is
part of SAS installation. display.exe could use the
"Microsoft Web Browser" control to supervise all the clicks
and such, and easily capture the submit action.
-----------------------------------
In SAS-L or open domain, we could engineer our own display.exe, written in
..NET, Java (with JNI?Corba?), C, Delphi, Perl, Python, PHP, whatever...
display.exe would write a file that would be %included, the file would
contain macro variable assignments.
display.exe
name of HTML file
name of file to write %let statements in
i.e.
filename temp LETS;
%let osfile = %sysfunc(pathname(LETS));
x "display.exe myDialog.html &osfile";
%include LETS;
Now, If you pursue wanting myDialog.html to be real fancy, such as getting
live data from SAS via a query (from within the browser), you start a 'snake
eating its tail' situation. Sure the html could have activex and java and
htmlSQL and connect to a SAS/Share server and ... on and on, but it doesn't
seem to be a fruitful intermixing of technology.
Simply use myDialog.html for gathering some inputs that effect the
downstream operation of a SAS program running in a running SAS session. [ I
would have no problems with myDialog.html being created with ODS ;) ]
Homegrowing anything more fancy likely exceeds (in cost) the licensing of
existing SAS products that perform the same.
--
Richard A. DeVenezia
http://www.devenezia.com/
|
|
|
