f



Destroying Objects

Hello All,
   I'm new to the group and still fairly new to xHarbour but have an existi=
ng piece of code to support that I'd like some help with please.

   In one program a public array is declared, the user can then select a me=
nu option which runs another PRG that allows the scheduling of jobs to deli=
very vehicles.  This code has a function which in turn has a local variable=
 that is used to create an instance of the schedule class, this is then add=
ed to the array.

oSchedule :=3D Schedule():New(TmpDate, mScType, Val( Left(mScSite1, nSiteLe=
n) ), Val( Left(mScSite2, nSiteLen) ), .F., Space(10), .F., .F.)

Aadd(aSchedule, oSchedule)

The user can have multiple schedules visible but the local variable is rele=
ased at the end of the function, the function is called again for additiona=
l schedules which builds up the array.  When the user is finished with the =
scheduling PRG the array is scanned to close windows and tables then the ar=
ray is emptied with=20

aSchedule :=3D {}

Some of our users are running our system on a virtual machine in a citrix e=
nvironment and through day experience a slowing down when entering the sche=
dule screen.  I think this is due to whatever limits there are on resources=
 in the virtual environment and our code not releasing those resources.

So my question is, in the above example do the objects of class schedule st=
ill exist after the array is set to empty and all the code does is remove a=
ny reference/pointer to them?  If this is the case is there a command to de=
stroy those objects that I can use after their window and tables have been =
closed?

Thank you
Rich
0
Richard
11/10/2016 10:07:00 AM
comp.lang.xharbour 5470 articles. 0 followers. Post Follow

1 Replies
120 Views

Similar Articles

[PageSpeed] 58

Dear Richard Graham:

On Thursday, November 10, 2016 at 3:07:01 AM UTC-7, Richard Graham wrote:
>    In one program a public array is declared,

OK, either make this array a DBF, or create a function that stores and retrieves data:
http://www.ghservices.com/gregh/clipper/trix0001.htm

> the user can then select a menu option which runs
> another PRG

.... and this will likely be complied into a single executable, or could be.

> When the user is finished with the scheduling
> PRG the [public] array is scanned to close windows
> and tables then the array is emptied with 
> 
> aSchedule := {}

You might try to release it, then recreate it, but...

> Some of our users are running our system on a
> virtual machine in a citrix environment and
> through day experience a slowing down when
> entering the schedule screen.

You could record a time stamp between major operations when "entering the schedule screen", and write this information to a text file.  That would allow you to narrow down the statements that generate the problem.

> I think this is due to whatever limits there
> are on resources in the virtual environment
> and our code not releasing those resources.

If you compile / configure so that rather than dump the schedule array, the entire executable is dumped, and returned to a light menu program, then resources may be released better.

> So my question is, in the above example do
> the objects of class schedule still exist
> after the array is set to empty and all the
> code does is remove any reference/pointer to
> them?

Supposed to, but that doesn't mean the virtual environment is reclaiming those resources.  A better solution is to push new entries into a database, even a temporary database...

> If this is the case is there a command to
> destroy those objects that I can use after
> their window and tables have been closed?

release aSchedule
.... but no guarantee that the VE will be impressed or respond.

You might create the database with a temporary name:
http://www.ousob.com/ng/tools1-3/ng9fb4d.php
Create it with the structure outlined as you show above, and give it the alias "aSchedule"
.... remember to close it, and then delete it (or just reuse the file, allowing the create operation to overwrite previous iterations.

David A. Smith
0
dlzc
11/10/2016 2:17:05 PM
Reply: