Re: GUI or Event ? as nice as character-based

2004-04-19 Thread Christophe Marchal


[EMAIL PROTECTED] wrote:

In a message dated 4/19/2004 11:59:57 AM Pacific Daylight Time, 
[EMAIL PROTECTED] writes:

 

Does the requirement to have no client-side setup (other than pointing a
user to a web page in a std web browser) eliminate accuterm or not?  If not,
then does this permit drop-down boxes, combo boxes, calendars for date entry
and the usual icons one might expect for various features?
I'm talking about the U2 database, but the tools on the mv side need not be
more than UOJ, for example (with support for update of stored fields and
preferably also virtual fields as read-only). 

   

yes Dawn, Accuterm does support a web browser interface
I've not worked closely with that implementation, I usually use the telnet 
terminal emulator thingie.
But I did dink around with it slightly just to make sure it works.
I would expect since its running in a browser that you could do any java 
thingies you do with any other page if you want
Or any HTML or whatever.
Will
 

Well, in the demo page (http://www.asent.com/atguidemo5.htm ) it seems 
to use Activex in the web browser. Not just HTML.
And it does not work on my Mozilla.
So I don't think that it could be used on other OS than Windows/IE...

--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users


Re: GUI or Event ? as nice as character-based

2004-04-19 Thread FFT2001
In a message dated 4/19/2004 11:59:57 AM Pacific Daylight Time, 
[EMAIL PROTECTED] writes:


> Does the requirement to have no client-side setup (other than pointing a
> user to a web page in a std web browser) eliminate accuterm or not?  If not,
> then does this permit drop-down boxes, combo boxes, calendars for date entry
> and the usual icons one might expect for various features?
> 
> I'm talking about the U2 database, but the tools on the mv side need not be
> more than UOJ, for example (with support for update of stored fields and
> preferably also virtual fields as read-only). 
> 

yes Dawn, Accuterm does support a web browser interface
I've not worked closely with that implementation, I usually use the telnet 
terminal emulator thingie.
But I did dink around with it slightly just to make sure it works.
I would expect since its running in a browser that you could do any java 
thingies you do with any other page if you want
Or any HTML or whatever.
Will
-- 
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users


Re: GUI or Event ? as nice as character-based

2004-04-19 Thread Mark Johnson
Isn't that what System Builder did (does) with its sbclient software?

- Original Message -
From: <[EMAIL PROTECTED]>
To: "U2 Users Discussion List" <[EMAIL PROTECTED]>
Sent: Monday, April 19, 2004 2:27 PM
Subject: Re: GUI or Event ? as nice as character-based


> Clarify.  Are you talking about *within* the mv environment? Or an outside
app?
>
> Accuterm has the ability to recognize where a mouse-click is in regards to
(col, row).  This is the same col, row that PRINT @ uses.  Now if your mv
programs have a single, standard INPUT subroutine then you can simply modify
that subroutine.
>
> So your modification would look something like
> If I.am.using.accuterm then
>if mouseclick then
>   get.location; determine.which.field; reset fieldno = this.field
>   redo.input = true; return
>end
> end else
>input xxx
> end
>
> Or something along those lines.
> I have only seen one application package that integrated this ability,
however, the screen drivers it built allowed the user to point-and-click and
enter data into any field in any order on the screen.  It was then up to the
programmer to ensure that intra-field dependencies were properly handled.
But it was certainly a good start.
>
> Is that what you meant?
> Will
>
> In a message dated 4/19/2004 2:17:34 PM Eastern Daylight Time,
[EMAIL PROTECTED] writes:
>
> > I haven't gotten through all of the postings in the GUI thread as yet,
but
> > am working on the question of how to write a GUI that is as good as a
"green
> > screen" from the perspective of folks currently using a green screen
> > application.  I saw hints at that, but nothing that tackled it from the
> > standpoint of being able to use any tools on the market today to
accomplish
> > this (no need to retain databasic code, for example).
> >
> > What could be used to actually replace, completely, the character
screens?
> >
> > Requirements:
> > 0) work with U2 as multiuser databases
> >
> > 1) Be able to use any Windows, new Mac (unix) or Linux client
> > 2) Have graphically attractive & colorful screens, looking enough like
> > standard GUIs (M$, in particular) that users would understand the use of
> > icons, etc.
> > 3) Respond to keystrokes by users -- not only to the click of a "submit"
> > button
> > 4) Require no preparation of the client computers in advance of using
the
> > software, likely directing user to a web page.
> > 5) "type ahead" can be done so that the user is not waiting constantly
for
> > the computer to respond
> > 6) Heads down data entry folks are as happy with this as they were with
> > their green screens when they first got those and have only minor
complaints
> > if converting now from a green screen, none of substance
> >
> > What are the options -- who has written or seen such a GUI?
> >  --dawn
> >
> > Dawn M. Wolthuis
> > Tincat Group, Inc.
> > www.tincat-group.com
> --
> u2-users mailing list
> [EMAIL PROTECTED]
> http://www.oliver.com/mailman/listinfo/u2-users

