Re: Nine to Five Reports and Rev
One of my clients is still using HyperCard and Reports DataPro, but I'm working on migrating him to mySQL with a RunRev standalone UI. I haven't delved into report generation yet, but I know there are plenty of specialized SQL-based report design applications available, such as Crystal Reports, Elixir Report, Express Report Pro, and many others. So, I'm tentatively planning on not using Revolution for any but the most simple reports, and finding a dedicated app to build more complex reports. Of course, this may not work well. Most of the business logic lives in the Rev client app, and outside report generation tools probably won't have access to that business logic. I'm not yet clear on whether this will be a problem. Clearly it would be beneficial to have report generation tools within Revolution, similar to those found in dedicated reporting apps. But it might also be possible to find an existing tool that can communicate with a Rev app, maybe through a protocol such as SOAP. That way, business logic can be centralized, without having to write separate code for the report generating app. I'll report back here if I find anything useful along those lines. ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Nine to Five Reports and Rev
On Wednesday, May 28, 2003, at 06:01 AM, Richard Gaskin wrote: To make sure we keep a useful focus, let's return to the basics for a moment: What do folks need to print? What challenges are they currently facing implementing that? Hi Richard After speaking extensively on the need for a (Nine to Five) Reports workalike about a year ago, I've been staying in the background for a while waiting to see what the new 2.0 report generator had to offer. So, in answer to your question: what do I need to print? Well, initially at least I need to do the same things I've been doing in Hypercard for more than 10 years: I store a lot of information relating to single business transaction (e.g. - an Insurance risk) on a single card, or across a series of cards in different stacks which are related by a field common to each stack which is indexed (fld control number - I used Nine to Five Index for this). So for a single insurance risk I might typically have single card in main stack (Underwriting) and possibly multiple related transactions such as Endorsements and Claims which are related to the unique Underwriting card by the indexed control number field which they share in common. So far, none of this presents much of a problem in RunRev. And although I've had to roll my own index scheme and a lot of goodies such as calendars and other specialized dialogs, RunRev's capabilities which are far more extensive than Hypercard allow many more ways to skin these cats. With the stack setup described above I typically generate a great variety of single page documents which relate to the data contained on a single card. For example, from the Underwriting stack I will initially generate a cover letter, a detailed quotation, a billing sheet, pro-forma invoice and any number of documents related to the data contained or concatenated from fields on a single card. In Nine to Five Reports the fields on a report layout can get their data from a single field, a calculated combination of any number of fields or a global variable. It is the last of these that really gives the Nine to Five Reports scheme its versatility since what goes into a global is completely under script control and these can be populated interactively by special handlers which may be called as each stage of the printing progresses - i.e. beforeCard, beforeHeader, afterheader etc. It seems to me that any RunRev report scheme that allows a report object to be populated by a global would allow, with a bit of scripting, for the use of data stored in any valid RunRev container. Of course, Nine to Five Reports also allowed typical spreadsheet type reports, also under full script control. You would simply layout a single detail section which would then be repeated for each card in the selected set. I'm sure there are a number of bells and whistles that might be added to the wish list but I really think that this is the way that most users of Hypercard/Nine to Five Reports made use of the product for printing Nine to Five Reports ALSO provided a number of related very useful utilities. Most notable of these (IMHO) were the Search and Sort Engine and the Import and Export stacks which allowed you easily transfer data from one stack to another by matching up the background fields of a source stack to those a target stack with a simple drag and drop interface. These have been an incredibly useful tools for MY needs and although I haven't yet gotten around making my own yet, I wouldn't be surprised if one or more of you guys already have this stuff on the shelf. If so, please feel free to contact me as a really hate reinventing the wheel (especially since round is such a good solution). If it's easy to use and the price is reasonable I AM willing to pay. At this time I have just downloaded Runrev 2.0 - and perhap a lot of this stuff IS in the report generator/manager contained therein, but I can't find any documentation about the capabilities of this feature set and a really detailed tutorial on its use would be greatly appreciated. Alan ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Nine to Five Reports and Rev
At 7:30PM -0700 5/28/03, Alan Gayne wrote: At this time I have just downloaded Runrev 2.0 - and perhap a lot of this stuff IS in the report generator/manager contained therein, but I can't find any documentation about the capabilities of this feature set and a really detailed tutorial on its use would be greatly appreciated. If you go to the Development Guide page of the documentation window and click Printing, you'll find some topics on report printing - start with How to print a report and check out the See Also topics for it. (This is not documented in as much detail as I'd like yet, but the basic information is there.) -- Jeanne A. E. DeVoto ~ [EMAIL PROTECTED] Runtime Revolution Limited - Software at the Speed of Thought http://www.runrev.com/ ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Nine to Five Reports and Rev
Several people commented on the discussion about the availability of a Nine to Five Reports product equivalent in Revolution. FWIW, I did not find Reports to be buggy, though it was a tad obtuse and therefore easy to misuse, which may have been mistaken for bugs. I'm sure there *were* bugs (all software has bugs except for mine! :-) ), but I wouldn't characterize Reports as buggy. I agree with the analysis that it would be easier to create reports directly in Transcript than to try to mangle an external that would do so. However, if someone came up with a stack/app in Rev that handled most or all reporting functionality sufficiently generically and extensibly, I think it would be a world-beater of an app. I'd buy one for sure! -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- .-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Dan Shafer Technology Visionary - Technology Assessment - Documentation Looking at technology from every angle http://www.danshafer.com 831-648-1738 Voice - 831-401-2283 Fax ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
Re: Nine to Five Reports and Rev
Dan Shafer wrote: I agree with the analysis that it would be easier to create reports directly in Transcript than to try to mangle an external that would do so. However, if someone came up with a stack/app in Rev that handled most or all reporting functionality sufficiently generically and extensibly, I think it would be a world-beater of an app. I'd buy one for sure! Here's the deciding question: How _much_ would you pay? I've been looking into this for years, and since I once made my living selling parts to xTalkers I've been trying to find a viable business opportunity with this. Thus far dense clouds, no rain. It seems printing needs for most Rev folks could be categorized like this: - Large blocks of text, which can be done with revPrintField - Labels and other grid-based layouts, which can be handled with Rev 2.0's Report Generator - Single-page forms, which can be handled by just laying it out and printing the card - Things not handled by the first three, which are often too weird to be easily generalized, if at all And that's just layouts. The real power of Reports was in the layout tools and queries. Layout tools are easy enough -- it's really just the pointer tool with a palette to bind fields to data. It's the latter that's hard in Rev if one attempted to write The Ultimate Printing Tool: where is the data coming from and how is it structured? With custom props, SQL, Valentina, etc., we're not just talking about walking through background fields anymore. In most cases, if you can handle the other aspects of app development you can probably lay out some fields and issue a print command. The tricky stuff is like the example from last year when the topic came up, an interestingly complex case but not likely to be of general use any more than some of the more complex reports in HyperRESEARCH (another MC-based app). If we left data gathering up to the user, how many folks would need a tool that does just formatting? And again, how much would they pay? So one challenge from a business perspective is that it must be priced low enough to make it worth buying instead making a custom solution that does exactly what you need, but it must be flexible enough to appeal to as many different developers as possible, with the foreknowledge that some unique types of reports could not be generalized affordably -- those potential customers with the most complex printing needs may still need to roll their own for the hard ones, and those with the simplest needs already have three types of printing solutions available. And that's before we start exploring support costs. Sure, in the mind of an experienced person like you the dividing lines between The Ultimate Print Tool, Rev, the MC engine, and the printer driver are probably pretty clear, or at least you could follow a set of guidelines issued with your license for The Ultimate Print Tool. But as Rev's audience grows, one could expect new developers to call everytime their customers report a printing-related issue. Just the cost of referring people to the appropriate party could eat up a prohibitive amount of time (there are some pretty sloppy drivers out there, and very, very few end-users who report having the latest driver have actually even checked the vendor's site). If I can find a way to do this profitably I'd be a fool to turn down the cash. But thus far the level of effort to generalize and support a universal printing tool seems likely to cost far more than the aggregate of writing print routines for the task at hand, many of which use the preexisting solutions listed above. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.2: Publish any database on any site ___ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc ___ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
