Home > Archive > Clipper > July 2007 > Which method of returning timeslices works under Summer '87?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Which method of returning timeslices works under Summer '87?
|
|
| Scott Coffey 2007-07-23, 6:55 pm |
|
I'm in the process of moving a Clipper application from Windows 98 to
2000. I find that printing (as well as general application
performance) is slower under 2000 than 98. I'm guessing the problem
is due to the Clipper application not yielding timeslices. I read the
FAQ, but I still have questions. I tried OL_AutoYield, but this
appears to not work with Summer '87, and I'm afraid the other
solutions mentioned might fall under the same category. Is there a
solution that is known to work under Summer '87?
I'm a Clipper lightweight. I'm OK with writing and modifying code but
things like link scripts (I use what I inherited) and other "under the
cover" topics give me problems. I've considered moving to a later
version of Clipper, but it all seems fairly daunting to me so I would
prefer a solution to the timeslice problem that would work under
Summer '87. Can anyone help?
| |
|
|
| Scott Coffey 2007-07-24, 6:55 pm |
| On Mon, 23 Jul 2007 16:08:21 -0700, dlzc <dlzc1@cox.net> wrote:
>Dear Scott Coffey:
>
>On Jul 23, 8:11 am, Scott Coffey <n...@noemail.com> wrote:
>...
>
>Looking at the links provided in the FAQ posting, I come up with this:
>http://groups.google.com/group/alt....842ffaa73192f2a
>
>I think what you need is in:
>http://www.the-oasis.net/ftpmaster....tent=ftplib.htm
>... down to "nflib21.zip".
>
>David A. Smith
Thanks for the reply David.
But it appears that the Summer '87 version of the NanForum library
contained in 'nflib21.zip' does *not* contain any counterpart to the
FT_IAMIDLE function. I did track down the 'nice.zip' program
mentioned in the first link, but it doesn't seem to have much of an
effect.
And as it turns out, the slow printing isn't related to cpu hogging,
and I've found a not-so-elegant work-around. First the problem: The
application is point-of-sale. The program prints a receipt. First it
prints a customer copy and then an in-house copy. The first copy
prints OK, but it takes up to 20 seconds to print the second copy. I
found an archived discussion from this group here:
http://groups.google.com/group/comp...k=st&q=&rnum=10
but the OP never chimed back in with a solution. (I hate when that
happens <g> ) I noticed that the OP had tried implementing the
FT_OnIdle solution and it still didn't solve his problem, so that told
me the problem lies elsewhere. I tried implementing some of the other
suggestions in the thread, and the thing that worked was to print to a
file and then copy the file to LPT1. I would prefer another solution,
but that's the only thing I've found so far that works.
In the meantime, I've decided to bite the bullet and move to 5.3. I've
been wanting to do this for a while, and I feel I'm going to need some
of the feature that can only be found in 5.3, so I'm taking the
plunge. I spent most of the day yesterday working on the move, and
have run into a couple of snags. I'll be posting about those in
different threads.
Once again, thanks for your help.
| |
|
| Dear Scott Coffey:
On Jul 24, 11:26 am, Scott Coffey <n...@noemail.com> wrote:
....
> In the meantime, I've decided to bite the bullet
> and move to 5.3. I've been wanting to do this for
> a while, and I feel I'm going to need some of the
> feature that can only be found in 5.3, so I'm
> taking the plunge. I spent most of the day
> yesterday working on the move, and have run into
> a couple of snags. I'll be posting about those
> in different threads.
If you are going to change anyway, you might want to consider other
options. xHarbour.org is pretty solid, and generates Windows (and
Linux) native code. And xHarbour.com has some neat features that you
can probably live without, but might be nice (read "salable") things
to have in your toolbox.
David A. Smith
| |
| Klas Engwall 2007-07-24, 6:55 pm |
| Scott,
>But it appears that the Summer '87 version of the NanForum library
>contained in 'nflib21.zip' does *not* contain any counterpart to the
>FT_IAMIDLE function.
That is unfortunately a correct observation. S87 and 5.x require
completely different solutions to the CPU hogging problem.
>I did track down the 'nice.zip' program
>mentioned in the first link, but it doesn't seem to have much of an
>effect.
Pete Disdale, the author of both the Nice TSR and the Clipper-callable
Benice, said in a thread with subject "S87 app is hogging the CPU,
what is best fix" in April 2003 that it is not likely to do anything
under NT/2K/XP etc. I have seen recommendations to try TameDos from
www.tamedos.com instead but have not tried it myself.
>And as it turns out, the slow printing isn't related to cpu hogging,
>and I've found a not-so-elegant work-around. First the problem: The
>application is point-of-sale. The program prints a receipt. First it
>prints a customer copy and then an in-house copy. The first copy
>prints OK, but it takes up to 20 seconds to print the second copy.
>I >found an archived discussion from this group here:
>http://groups.google.com/group/comp...k=st&q=&rnum=10
>but the OP never chimed back in with a solution.
That thread died before arriving at the solution. It mentions SET
PRINTER TO <nothing> at the end of the print job, and that is an
important part. But nothing will happen unless there is also SET
PRINTER TO LPT<n> at the beginning. The 20-30 second delay has been
discussed in many threads over the years, and most of the time it
turned out that the problem code was missing the initial opening of
the print device so Clipper could not know which device to close at
the end. So check that you have SET PRINTER TO LPT<n> at the top of
the print routine and SET PRINTER TO <nothing> at the end. You will
have to do that whether you stay with S87 or upgrade to 5.x
>In the meantime, I've decided to bite the bullet and move to 5.3
Then you will also need a 5.x compatible time slice release solution.
I use FT_IamIdle() with FT_OnIdle() from the Nanforom Toolkit ver 3.05
and get 1-2% CPU usage when the application is idle. There is a
required patch plus instructions for use at
http://www.engwall.com/clipper/nfpat1a.htm
Regards,
Klas
-------
klas dot engwall at engwall dot com
http://www.engwall.com/clipper/
The LFN Library for Clipper
The LanMan Library for Clipper
The NFPAT1A Timeslice release patch for the Nanforum Toolkit
| |
| Damir Hodak 2007-07-25, 3:55 am |
| On 23 Jul 2007 10:11:01 -0500, Scott Coffey wrote:
> I'm in the process of moving a Clipper application from Windows 98 to
> 2000. I find that printing (as well as general application
> performance) is slower under 2000 than 98. I'm guessing the problem
> is due to the Clipper application not yielding timeslices. I read the
> FAQ, but I still have questions. I tried OL_AutoYield, but this
> appears to not work with Summer '87, and I'm afraid the other
> solutions mentioned might fall under the same category. Is there a
> solution that is known to work under Summer '87?
>
> I'm a Clipper lightweight. I'm OK with writing and modifying code but
> things like link scripts (I use what I inherited) and other "under the
> cover" topics give me problems. I've considered moving to a later
> version of Clipper, but it all seems fairly daunting to me so I would
> prefer a solution to the timeslice problem that would work under
> Summer '87. Can anyone help?
Hi Scott!
Try this:
http://www.pdlhost.demon.co.uk/clipper/nice_12.zip
or
http://www.pdlhost.demon.co.uk/clipper/benice.zip
| |
| Scott Coffey 2007-07-25, 6:55 pm |
| On Tue, 24 Jul 2007 22:04:31 GMT, klas.engwall@nospam.please (Klas
Engwall) wrote:
>Scott,
>
>
>That is unfortunately a correct observation. S87 and 5.x require
>completely different solutions to the CPU hogging problem.
>
>
>Pete Disdale, the author of both the Nice TSR and the Clipper-callable
>Benice, said in a thread with subject "S87 app is hogging the CPU,
>what is best fix" in April 2003 that it is not likely to do anything
>under NT/2K/XP etc. I have seen recommendations to try TameDos from
>www.tamedos.com instead but have not tried it myself.
>
>
>That thread died before arriving at the solution. It mentions SET
>PRINTER TO <nothing> at the end of the print job, and that is an
>important part. But nothing will happen unless there is also SET
>PRINTER TO LPT<n> at the beginning. The 20-30 second delay has been
>discussed in many threads over the years, and most of the time it
>turned out that the problem code was missing the initial opening of
>the print device so Clipper could not know which device to close at
>the end. So check that you have SET PRINTER TO LPT<n> at the top of
>the print routine and SET PRINTER TO <nothing> at the end. You will
>have to do that whether you stay with S87 or upgrade to 5.x
Bless you. <g> That worked like a charm.
>
>Then you will also need a 5.x compatible time slice release solution.
>I use FT_IamIdle() with FT_OnIdle() from the Nanforom Toolkit ver 3.05
>and get 1-2% CPU usage when the application is idle. There is a
>required patch plus instructions for use at
>http://www.engwall.com/clipper/nfpat1a.htm
Thanks. I plan to do just that.
| |
| Scott Coffey 2007-07-25, 6:55 pm |
| On Tue, 24 Jul 2007 14:17:51 -0700, dlzc <dlzc1@cox.net> wrote:
>Dear Scott Coffey:
>
>On Jul 24, 11:26 am, Scott Coffey <n...@noemail.com> wrote:
>...
>
>If you are going to change anyway, you might want to consider other
>options. xHarbour.org is pretty solid, and generates Windows (and
>Linux) native code. And xHarbour.com has some neat features that you
>can probably live without, but might be nice (read "salable") things
>to have in your toolbox.
Thanks for the suggestion David.
My bread and butter is *not* Clipper programming. I'm a contract
programmer that supports IBM AS/400 applications for various clients.
One of those clients also has a POS system written in Clipper and
that's why I'm posting here.
Having said that, I've read with interest the comments in this group
about xHarbour and there may certainly come a time when I need some
capabilities that Clipper can't provide. It's good to know that
resource is there.
| |
|
|
| pete@nospam.demon.co.uk 2007-07-25, 6:55 pm |
| In article <a2nea3p9qibi3bibjnqc6smgqkjkeu7b68@4ax.com>
none@noemail.com "Scott Coffey" writes:
> On Wed, 25 Jul 2007 10:17:48 +0200, Damir Hodak
> <damir.hodak@zg.t-com.hr> wrote:
[..]
>
> Thanks for the links Damir. If I get stuck on Summer '87 I will
> certainly give these a try.
Don't raise your hopes, Scott. These utils were written for a
Win9x environment which still had a "proper DOS" int21h
capability -- I'd guess they will do nothing in a NT/XP setting.
Were I in your situation, I'd explore the [x]Harbour route to
move your S'87 app to a native Windows app -- and surrender your
will to Bill Gates...
Pete
--
"We have not inherited the earth from our ancestors,
we have borrowed it from our descendants."
| |
| Scott Coffey 2007-07-26, 6:55 pm |
| On Wed, 25 Jul 2007 18:11:45 +0000 (UTC), pete@nospam.demon.co.uk
wrote:
>In article <a2nea3p9qibi3bibjnqc6smgqkjkeu7b68@4ax.com>
> none@noemail.com "Scott Coffey" writes:
>
>[..]
>
>Don't raise your hopes, Scott. These utils were written for a
>Win9x environment which still had a "proper DOS" int21h
>capability -- I'd guess they will do nothing in a NT/XP setting.
>
>Were I in your situation, I'd explore the [x]Harbour route to
>move your S'87 app to a native Windows app -- and surrender your
>will to Bill Gates...
>
>Pete
LOL. But I've pledged allegiance to IBM!
| |
|
| Been on vacation or I would have posted this earlier.
S87 does not hog the CPU under W98 or W2000 or even XP unless you use
the nanforum lib. I don't and you should check to see if your app
does.
I suspect that the slowness that you experience has to do with W98 vs
W2K resource demands. W2k takes much more memory and cycles with all
its bloat. If you did not upgrade the processor significantly in the
upgrade...
The slow printing is probably addressed in the archives.
|
|
|
|
|