Hi Brian,

> Is the Beep important?

Yes.  For example, in my library automation program the user holds a barcode
reader and scans a library card, then a book, over and over, without ever
looking at the computer screen.  The only way the user knows if there's an
error (eg invalid library card or restrictions on checking out) is with a
BEEP.
> it is not a "must have" upgrade

I presume it's better to use the latest version of DP unless something is
removed.  But why remove a potentially valuable function which is already
there? Is there a cost to keeping it there?

Regards,

Larry



On 6/11/08, Brian Hancock <[EMAIL PROTECTED]> wrote:
>
>  Hi Larry,
>
> It seems that the Beep function makes low level BIOS calls, which can be a
> problem with modern operating systems and hardware. Similarly which I also
> forgote to mention is the support for old Hercules Graphic cards. Basically
> the changes are to make it more robust for recent Windows versions.
>
> Is the Beep important?
>
> Note that generally the purpose of this version is to improve command line
> operating for scripting and dynamic web applications, and the underly
> functionality hasn't changed, so unless you are implementing these it is not
> a "must have" upgrade.
>
> Regards
> Brian
>
>
>
> ----- Original Message -----
> *From:* LN <[EMAIL PROTECTED]>
> *To:* Dataperfect Users Discussion Group <[email protected]>
> *Sent:* Thursday, June 12, 2008 6:54 AM
> *Subject:* Re: [Dataperf] New version of DP on the horizon...
>
>
>  Hi,
>
> Why remove the Beep function?
>
> Larry Neuton
>
>
> On 6/9/08, Brian Hancock <[EMAIL PROTECTED]> wrote:
>>
>>  Hi everyone,
>>
>> Lew has been working on a new version of DP with some improvements for
>> scripting, and I have had the pleasure of doing some preliminary testing.
>> Lew doesn't have easy access to the group mailing list and has asked me to
>> ask a few questions.
>>
>> The major thrust of the new DOS based version 2.6Y is to support scripting
>> a little better, this allows it to perform better in web based applications,
>> and also desktop application which are driven by scripts.
>>
>> The major change is that by default if you use the /EI switch to import
>> data from a transaction logs, then reports will output to STDOUT
>> (often referred to as printing to the console). For example if you run the
>> DOS DIR command at a DOS screen the output streams onto the console screen,
>> and after DIR has finished you can still read the output on the console. In
>> contrast a DP report printing to the screen only displays while DP is
>> executing, and is removed from the screen after you exit the report and
>> before DP exits. There are a couple of advantages to being able to output to
>> STDOUT (or the console). Firstly at present to use output from DP in another
>> program you first have to save it to a file in DP, and then open the file
>> with another program to use the data. It is currently not possible to pipe
>> data from one application into another. Many DOS users would be used to
>> piping the output from DIR to the MORE command so you can view the output a
>> page at a time.  There are many advanced text processing tools which could
>> be used with DP more quickly  and efficiently, such as AWK amd SED, etc.
>> The new version allows piping to secondary processes.
>>
>> A major advantage of using STDOUT for output from DP is that data can be
>> sent directly to a web browser or other internet application. At present you
>> need to save the output from DP into a file, and then with another program
>> read the file and output it to the web browser. This has two problems,
>> firstly, there are more steps to getting data to the browser and so is
>> slower, and secondly, until a report finishes and DP exits nothing can be
>> sent to the browser, so there is often a long period of inactivty until the
>> web browser's screen suddenly fills with data. (users often think a problem
>> has occurred with this delay). Using STDOUT, output from DP reaches the web
>> browser screen as it is output from DP, so even a long slow DP report can
>> present results to the user while it is still running.
>>
>> So that is the background to the new version. Some of the changes are:
>> - the ;;W field output formatter will act on normal text fields and not
>> just multiline alphanumeric memo type fields
>> - from a /EI transaction log you can select for more that one report to
>> run, this is a bug fix from 2.6x. This has great benefits in that you can
>> compartmentalise reports. For example, you can have a simple report to add
>> data, another to delete data, and another to edit data, but only need one
>> report to view the output, With the current 2.6x version you must either
>> combine sections of the report the output into each of those operations, or
>> execute DP twice. Now you could specify the two reports as in #R:=3= #R:=10=
>> to run report number 3 and when that is finished run report number 10.
>> - the ;;W acts on all of the XML/XHTML  predefined entities,&  &amp;  "
>> &quot;  ' &apos; < &lt; > &gt;
>> - the ;;W transforms a single line break (carriage return) in a AxAy memo
>> type field to a <br /> instead of <BR> to conform more with XML and XHTML
>> standards.
>> - the ;;W transforms two consecutive line breaks in an AxAy memo field to
>> two line breaks <br /><br /> instead of a single <p>. This also makes it
>> more conforming to XML and XHTML standards.
>> - the ;;W transforms bold markup in an AxAy field to <b>...</b> in place
>> of <B>...</B> to make it conform to standards.
>> - The Beep function is to be removed
>>
>> This leads to the questions, currently the ;;W output for an underlined
>> text in an AxAy field output as <I>....</I> which with HTML indicate italics
>> rather than underline. Lew believes there was a deliberate reason for this
>> rather than just an oversight, as you would normally expect the output to be
>> <u>....</u>. Lew wants to know if this would cause a problem to anyone
>> before he changes it.
>>
>> The other question Lew has, in that with scripting using the /EI
>> transaction log there is no simple way to delete all records from a panel or
>> to empty the database. You can do these with reports, but in comparison to
>> the inbuit function to do this, reports are very slow. Lew would like to add
>> two new functions to the transactions logs. #DA =x= to delete all the
>> records in Panel numbered x, or #DT: , but before he does this he would like
>> to see if people would find it worthwhile.
>> Lew is getting very close to having a candidate for release, but if there
>> are any other bug bears, now would be a good time to air them and I will
>> pass them on to Lew.
>>
>> Lew is also working on a Windows version of DP, but it is early days yet.
>>
>> Regards
>> Brian
>>
>>
>> _______________________________________________
>> Dataperf mailing list
>> [email protected]
>> http://lists.dataperfect.nl/mailman/listinfo/dataperf
>>
>>
>  ------------------------------
>
> _______________________________________________
> Dataperf mailing list
> [email protected]
> http://lists.dataperfect.nl/mailman/listinfo/dataperf
>
>
> _______________________________________________
> Dataperf mailing list
> [email protected]
> http://lists.dataperfect.nl/mailman/listinfo/dataperf
>
>
_______________________________________________
Dataperf mailing list
[email protected]
http://lists.dataperfect.nl/mailman/listinfo/dataperf

Reply via email to