 | | From: | Lutz Conrad | | Subject: | Rowset-Setrange | | Date: | Thu, 6 Jan 2005 22:14:03 +0100 |
|
|
 | If I need to change the indexname of a rowset, the current settings of
setRange will be lost.
I can save the current indexname to a variable or property, but not the
current settings of setRange().
So I wish new rowset-properties in witch automatically stored the current
setRange() key limitations.
For example rowset.minRange and rowset.maxRange. Then I could realize the
following sequenz
.......
//Save current environment
cIndex=oRowset.indexname
cHigh=oRowset.minRange
cLow=oRowset.maxRange
cValue=
//Set new properties
oRowset.indexname=
oRowset.setRange(,)
oRowset.first()
//
//Following processing
//.
//Restore old environment
oRowset.indexname=cIndex
oRowset.setRange(cHigh,cLow)
oRowset.findkey(cValue)
.......
Regards
Lutz
www.dbase-tools.de
|
|
| | From: | Ken Mayer [dBVIPS] | | Subject: | Re: Rowset-Setrange | | Date: | Thu, 06 Jan 2005 13:29:19 -0800 |
|
|
| Lutz Conrad wrote:
> If I need to change the indexname of a rowset, the current settings of
> setRange will be lost.
> I can save the current indexname to a variable or property, but not the
> current settings of setRange().
Since setRange() relies on the current index, that makes a certain
amount of sense ... on the other hand, I suppose having a way to save
the settings might be useful.
Ken
--
/(Opinions expressed are purely my own, not those of dataBased
Intelligence, Inc.)/
*Ken Mayer* [dBVIPS]
/Golden Stag Productions/
dBASE at goldenstag dot net
http://www.goldenstag.net/GSP
http://www.goldenstag.net/dbase
|
|
| | From: | Carolyn Charno | | Subject: | Re: Rowset-Setrange | | Date: | Fri, 21 Jan 2005 10:07:44 -0500 |
|
|
| Thanks for posting : I gave this issue a QAID of: 5171
- Carolyn - (dBI)
Lutz Conrad Wrote:
> If I need to change the indexname of a rowset, the current settings of
> setRange will be lost.
> I can save the current indexname to a variable or property, but not the
> current settings of setRange().
>
> So I wish new rowset-properties in witch automatically stored the current
> setRange() key limitations.
> For example rowset.minRange and rowset.maxRange. Then I could realize the
> following sequenz
>
> ......
> //Save current environment
> cIndex=oRowset.indexname
> cHigh=oRowset.minRange
> cLow=oRowset.maxRange
> cValue=
> //Set new properties
> oRowset.indexname=
> oRowset.setRange(,)
> oRowset.first()
> //
> //Following processing
> //.
> //Restore old environment
> oRowset.indexname=cIndex
> oRowset.setRange(cHigh,cLow)
> oRowset.findkey(cValue)
> ......
>
> Regards
> Lutz
> www.dbase-tools.de
>
>
>
>
|
|
| | From: | Todd Kreuter [dBVIPS] | | Subject: | Re: Rowset-Setrange | | Date: | Thu, 06 Jan 2005 16:59:58 -0500 |
|
|
| Lutz Conrad wrote:
>
> So I wish new rowset-properties in witch automatically stored the current
> setRange() key limitations.
This can be none using a custom query class. If you are not using them,
you should .
class LutzQuery of Query()
this.minRange = null
this.maxRange = null
this.rowset.setRange = class::SetRange
function SetRange(uMin, uMax)
this.minRange = uMin
this.maxRange = uMax
return ROWSET::SetRange(uMin, uMax)
endclass
--
Todd Kreuter [dBVIPS]
|
|
| | From: | Lutz Conrad | | Subject: | Re: Rowset-Setrange | | Date: | Fri, 7 Jan 2005 07:34:28 +0100 |
|
|
| > This can be none using a custom query class. If you are not using them,
> you should .
You're right and just this is the way, I've realized the functionality now.
But why we have to create a workaround for this simple enhancement in the
core-product?
Regards
Lutz
www.dbase-tools.de
|
|
| | From: | Todd Kreuter [dBVIPS] | | Subject: | Re: Rowset-Setrange | | Date: | Fri, 07 Jan 2005 07:50:10 -0500 |
|
|
| Lutz Conrad wrote:
>
> > This can be none using a custom query class. If you are not using them,
> > you should .
>
> You're right and just this is the way, I've realized the functionality now.
> But why we have to create a workaround for this simple enhancement in the
> core-product?
I would not consider it a work around. It is a customization to suit
your wish .
If we can do these things so simply on our own, why does it need to be
added to the product? This is why we have the ability to subclass and
override.
--
Todd Kreuter [dBVIPS]
|
|
| | From: | Lutz Conrad | | Subject: | Re: Rowset-Setrange | | Date: | Mon, 10 Jan 2005 16:38:44 +0100 |
|
|
| > If we can do these things so simply on our own, why does it need to be
> added to the product? This is why we have the ability to subclass and
> override.
Let me answer with a little likeness.
When I got my first car, it was an old one from 1971. Yes, it had a
steering-wheel, four tyres, an engine and so on. And I used it some years
and drove many kilometers.
Then I got a new one with built in ABS.
After a few year I got the next with built in navigation too.
Yes, if I want to have the handbreak on the left side, I have to make
changes, but normally I can use the car as it is.
Like this it should be with software too. To hide behind the ability to make
user-created enhancements (which may be helpfull for many users) is in my
opinion no way for development.
Regards
Lutz
www.dbase-tools.de
|
|
| | From: | Todd Kreuter [dBVIPS] | | Subject: | Re: Rowset-Setrange | | Date: | Mon, 10 Jan 2005 12:34:16 -0500 |
|
|
| Lutz Conrad wrote:
>
> Let me answer with a little likeness.
> When I got my first car, it was an old one from 1971. Yes, it had a
> steering-wheel, four tyres, an engine and so on. And I used it some years
> and drove many kilometers.
> Then I got a new one with built in ABS.
> After a few year I got the next with built in navigation too.
The guy who bought the exact same make, model, and year 5 minutes later
from the same dealer had different rims, different interior, different
color, no navigation, manual transmission, power seats for the driver
side only, and a seat warmer for the passenger seat only because his
wife always complains about having a cold behind.
Obviously we disagree on what should be included in the core-product, so
lets move on.
--
Todd Kreuter [dBVIPS]
|
|
