Memory gone...

[Marc Verkade [Marti BV]]

Hello to all,
Our users are noticing that our app is getting slower after a while...
Retsrt the app and than it runs fast again...
After some checks, we discovered that we loose memory...

Can anybody explain why an app is using more and more memory...

I've check by creatinbg the snadard MDI App and then check the memory load
with Windows tasklist after opening and closing the about box several
times..

9.332 KB
9.528 KB
9.544 KB
9.580 KB
9.604 KB
9.620 KB
9.636 KB

You see that after opening and closing it 7 times, it costs the app about
300 Kb more..
Wil the CG release this memory sometimes?
Does anybody else experience this too?
Can anybody explain this?

Grtz, Marc

[Marc Verkade [Marti BV]]

Hello,
When using this code, the memory loss is less..
Can anybody explain this?
I do notice however that memory that is once taken, is not released after
you close a window.
Grtz, Marc

METHOD WinHelpABout CLASS StandardShellWindow
LOCAL oWindow AS HelpAbout
oWIndow:=HelpAbout{SELF}
oWIndow:Show()
oWIndow:Destroy()
oWIndow:=NULL_OBJECT
IF !InCollect()
CollectForced()
END
RETURN NIL

9.360
9.588
9.600
9.600
9.604
9.604
9.608
9.608

"Marc Verkade [Marti BV]" <ma...@martiXYZNOSPAMZYX.nl> schreef in bericht
news:411bee36$0$205$58c7...@news.kabelfoon.nl...

[Marc Verkade [Marti BV]]

After some time when not doing anything to the standard MDI application, the
memory size keps increasing after I gave it focus with ALT-TAB and then give
anpother ap focus...

The memory is increase from 960 KB to 9692 Kb without opening any window or
doing anything...
Strange... Does anybody know what this is and how to prevent this because
our ap is increasing in 20 minutes fomr an intial memoryload of 67 MB to 92
MB, and then I openened only some windows! That is causing the slowness on
some older machines...

Grtz, Marc

"Marc Verkade [Marti BV]" <ma...@martiXYZNOSPAMZYX.nl> schreef in bericht

news:411bf018$0$205$58c7...@news.kabelfoon.nl...

[Phil McGuinness]

Marc,