-- 
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users


RE: GUI or Event ? as nice as character-based

2004-04-19 Thread Tony Gravagno
Side comment, this is too interesting a thread, it almost deserves a forum
of its own.

Dawn asks:
>Does the requirement to have no client-side setup (other than 
>pointing a user to a web page in a std web browser) eliminate 
>accuterm or not?  If not, then does this permit drop-down 
>boxes, combo boxes, calendars for date entry and the usual 
>icons one might expect for various features?

For a web browser there is AccuTerm for Internet Explorer.  ATIE does
require a client-side object, as can be expected, but overhead to the user
is minimal.  To my knowledge, ATIE does support the ATGUI, so yes, while I
haven't tried this, I believe we can get a nice VB-style GUI within the
browser using ActiveX technology.

Related, AccuTerm has a new feature called Visual Styles which allows a
character UI to render much like a GUI, just by assigning styles to common
@(-x) Print sequences.  The stunning effects can be seen on this page:
http://www.asent.com/at2k2borders.asp
I'll repeat and it's important to understand that you are not looking at a
GUI there, you are looking at standard procedural green screen output
(non-modularzied spaghetti...) that simply renders like a GUI within AT.
Much of this can be accomplished with zero code changes if the app already
makes use of visual attributes like Dim, Bold, etc.

Now about the capabilities of ATGUI, drop downs, combos, etc.  You cannot
add your own custom components to ATGUI, and this was originally my beef
with it.  However, seeing a beautiful and rich app created before my eyes
with Symbion I was convinced that we don't need third-party add-ons to build
a really functional GUI for the typical end user.
(No payment received for comments.  :)  )

The trade-off benefit received when we lose third-party component support is
that we do not need to write any GUI code (classes, methods, event handlers,
etc).  In my mind, if the average Pick developer doesn't want to use VB,
Java, C#, etc to manually code their app, then they won't miss the extended
component support.  If they can code on their own then they won't be
considering a GUIRADIDE type environment like AT/ATGUI anyway.

Do note again that interfacing with a tool like ATGUI does require code
modularization.  Once you've done that, a number of similar tools are
available for consideration.  With modularization complete, you can
prototype a UI with ATGUI (free, assuming you already use AT), and then you
can decide which one or more GUI's you want to support after that.

>
>I'm talking about the U2 database, but the tools on the mv 
>side need not be more than UOJ, for example (with support for 
>update of stored fields and preferably also virtual fields as 
>read-only). 

[Ad] To address this mishmosh of connectivity options and issues I'm working
now on a tool which is cross-OS and cross-DBMS capable which will provide a
host of back-end features to client interfaces.  Stay tuned...

Tony
[EMAIL PROTECTED]

--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users


RE: GUI or Event ? as nice as character-based

2004-04-19 Thread Dawn M. Wolthuis
Does the requirement to have no client-side setup (other than pointing a
user to a web page in a std web browser) eliminate accuterm or not?  If not,
then does this permit drop-down boxes, combo boxes, calendars for date entry
and the usual icons one might expect for various features?

I'm talking about the U2 database, but the tools on the mv side need not be
more than UOJ, for example (with support for update of stored fields and
preferably also virtual fields as read-only). 

Thanks.  --dawn

Dawn M. Wolthuis
Tincat Group, Inc.
www.tincat-group.com

Take and give some delight today.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: Monday, April 19, 2004 1:28 PM
To: U2 Users Discussion List
Subject: Re: GUI or Event ? as nice as character-based

Clarify.  Are you talking about *within* the mv environment? Or an outside
app?

Accuterm has the ability to recognize where a mouse-click is in regards to
(col, row).  This is the same col, row that PRINT @ uses.  Now if your mv
programs have a single, standard INPUT subroutine then you can simply modify
that subroutine.

So your modification would look something like
If I.am.using.accuterm then
   if mouseclick then
  get.location; determine.which.field; reset fieldno = this.field
  redo.input = true; return
   end
end else
   input xxx
end

Or something along those lines.
I have only seen one application package that integrated this ability,
however, the screen drivers it built allowed the user to point-and-click and
enter data into any field in any order on the screen.  It was then up to the
programmer to ensure that intra-field dependencies were properly handled.
But it was certainly a good start.

Is that what you meant?
Will

In a message dated 4/19/2004 2:17:34 PM Eastern Daylight Time,
[EMAIL PROTECTED] writes:

> I haven't gotten through all of the postings in the GUI thread as yet, but
> am working on the question of how to write a GUI that is as good as a
"green
> screen" from the perspective of folks currently using a green screen
> application.  I saw hints at that, but nothing that tackled it from the
> standpoint of being able to use any tools on the market today to
accomplish
> this (no need to retain databasic code, for example).
> 
> What could be used to actually replace, completely, the character screens?
> 
> Requirements:
> 0) work with U2 as multiuser databases
> 
> 1) Be able to use any Windows, new Mac (unix) or Linux client
> 2) Have graphically attractive & colorful screens, looking enough like
> standard GUIs (M$, in particular) that users would understand the use of
> icons, etc.
> 3) Respond to keystrokes by users -- not only to the click of a "submit"
> button
> 4) Require no preparation of the client computers in advance of using the
> software, likely directing user to a web page.
> 5) "type ahead" can be done so that the user is not waiting constantly for
> the computer to respond
> 6) Heads down data entry folks are as happy with this as they were with
> their green screens when they first got those and have only minor
complaints
> if converting now from a green screen, none of substance
> 
> What are the options -- who has written or seen such a GUI? 
>  --dawn
> 
> Dawn M. Wolthuis
> Tincat Group, Inc.
> www.tincat-group.com
-- 
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users

--
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users


Re: GUI or Event ? as nice as character-based

2004-04-19 Thread FFT2001
Clarify.  Are you talking about *within* the mv environment? Or an outside app?

Accuterm has the ability to recognize where a mouse-click is in regards to (col, row). 
 This is the same col, row that PRINT @ uses.  Now if your mv programs have a single, 
standard INPUT subroutine then you can simply modify that subroutine.

So your modification would look something like
If I.am.using.accuterm then
   if mouseclick then
  get.location; determine.which.field; reset fieldno = this.field
  redo.input = true; return
   end
end else
   input xxx
end

Or something along those lines.
I have only seen one application package that integrated this ability, however, the 
screen drivers it built allowed the user to point-and-click and enter data into any 
field in any order on the screen.  It was then up to the programmer to ensure that 
intra-field dependencies were properly handled.  But it was certainly a good start.

Is that what you meant?
Will

In a message dated 4/19/2004 2:17:34 PM Eastern Daylight Time, [EMAIL PROTECTED] 
writes:

> I haven't gotten through all of the postings in the GUI thread as yet, but
> am working on the question of how to write a GUI that is as good as a "green
> screen" from the perspective of folks currently using a green screen
> application.  I saw hints at that, but nothing that tackled it from the
> standpoint of being able to use any tools on the market today to accomplish
> this (no need to retain databasic code, for example).
> 
> What could be used to actually replace, completely, the character screens?
> 
> Requirements:
> 0) work with U2 as multiuser databases
> 
> 1) Be able to use any Windows, new Mac (unix) or Linux client
> 2) Have graphically attractive & colorful screens, looking enough like
> standard GUIs (M$, in particular) that users would understand the use of
> icons, etc.
> 3) Respond to keystrokes by users -- not only to the click of a "submit"
> button
> 4) Require no preparation of the client computers in advance of using the
> software, likely directing user to a web page.
> 5) "type ahead" can be done so that the user is not waiting constantly for
> the computer to respond
> 6) Heads down data entry folks are as happy with this as they were with
> their green screens when they first got those and have only minor complaints
> if converting now from a green screen, none of substance
> 
> What are the options -- who has written or seen such a GUI? 
>  --dawn
> 
> Dawn M. Wolthuis
> Tincat Group, Inc.
> www.tincat-group.com
-- 
u2-users mailing list
[EMAIL PROTECTED]
http://www.oliver.com/mailman/listinfo/u2-users