Karsten,
1. Have you tried using Memory( -1 ) to explicitly activate Clipper's
Garbage Collector?
2. I'd strongly suggest a recompile of your app under xHarbour, which is
practically 100% Clipper compatible, and does not suffer from these memory
size limitations.
Ron
"Karsten Stöckmann" <ngc2997@[EMAIL PROTECTED]
> wrote in message
news:fsq39g$ckg$02$1@[EMAIL PROTECTED]
> Hi,
>
> for a few years now, we have been constantly experiencing 667-Errors
> every now and then in our application (Clipper 5.2e / Class(y) /
> Clip4Win / Funcky); lately in an increasing manner. There have been many
> attempts to get rid of this, yet with no lasting effect.
>
> After having inspected "conventional" ways how to fix this issue, I am
> now trying to figure out why memory in Clipper's DGROUP (esp. the Eval
> stack) seems to not being released properly when I'd expect it should.
> We are making extensive use of Class(y) objects, e.g. for windows, UI
> controls, etc. What I'm interested in is: how does a Class(y)
> class/object affect memory in the Eval stack? I.e.: how are instance
> variables managed by means of their memory consumption? And: as far as
> I'd understand, destroying an object should free the resources it used,
> however, while testing I've found out it doesn't. (Or at least, it seems
> so.) For example, when closing a window in our application, the
> underlying object (managing window behaviour, event handling, etc) is
> destroyed via object:destroy(). Doesn't this free the memory used inside
> the Eval stack for instance and/or local variables?
>
> Any ideas appreciated. :)
>
> Best wishes,
> Karsten
>
> --
> PGP Public Key ID 0x708CD1FE (pgpkeys.pca.dfn.de)
> "When the light of day is dead, the spark of night ignites"
|