I would like to confirm I have the same problem [Vo2.5b3 ]
I would like to know in VO2.7b patch can this be fixed.
If Brian wants a sudden major change to the VO2.7 product from previous
version this will be the big one to get that going. I cannot see in my
code what is wrong and I have spent so much time on this issue.
I have a DW and many tabs and the memory loss is a maximum 20 openings /
closings before I run out of memory.
Increasing Dynsize( gets around the issue but there is only so far you can
take this.

Phil McGuinness - Sherlock Software
--

[Craig Dawson]

Marc & Phil,

After seeing your posts, I became concerned that maybe it was also happening
in my apps, and if it was then i'd better jump on it quick - so I did some
checking. I also have datawindows with many tabs so memory loss would be a
big issue for me also.

I can tell you both though that (at least in VO2.7a), my apps seem to be
running fine and are not experiencing the same things that you are
reporting. When windows are closed, memory is being returned as far as I can
tell.
In the field, customers are not having issues with that either - and the
feedback is that is they see it as being more stable that my main
competitors (MYOB & Quicken). Customers also have it running on different
OS's (98,2000,XP, Terminal Server, etc) and with a user base now in the
1000's, I am very pleased with 2.7a's performance.

We also had a display at a trade show down in Melbourne 2 weeks ago and our
apps were running on several computers non-stop and were given an absolute
caning from many prospective customers there (you know - the ones that like
to click on anything they see to try to crash it). Another major display
running from a projector had our main app running on a 3 metre high screen
and it performed all day 8am to 5pm (much to our delight) without a single
glitch.

If there is any memory creep/loss happening, it appears to be minimal if at
all.

Have you guys tried compiling your apps in 2.7a? What are your findings
then?
Are there any other developers out there seeing the same thing?

Craig Dawson
Control Information Systems
-----------------------------

"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:2o2cuhF...@uni-berlin.de...

[Michael Rubinstein]

Phil, I had similar problems and mine were self-inflicted. I use a quite
complex GUI with Tab Control on a Dialog Window. Tab pages are Split Windows
and Split Window panes are either Dialog Windows or List View/Tree View. I
used to chew up memory when launching and quitting the application multiple
times. I fixed the problem by going through my code and cleaning up. I found
that using protected variables for windows that are tab pages is looking for
trouble. Instead I instantiate these in the PostInit() using LOCAL and
access page windows through TabControl:GetTabPage(). The destruction of
windows that are on a Tab Control page is handled by the
TabControl:DeleteAllPages(). After I made these changes the leak
disappeared.
I am very cautious about using DynSize(). In my experience whenever
DynSize() trick made a difference, it simply masked a problem that would
eventually pop up.

My 2 cents, Michael

"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:2o2cuhF...@uni-berlin.de...

[Phil McGuinness]

Craig,

I will email you a test rig that shows what is happening in your app.
I can tell you that I open lots of other windows aDW/ DD and DLG and there
seems to be no issues.

The only common like so far is DW with a Tabcontol and this has other DW and
heaps of bBrowsers.
I just wonder with the destroying of the owner DW where the resources /
memory etc ever fully get released.

This app has been running in the field for 2 years and if they do not open
and close a particular area of the program XX amount of times there are no
issues... but I have few who want to open and close stuff all the time.

[Phil McGuinness]

snip[ Phil, I had similar problems and mine were self-inflicted. ]

and I am happy to admit they are.. when I can find them. <G>

snip[ In my experience whenever DynSize() trick made a difference, it simply

masked a problem that would

> eventually pop up. ]

I agree.. but it at least gets around an issue.
--
snip[ I found that using protected variables for windows that are tab pages
is looking for trouble. ]

But this is exactly how VO works.... so what are you saying..VO has a
problem. Might confirm what I am seeing.
---
snip[ Instead I instantiate these in the PostInit() using LOCAL and access

page windows through TabControl:GetTabPage(). The destruction of windows
that are on a Tab Control page is handled by the

> TabControl:DeleteAllPages(). ]

I will keep running my tests...

[Alwin Nederpelt]

Marc,

I've seen this in one of my apps
Everytime a window was created with a logo like:

SELF:oDCccLogo:NewImage(_GetInst(),"RESOURCE_AE_LOGO_JPG")
NewImage is the dibcontrol class
RESOURCE_AE_LOGO_JPG is the resource.

It keeps on eating memory,
I fixed it temporarly by keep using the same window again (hide/show)
because it's a service. But when remarking the image creation, it is
fixed.

alwin

[Marc Verkade [Marti BV]]

This morning the app uses 9788 Kb...
Grtz, Marc

"Marc Verkade [Marti BV]" <ma...@martiXYZNOSPAMZYX.nl> schreef in bericht

news:411bf1e5$0$742$58c7...@news.kabelfoon.nl...

[Marc Verkade [Marti BV]]

> The only common like so far is DW with a Tabcontol and this has other DW
and
> heaps of bBrowsers.

This is exactly what I am using too!

Graig, do you have tabwindows and bbrowsers?
Grtz, Marc

"Phil McGuinness" <hey...@sherlock.com.au> schreef in bericht
news:2o2qfkF...@uni-berlin.de...

[Erik Visser]

Wait a little while and it is my zip-code.
<g>

Erik

"Marc Verkade [Marti BV]" <ma...@martiXYZNOSPAMZYX.nl> schreef in bericht

news:411c8de9$0$192$58c7...@news.kabelfoon.nl...

[Craig Dawson]

Hi Marc,

Yes - a fair amount of them... just counted 68 bbrowsers in total
throughtout the app and many on tabwindows or in tabwindows in tabwindows...

Craig.
------

"Marc Verkade [Marti BV]" <ma...@martiXYZNOSPAMZYX.nl> wrote in message
news:411c9202$0$739$58c7...@news.kabelfoon.nl...

[Michael Rubinstein]

Phil,

> But this is exactly how VO works.... so what are you saying..VO has a
> problem. Might confirm what I am seeing.

I don't think so. I simply believe that keeping multiple references to the
same object is looking for trouble. When you place a Dialog Window (or a
Data Window) onto a Tab Control in the WED, the code generator will create a
protected variable for the tab page window. This accounts for one reference.
Another line in WED generated code
oDCYourTabControl:AppendTab(#YourWindow,oYourWindow,"Window Caption",0) in
effect creates a reference to the same object. There is nothing terribly
wrong with it, but once you start piling up your own code, there is a good
chance to screw up when you close the 'pie'. In my applications I create the
tab control in the WED, but initialize and add pages in the PostInit()
method. Instead of using protected variables to call page windows methods I
write ACCESSes using GetTabPage(). This is just a technique that in my view
is more efficient and 'clean' compared to the WED generated code. Does not
mean something is 'terribly' wrong with VO.

Michael

"Phil McGuinness" <hey...@sherlock.com.au> wrote in message

news:2o2qljF...@uni-berlin.de...

[Geoffrey M Chambers]

Is there a utility that you use to track the memory leaksge. I have an
app that displays a window with 4 tab pages. Each tab has a browser.
When I add or edit a record in the browse I open a dialog window and
add/edit in this dialog and then close it. If I open and close this
dialog multiple times (around 15) the app crashes. I must not be
closing something correctly and causing a memory leak.

"Michael Rubinstein" <m_SPAMR...@mrubinstein.com> wrote in message news:<2o2p28F...@uni-berlin.de>...

[Geoff Schaller]

Something is wrong with your apps. I have no such memory "growth" and
can account for all dynamic memory usage. But maybe its also not of
concern? I'd need to see some evidence its causing a problem.

Geoff

"Phil McGuinness" <hey...@sherlock.com.au> wrote in message

news:2o2cuhF...@uni-berlin.de:

[Geoff Schaller]

Marc,

Its your app design - pure and simple. See my note to Phil.

Geoff

"Marc Verkade [Marti BV]" <ma...@martiXYZNOSPAMZYX.nl> wrote in message
news:411bf018$0$205$58c7...@news.kabelfoon.nl:

[Michael Rubinstein]

Geoffrey,

>
Is there a utility that you use to track the memory leaksge.
>

not among VO tools I am familiar with. I keep around an 'old' Windows98
machine with resource meter always on. I started watching memory after a
colleague of mine pointed to a leak..
Opening and closing Dialog Windows should not bring a VO application to
it's knees. I have quite complex applications running for hours on new
machines and older machines alike. I open and close dialogs multiple times,
never occurred to me to count, but if there would be a problem doing so more
then 15-20 times, I would have noticed and my users would call me names on
my cell number. I also add and remove quite complex tab pages dynamically.
If there would be a major problem, I should been the first to cry. Anyway,
few simple rules. A modal dialog should be created as LOCAL object. Also, it
is easy to forget that just closing a Dialog Window does not destroy it. If
it is created as LOCAL object, GC should eventually take care of it. In a
case like you describe it makes sense not waiting for the GC to kick in and
call Destroy() after Show() and within the same method. Also, pay attention
to who owns whom. I do not use Data Windows and do not use VO DataBrowser.
Of course I did use them in the past, exterminated the beasts about 6 years
ago and never looked back. I use regular Dialog Windows. A List View is
enough for my browsing needs. For more sophisticated browsing there is
BBrowser.

Michael

"Geoffrey M Chambers" <gcham...@msn.com> wrote in message
news:9baeb1d8.04081...@posting.google.com...

[Armin Back]

HelloPhil,

I'm also using bBrowser and tabcontrols heavily and I didn't see those kind
of memory resource leaks you're descriping.

Can you send me the test app, too? I would also like to take a look at it
... probably there is a problem in VO, but to be honest I think it has to do
with something in front of the monitor <g>.

HAND

Armin

"Phil McGuinness" <hey...@sherlock.com.au> schrieb im Newsbeitrag
news:2o2qfkF...@uni-berlin.de...

[Craig Dawson]

Aha! - do you mean it could be a "PEBKAC" issue?
(Problem Exists Between Keyboard And Chair)

<BG>
Craig.
------

"Geoff Schaller" <Geoff...@softwareobjectovesNoSpam.com.au> wrote in
message news:411d6a0f$1...@dnews.tpgi.com.au...

[Marc Verkade [Marti BV]]

Test it yourself with the MDI Basic App from the galery and open and close
the about box several times...
Grtz, Marc

"Geoff Schaller" <Geoff...@softwareobjectovesNoSpam.com.au> schreef in
bericht news:411d69f1$1...@dnews.tpgi.com.au...

[Karl Faller]

Marc,

>Test it yourself with the MDI Basic App from the galery and open and close
>the about box several times...

FWIW, just tried it. Mem on Taskman rises for the first 3 or 4
openings, then it stays were it is...

HAND
Karl @ 7a, XP Home Sp1

[Craig Dawson]

Marc,
Did it about 100 times - no problem whatsoever.
Memory stayed pretty much the same. No discernable increase.
What did you get?

Running XPPro VO2.7a
Craig.

"Marc Verkade [Marti BV]" <ma...@martiXYZNOSPAMZYX.nl> wrote in message

news:411df2ea$0$203$58c7...@news.kabelfoon.nl...

[Marshall Rhinehart]

Geoffrey,

Respectfully....IMO if your app is crashing after opening a dialog 15 times,
something other than a memory leak is at work. (Your not running this on a
TRS-80 or ATARI 800, are you? <g>) If you could post some code...or if you
can put something in an AEF I would take a look.

Although I don't think this is the problem.... what kind of browser is on
the tab, and how large are the files being browsed? The dialog that pops
open for the ADD/EDIT...when you write the data to the file and close this
window, is everything getting closed up properly? Or do you reference one
server object for the browse, and use this for the popup dialog?

Once the bigger issues get sorted out, I'm interested to hear what others
have to monitor memory leakage. Would seem that a single utility would be
better than sticking debout32's all about... Did I see a thread once where
Graham M. had something for this?... well...off to Google.

Marshall

[Marshall Rhinehart]

Michael,

> same object is looking for trouble. When you place a Dialog Window (or a
> Data Window) onto a Tab Control in the WED, the code generator will create
a
> protected variable for the tab page window. This accounts for one
reference.
> Another line in WED generated code
> oDCYourTabControl:AppendTab(#YourWindow,oYourWindow,"Window Caption",0) in
> effect creates a reference to the same object. There is nothing terribly
> wrong with it, but once you start piling up your own code, there is a good
> chance to screw up when you close the 'pie'. In my applications I create
the
> tab control in the WED, but initialize and add pages in the PostInit()
> method. Instead of using protected variables to call page windows methods
I
> write ACCESSes using GetTabPage(). This is just a technique that in my
view
> is more efficient and 'clean' compared to the WED generated code. Does not
> mean something is 'terribly' wrong with VO.
>

I agree with many of your tab comments. Taken a step further, I have a base
window that I put all my tab pages on. When a tab is selected (within this
'base' window) it checks to see if there is a particular method (on the
window about to receive focus) for the selected tab, do the same thing when
exiting a tab page. Find this efficient for turning on timers, killing
timers, or any other cleanup that might make the app run better/more
responsive. Why run a timer to check for email (for example) on a tab page
that the user isn't even looking at? Just a thought.

Marshall

[Geoff Schaller]

Yep - ok - did that and see absolutely NO problem.

Next?

"Marc Verkade [Marti BV]" <ma...@martiXYZNOSPAMZYX.nl> wrote in message

news:411df2ea$0$203$58c7...@news.kabelfoon.nl:

[Geoffrey M Chambers]

Send me a message at gcham...@msn.com and I'll send you the source.