Ignored RECT commands

[LarryMc]

My program had a parent window and 21 child windows that I shuffle in and out.

All 21 child windows use RECT commands.
The last 2 windows I was setting up would not show the RECT command results but the other 19 almost identical commands worked fine.
Moved the last 2 to the head of the init process and now all of them display fine.

Strange.

Larry

[Ionic Wind Support Team]

Did you have a question Larry? 

What you are experiencing is not strange, in fact it is more common then you may realize.  When you corrupt memory just moving code around can change the symptoms.  Because you are changing the addresses where that code existed.

Memory corruption/overwrites is the #1 software problem and can lead to strange exceptions, usually involving the system heap when a simple allocation will fail.  It can also lead to GDI commands failing, bitmaps failing to load, etc.  And 99% of the time the corruption is happening in a completely unrelated section of code, which invariably leads you chasing false leads.

In your previous posting the debugger reported such a corruption, where you were writing past the end of allocated memory.  ListCreate uses NEW to allocate memory for the head of the list, and it is a false lead. Until you nail that down you will continue to experience strange symptoms, no getting around it you will need to do some intensive debugging to find it.  Part of my contract work was finding bugs like this.  A couple of them took weeks to track down because of the sheer amount of code we were dealing with.  And usually it turned out to be something very simple, writing to a non existent array index, exceeding a strings length, or writing past memory allocated with NEW.  In one case it was a matter of a calculation that was wrong, a buffer passed to an API function and the size given to that API function was 1 off, causing Windows itself to corrupt memory.

I can't tell you were your corruption is, without spending a lot of time with your code, but I can tell you that you need to be methodical. Start with every instance of NEW/DELETE and go through them one at a time.  Then go onto arrays and check all possibilities of exceeding the dimensions.  Then move onto strings, common problems include: not accounting for a NULL, using STRING for file paths when you really need to account for 260 characters (MAX_PATH), or exceeding the limits of a dimensioned string. 

If you do get the debugger to report a heap corruption then start commenting out code, eliminating subroutines until you get a clean debug run.  The last section you commented will contain the overwrite.

Paul.

[LarryMc]

Found 2 problems which made it a lot more stable.

Moved the 2 windows I was having problems with back to the tail in where they were and recompiled.
Now all the 21 child windows think they are parents.

I use some pretty big UDT's for file I/O. and shuffling that info from/to the controls on the 21 child windows.

I guess I'll start stripping stuff out till I find it.
Like you indicated, it isn't going to be easy since everything is intertwined and I'm around 7,000 lines of code now.

Thanks for 'splaining.

Larry

[LarryMc]

Seems I had some luck.
1. I had a counter value off by one that was used to set values in an array of UDT. -
That was the one that was giving me the "modify heap" error message.

2. Heap underflow errors.
I had some code that looked like this

Code Select Expand

mysub(a$:string,b$:string,c:int byref,d:int byref)
  string z=a$
  modify z.blah blah blah
  return
endsub
and then calling it like this in 15 different places

Code Select Expand

mysub(getcontroltext(mywin,mycontrol)),bi$,v1,v2)

had to change to this

Code Select Expand

mysub(a$:string,b$:string,c:int byref,d:int byref)
  modify a$  blah blah blah
  return
endsub
and then call it like this

Code Select Expand

string t$
t$=getcontroltext(mywin,mycontrol))
mysub(t$,bi$,v1,v2)

That made all the heap underflows go away.

see this thread for related info: http://www.ionicwind.com/forums/index.php/topic,3212.msg26234.html#msg26234

Larry