Loading time on PPL 1.30 and some questions

[DirectDance]

Hi Kornalius,

first of all, thank you for the 1.30 release. The loading time of a bigger ppl file is, after compiled once, fantastic.

It is even working when loading program modules using run and call commands. Congratiolations for this! Now it is possible to create even bigger projects without letting the user wait until the program is started for almost 1 minute.

You told in an older thread, that it will be possible by using a switch or something else, to change the loading / compiling status bar against a standard wait cursor. It would be nice if you can give me a hint how to do this.

I have read your thread re the 1.31 version and that the memory problem of the invoke problem will not be resolved in that version (it is not on the list). Do you have any idea when this one will be resoved?

Re POOM, I have recognized, that it is now a must to create the POOM object in every subroutine and kill it by leaving. In v1.25 it was enough to create it once while starting the project and kill it by leaving it. If a POOM variable was created in one proc (createcomobject) and from this one, another proc is called, the poom object is not accessable anymore. The variable to wich the poom object was assigned still have the value but not the real object.

Have you allready changed something re poom?

Many thanks,
DirectDance

[kornalius]

To remove the loading window, just use the QuietMode(True) function before calling something.

Re POOM, I will have to look into it further for a later version. I don't know why this would have changed since 1.25 but please send me a sample code file that replicates this issue so I can test it.

Re Invoke memory issue, I don't have a solution, I believe it is the POOM itself that is very badly coded, since the other COM objects that I have tested with on the desktop don't produce memory leaks. I suspect there is something else we have to do with the POOM to free the memory or POOM as memory leaks (I wouldn't be surprised).

[kornalius]

Sorry I just realized why it's only working in one procedure not in the other. I have added COM object handle's to the garbage collector which deletes them when not freed at the exit of each procedure.

I will remove that, I thought it made sense but it doesn't. Things will be back to normal in 1.3.1.

I still don't have an idea as to why POOM is leaking.

[DirectDance]

Hi Kornalius,

thanks for your reply.

Re the memory problem using poom, I have found something really interesting wich could help a lot (or maybe not ...).

In my origin example (memloss.ppl) I have runned the code directly in the for-next loop. If copieng the content of the for-next loop into a proc and only call it in the for-next loop, the result is totally diffrent. Only a small amount of memory is allocated but it doesn´t matter if you perform the loop only 2 times or 200 times.

In short, I have changed only this:


for(u$, 1, 10, 1)
poom$ = CreateCOMObject("PocketOutlook.Application");
result$ = Invoke(poom$, "logon");
folder$ = Invoke(poom$, "GetDefaultFolder", 10);

... and so on ...
end;

to

proc test
poom$ = CreateCOMObject("PocketOutlook.Application");
result$ = Invoke(poom$, "logon");
folder$ = Invoke(poom$, "GetDefaultFolder", 10);

... and so on ...
end;

for(u$, 1, 10, 1)
test;
end;


I have attached the changed memloss.ppl to this thread where you can see both of those versions in one source file and the big difference of both versions re the memory loss.

Please, let me know if this will help.

Many thanks,
DirectDance[br]1190209725_11_FT6672_memloss.zip

[DirectDance]

Ahh, I have written the thread before I have read your new one re the garbage collector. Maybe it is better NOT TO REMOVE this. If you read my thread above, maybe this is better now in V1.30 using the garbage collector ??? If you will turn it back, maybe even the trick with the subroutine is not working anymore ...

It looks like, what you have changed has resolved the issue at all if used in a subroutine !! I will investigate this furtheron but please DO NOT REMOVE THIS CHANGE

[kornalius]

I had to remove the it because it didn't make sense. You need to be able to carry the the POOM object from proc to proc in the program.

Even with the garbage collection in place, all it does it call up the FreeCOMObject() function at the end of the proc. Why does it not take memory when placed in a proc and in a for loop it does? That is a very weird one, are you sure you are freeing all objects correctly in the for loop?

Ha I just saw your errors:

1. Use FreeCOMObject(poom$) and not Free(poom$);
2. You need to FreeCOMObject(loadmycontact$);
3. You need to FreeCOMObject(items$);
4. You need to FreeCOMObject(folder$);

loadmycontact$, items$ and folder$ are COM objects returned by Invoke() or GetProperty().

The For() loop should now give you the same amount of memory the proc uses.

[DirectDance]

You wrote:
1. Use FreeCOMObject(poom$) and not Free(poom$);
I did it, the sourcecode I have attached in the thread before lists:

freecomobject(poom$);
free(poom$);

in both, the proc test and implemented in the winmain. I did the free, too, to be suhre, that even the variable itself will be deleted. The free command does not matter the free memory at all, it can be deleted.

You wrote:
2. You need to FreeCOMObject(loadmycontact$);
3. You need to FreeCOMObject(items$);
4. You need to FreeCOMObject(folder$);

If I kill (freecomobject) the childs of poom, the next loop will crash. The poom object still includes the functions but the childs are not valid anymore. Errors like adress missaligned will appear.

Btw., are you suhre, the normal free command will free all variables? I implemented a function in my project, that is displaying the free memory by clicking a button. I am freeing all variables by the free command in that subroutine directly after a showmessage wich is displaying the free memory. But after pressing the knob and closing it and pressing it again, and so on, each call is killing 8 kb of memory.

But back to the poom problem. I think, I know what the problem is. The sub proc "test" is not killing memory because after every cycle, the whole poom object is killed and every child of poom like item$, folder$, etc. are only called once. I think, in this situation, PPL still have the pointer to the created new object. But in reality, that it is not possible to delete the whole poom object after each cycle.

For example, this snippet will load calendar items greater 1.1.2007


//Set start on Calendar Items
poomfind$ = invoke(poomitems$, "find", "[" % "Start" % "] >= \"" % "01.01.2007" % "\"");

while (poomfind$ > 1)
poomoid$ = getproperty(poomfind$, "oid");
poomloadappointment$ = invoke(poom$, "GetItemFromOid", poomoid$);

//do something with the poom object

//Next calendar item wich is greate than 1.1.2007
poomfind$ = invoke(poomitems$, "findnext");
end;

In this case, it is not possible to clear the whole poom object each cycle. And if there are e.g. 20 Appointments found, the poomoid$ and poomloadappointment$ have created 20 comobjects, each. Freecomobject to poom is only deleting the last objects assigned to poomoid$ and poomloadappointment$.

It would be perfect, if PPL will be able to overwrite the last objects assigned to those variables, if the same variables (poomoid$ and poomloadappointment$) are used in the next cycle again.

It seems, that PPL is creating a new comobject each cycle. When it is done and freecomobject is used, only the assigned comobject from the last cycle is deleted but the ones before are lost and blocked from memory (PPL can not delete it because the pointer to the comobjects is lost).

Could that be the reason ?

[kornalius]

FreeCOMObject should delete the COM object contained in the variable at the time of execution.

An Invoke() or GetProperty() that creates a new COM object should be freed before it's variable is assigned a new one.

For loop
t$ = GetProperty...
FreeCOMObject(t$);
end;

In your case you will have to store each new COM object in an array and then FreeCOMObject each element in the array to clear all COM objects from memory.