I've posted this on the MadExcept newsgroup as well, but I'm spreading the net

I spent about 4 hours today trying to identify a problem and came to the reluctant conclusion its related to MadExcept.

As part of a rather large app I've developed my own date/time lookup. Its based on MustangPeak's DropDownForm and uses TMS components for prettyness. There are two variants non-data aware and data aware.

In the IDE everything works as it should. I click on the lookup, select the date and time, click the ok button and the date and time appears in the field before me. Outside the IDE I (sometimes) just get a blank field.

I had this happen today and decided to track it down. I planted showmessages through the lookup code all of which confirmed that the date and time were being correctly set (had to use show message cos it works in the IDE grrrr). Did much the same to the form in the app but could not isolate where the change to a blank data/time was happening.

Then I decided to remove FastMM, still had the problem, finally removed MadExcept and problem solved.

Its made even more confusing by the fact that this form is used in four places with the difference being the sql used to generate the list. On three forms things work as they should, on the fourth they don't.

Any ideas?

Roy Lambert

Roy,

<< Then I decided to remove FastMM, still had the problem, finally removed
MadExcept and problem solved. >>

I wouldn't necessarily consider MadExcept the issue for sure.  The
inclusion/exclusion of MadExcept could simply change around the memory
allocation in a way that covers up the issue, which may be simply related to
an error in the component itself.  For example, the component may be trying
to access a freed variable and, with MadExcept in place, can do so because
that allocated block of memory is still hanging around in FastMM4 and hasn't
been re-used.  But, with MadExcept in place, the memory block is re-used or
re-initialized, resulting in no data.

I guess it all depends upon how complicated the actual component is.  If it
is particularly complicated, then it is likely that the above is the issue.
If it is simple, than the above is probably not correct, and MadExcept may
indeed be the issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>I wouldn't necessarily consider MadExcept the issue for sure. The
>inclusion/exclusion of MadExcept could simply change around the memory
>allocation in a way that covers up the issue, which may be simply related to
>an error in the component itself. For example, the component may be trying
>to access a freed variable and, with MadExcept in place, can do so because
>that allocated block of memory is still hanging around in FastMM4 and hasn't
>been re-used. But, with MadExcept in place, the memory block is re-used or
>re-initialized, resulting in no data.
>
>I guess it all depends upon how complicated the actual component is. If it
>is particularly complicated, then it is likely that the above is the issue.
>If it is simple, than the above is probably not correct, and MadExcept may
>indeed be the issue.

The component is medium complexity, the form it sits on is also medium complex, and the assumption that its my code that's the problem is why I spent four hours on it. It wasn't until I tried the same component on a different instance of the form where it worked that I started to become really paranoid.

The difference between the four instances I tested is 1) the sql used to generate a memory table, 2) a filter applied to the memory table, 3) the ADVOfficePage its instanciated on and 4) two lines of code different in an afterpost event.

My paranoia even reached the point where I disable the filter "just in case"

Roy Lambert

Roy,

<< The component is medium complexity, the form it sits on is also medium
complex, and the assumption that its my code that's the problem is why I
spent four hours on it. It wasn't until I tried the same component on a
different instance of the form where it worked that I started to become
really paranoid. >>

Did you try breaking out the component on a test form/project and then
adding back in the code little by little ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Did you try breaking out the component on a test form/project and then
>adding back in the code little by little ?

Thought about it and decided not to for four reasons a) its not consistently repeatable b) the amount of code potentially involved c) I would need to add to much code back in a block and d) it works fine in the IDE which makes adding bits of code back in even more time consuming

One thing I have done is add a check constraint in so I now get warned rather than clicking a sequence quickly and things getting screwed.

Roy Lambert

From my post on the MadExcept ng


After many hours of showmessage delirium I think I have found the answer. In a function I wasn't explicitly setting Result at the top and there were some exit points where it wasn't set. Added a Result := True and now it seems to work. If I'm right (and only time will tell) then all that's left is my puzzlement as to why Result seems to be initialised differently in different circumstances.

Roy Lambert

Roy,

<< After many hours of showmessage delirium I think I have found the answer.
In a function I wasn't explicitly setting Result at the top and there were
some exit points where it wasn't set. Added a Result := True and now it
seems to work. If I'm right (and only time will tell) then all that's left
is my puzzlement as to why Result seems to be initialised differently in
different circumstances. >>

It's like I said - variables that are uninitialized can point to various
areas of memory, some of which may have had data in them at some point, and
some that may not have.  Just changing around a few lines of code can cause
the variable to be allocated from a different location in memory, thus
changing it's possible state.  This is why the compiler complains about
uninitialized variables so much - they can be very hard to track down.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


Out of interest do you know what is in memory for True and False?

Roy Lambert

Roy,

<< Out of interest do you know what is in memory for True and False? >>

For at least D7 or higher, it's 1 for True and 0 for False.  You can always
use this code to find out:

  ShowMessage(IntToStr(Byte(False)));

--
Tim Young
Elevate Software
www.elevatesoft.com

By default with Delphi 7 and up from what I've seen is the default value of a boolean is false.

Jud Cole, from Sock Software (CodeHealer), was in Seattle doing a presentation at our Delphi Users Group. He did a part session on some "good habit coding",  and pointed out that it's good practice to manually initialize variables to insure you get what you think.  Also to have the results of any function call be assigned to a variable, even if you're not using them, to insure keeping down memory leaks and such.

Drawback is you get warnings sometimes pertaining to these as the compiler doesn't grasp the big picture in that while you know you don't need it, you are insuring the values is set how you want.

Lance

>>Out of interest do you know what is in memory for True and False?