CompuServe Thread

Mike, The issue of Ultracard's relationship with ARexx has me a bit confused also (and is one of two main reasons why I chose to return my purchase of UC to my dealer for refund). My understanding of UC's support of ARexx is that basically it can tell ARexx to execute a Rexx script via the AmigaDos Execute() function, where the command executed is basically the equivalent of "rx uc-arexx-file". Sometimes the 'uc-arexx-file' is an in-line ARexx string script (multiple ARexx statements, separated by semicolons) and sometimes it is an external file name. If that is in fact the level of ARexx support, then Ultracard is NOT functioning as an ARexx host, but is running an external, dis-connected ARexx host (the 'rx' command). This is very different to providing true ARexx support, in which the ARexx host passes a script (file or string) to ARexx (via RexxMast's public port) to execute, and which in turn, RexxMast turns around and passes back "atomic" commands to the Rexx Host program to process as appropriate. No where in the documentation did I see any reference to the "atomic" commands supported by UltraCard when functioning as an ARexx host. Is this a documentation problem? Or is it an implementation problem, which I suspect. In the latter case, I feel that claiming ARexx support is mis-leading, as any program that provides the capability to Execute() any DOS program could (falsely, IMHO) claim ARexx support. There is more to true ARexx support than that. <continued>

<continuation> BTW, the "other" main reason I felt dissatisfied with UltraCard was the inflexibility that it afforded me in terms of Screen sizes when creating new stacks. Since my system has a flickerFixer, and consequently uses a severely over-scanned standard Workbench screen (688 x 470), the only stacks that I can create are ones that will ONLY run on my system. I can't create a stack that will run on a "stock" system, without re-booting my system with a "standard" system-configuration file before I invoke UltraCard. To me, this is a serious design deficiency. I've a couple of other suggestions and criticisms, now that I have your "ear" <grin>. First – documentation. The product is quite complex (which is good), but consequently really requires much better printed documentation. Help stacks and tutorial stacks are nice, but are not a replacement for a good reference manual. It would definitely be worth it if a comprehensive manual were created and included with the package, even if it means that you'd have to raise the price of the produce significantly. It's much to important, and the current level of documentation is simply not sufficient. One other important issue comes to mind. When I have opened up a Stack and gone into Modify mode, there is no way to not save any changes I make (other than the Undo feature, which only operates on the last change made). This really makes "experimenting" difficult, unless I remember to make a copy of the stack I want to play with _before_ I begin playing. The program really needs either a "Don't save the modified stack" command, or at least a <continued>

<continuation> "save as …" command, so that the original stack can be left intact. That's enough for now. I am really impressed with the potential presented by the product and do wish it (and you) well. I'm also impressed with the available demo of the competition, although it's not really fair to compare a demo for an un-released product with a now-shipping product. Currently, UltraCard didn't quite match my expectations, which is why I returned it. That may change in the future. This wasn't meant as a flame. More like constructive criticism. …BobR

I can see that when I start up UCBrowser 1.3 that a port appears name ULTRA1. I had been told that Ultracard was limited to sending ARexx messages via "rx xxxx" rather than via "ADDRESS hhh ssss" (which allows one to enable and examine RESULTS).