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
