Could someone else try and get some example to Peter please. If needed, send him the Lazarus code and pinpoint the location. I think I may have found the other problem with the gtk_widget_show error and I am stalking that.

Thanks
Shane

I built a new one but I'll try it again.

Shane

>> "Michael A. Hess" 07/08 1:34 PM >>>

Shane Miller wrote

Is there still an issue when using more than one procedure? When I comment out the other 3 it compiles.

Did you build a new compiler out of CVS? Peter just fixed this this morning. At least that is what he reported.

I just built a new one from CVS and it din't help.

I did

cvs co base compiler gtk fcl rtl
make clean
cd compiler
make cycle

It made a new compiler, but it still crashes after doing the TFOrms class if I have more than one message procedure.

Shane

>> "Michael A. Hess" 07/08 1:34 PM >>>

Shane Miller wrote

Is there still an issue when using more than one procedure? When I comment out the other 3 it compiles.

Did you build a new compiler out of CVS? Peter just fixed this this morning. At least that is what he reported.

I won't be back in my office for another 2 1/2 hours at the least so I can't do it until then. However, given what you have found so far with the DispatchStr('resize') crash I tend to think that we might be do some bad pointer passing or something and stomping on memory that is just plain messing everything up. StrPCopy was first and we by passed that only to find something else that got messed up. Since a smaller program StrPCopy does work I am leaning towards it being our problem. We are going to have to isolate parts of the code little by little until we find it. :-\

Here is a test program I made:
------------------------------------------------------- Program Example46;

{ This program demonstrates the StrBufSize function }
{$H+}
Uses heaptrc,sysutils;
Procedure DoTest;
Const S  = 'Some nice ansi string';
Var P : Pchar;
    SS : AnsiString;
Begin
   SS:=S+'!!!';
   P:=StrAlloc(Length(SS)+1);
   StrPCopy(P,SS);
   Write (P, ' has length ',length(SS));
   Writeln (' and  buffer size ',StrBufSize(P));
   StrDispose(P);
End;
Var L : longint;
begin
  L:=Memavail;
  Writeln('Mem :',L);
  DoTest;
  Writeln ('Mem : ',Memavail,' or lost ',L-Memavail,'bytes');
end.
------------------------------------------------------------

here is the output:

------------------------------------------------------------ home: >ex46
Mem :262016
Some nice ansi string!!! has length 24 and buffer size 25 Mem : 262016 or lost 0bytes
Heap dump by heaptrc unit
7 memory blocks allocated : 125/144
5 memory blocks freed : 101/112
2 unfreed memory blocks : 24
True heap size : 262144
True free heap : 262016
Should be : 262016
Call trace for block 0x08062600 size 12
0x080592E2
0x080551A0
0x08053B09
0x08053C04
0x08058D65
0x0805D49F
0x080480A4
Call trace for block 0x080625C0 size 12
0x080592E2
0x080551A0
0x08053AF1
0x08053C04
0x08058D65
0x0805D49F
------------------------------------------------------------

Remark the '0 bytes lost.'

The 2 allocated blocks that heaptrc cmplains about are because 2 exception objects that are allocated in iitialization code of the sysutils unit are never freed (no finalization code yet), they have nothing to do with the StrPCopy.

Michael.

I'll fix those things. heaptrc also needs to be adapted to use finalization.

Shane I do not know if this is the problem but what I had to do is put a call into TApplication.Create to ObjectInterface.Init to initiale the gtk engine properly. If this was not there It would throw the end of exception stack error because it was actually making calls to gtk and the engine was not initialized yet...

Cliff

It appears to me that this is being done in TApplication.Create by calling InterfaceObject.Init. The gtk stuff is being set there.

I will update CVS with the latest so othersa can look.

In this version I converted all the message procedures to " message LM_SHOW" or something like that, where LM_SHOW is an integer value. Then all I need to do is call Dispatch. Of course this doesn't work because of a problem of having multiple message procedure's in the same class. So I commented all of them out of TFORM except one.

Hopefully that problem will be fixed soon.

Shane

>> "Baeseman, Cliff" 07/08 2:53 PM >>>

Shane I do not know if this is the problem but what I had to do is put a call into TApplication.Create to ObjectInterface.Init to initiale the gtk engine properly. If this was not there It would throw the end of exception stack error because it was actually making calls to gtk and the engine was not initialized yet...

Cliff

I have updated CVS with my latest. Minor changes were made.

This version has the first 2 messages in TForms uncommented and it compiles. If I uncomment the third or fourth message procedure, it doesn't compile.

When you try to run it, you get the ExceptionAddressStack error when the resize message is trying to be Dispatched in GTKINT.pp

Any help to figure out what the problem is will be greatly appreciated.

I'll be on this weekend, until the 'wee' hours of the night as usual.

Shane

1) I am on my work PC so I am not getting the "static link" error ) Hard coding it so it says

 Procedure Something(var msg); Message 1;
 Procedure Something(var msg); Message 2;
 Procedure Something(var msg); Message 3;
 Procedure Something(var msg); Message 4;
 still makes it crash, yet commenting out the last two and it'll compile.

Shane

>> "Michael A. Hess" 07/09 11:34 AM >>>

You don;t think this has something to do with that can't link static message with regards do lmessages unit to you?

What if you tried hard coding the numbers into the messages and don't use the LM_DESTROY, etc.

Shane Miller wrote

still makes it crash, yet commenting out the last two and it'll compile.

Dang. :-(

When I did my test program I originally was trying 4 messages and that is when we found the problem. However when I tested it last night I was only doing it with 2. Maybe it does crap out with more than 2. I won't be able to test my machine until later this afternoon.

However, I do find it strange that on one machine you get the static link error message yet on another you do not. :-\

you wrote

I JUST did a CVS and make cycle and I still get the error with the multiple "message" procedures in a class.

Are you sure you're using the latest compiler? (using -l you can see the date the compiler was build).

It may not be strPCopy.

I have a possibly related question.

I converted all the

Procedure something(var msg); message 'resize';

to

Procedure Something(Var msg); Message LM_RESIZE;

where LM_RESIZE = $101

then instead of doing a DispatchStr('resize') I do a Dispatch(LM_RESIZE).

One problem I found was I had to assign a local variable to LM_RESIZE first, then use that in the Dispatch procedure. Now I get a

PANIC : Internal compiler error, exiting
forms.pp(52,5) Fatal: Internal error 9999

Line 52 is the end of the class definition for TFOrms which uses 4 different message procedures.

Is there still an issue when using more than one procedure? When I comment out the other 3 it compiles.

Shane

It is all landing here before getting to you....

That should bring us up to about 4 inches in the last two days..

Cliff "Starting to float!"

Cliff wrote

cool I will be on it all weekend.

I just made a bunch of changes to how the Init stuff takes place. I'll commit it in a few minutes.

BTW another storm headed your way we just got annother 2 inches of rain..

Man I wish we could get some of that rain you guys are getting. We haven't had rain here in over 2 weeks. Talk about things getting dry.

cool I will be on it all weekend. BTW another storm headed your way we just got annother 2 inches of rain..

Cliff

It IS a problem though. It throws an error if I have more than one in a class definition. This is done with FPC from CVS yesterday, not today, so perhaps something haas changed but I am not aware of the fix.

I commented out all but one of them and then it compiles.

You mentioned that InitProcedure.Init (or something) isn't being called? How do I fix it? The error with the exceptonaddressspace is still appearing.

Shane

>> "Michael A. Hess" 07/09 8:42 AM >>>

Shane Miller wrote

I updated CVS now so you can pull the latest source.

I'll get it as soon as I hit my office this afternoon. :-)

Not sure if this is the best idea seeing as though I believe there's still a problem with having multiple "message" procedure's in a class definition.

Shouldn't be a problem. As I stated last night I modified my msgtest program to use Dispatch with several messages. I was able to Dispatch to every one of them.

The StrPCopy simply does the following:

function StrPCopy(Dest: PChar; Source: string): PChar;
begin
  result := StrMove(Dest, PChar(Source), length(Source));
end ;

It seems rather strange that this would go wrong, since strmove has been around and tested for ages.

Michael.

This is the case.

Shane

the dispatchstr bug is not solved yet!

Yup Shane, you are correct. I just ran a test with my msgtest program and when I try to do it with more than 2 the compiler burps with a "9999".

Peter any clue on this one?

Peter Vreman wrote

the dispatchstr bug is not solved yet!

Sorry about that. Now I remember that you did say that you had identified it but not fixed it yet. Sorry about the mislead.

You don;t think this has something to do with that can't link static message with regards do lmessages unit to you?

What if you tried hard coding the numbers into the messages and don't use the LM_DESTROY, etc.

Did you get my mail from last night?

I indicated that I cycled a new compiler out of CVS last night sometime around 8:00-9:00. When you do that do a "make clean" of everything first. That is the RTL, GTK, compiler, etc.. I think Peter said that a change was made to the ppu format. He didn't correct me from last nights email so I still assume that might be correct.

Anyway I cycled the new compiler, rebuilt all the RTL, GTK, FCL units and then tried to compile my msgtest program which sets up multiple messages in one class file. The same test that failed before. Now it compiles and now the program runs and does Dispatch to every message when called.

I commented out all but one of them and then it compiles.

This has definitly been fixed.

You mentioned that InitProcedure.Init (or something) isn't being called? How do I fix it? The error with the exceptonaddressspace is still appearing.

TApplication.Initialize()

calls the initprocedure thusly

if InitProcedure  nil then TProcedure(InitProcedure);

InitProcedure is a pointer that is defined in interfaces.pp. In the initialization section of the interfaces unit it sets the value of InitProcedure to point to the the procedure that contains the gtk_init call. The problem is that the order of unit start up has now been muddled and TApplication.Create resets InitProcedure to nil.

To get around the problem until I make a fix comment out the line

InitProcedure := nil;

in the Tapplication section of forms.pp.

Once I get the code out of CVS I'll fix it up so that it works correctly.

I assume that this might fix the exception error but I don't know. As another alternative you can leave the InitProcedure := nil line and add a call to the procedure that has gtk_init in it.

Since it appears that there might have been a bug in StrPCopy and DispatchStr according to Peter you might definitly cycle out a new compiler before doing anything else.

This is interesting.

I am using
Procedure Something(var msg); Message LM_RESIZE;
Procedure Something(var msg); Message LM_SHOW;
Procedure Something(var msg); Message LM_DESTROY;
Procedure Something(var msg); Message LM_FOCUS;

in my TForms class.

In LMessages.pp I declare
LM_USER = $10;
LM_RESIZE = LM_USER+1;
LM_SHOW = LM_USER+15;
LM_DESTROY = LM_USER+2;
LM_FOCUS = LM_USER+6;

When I have the last two commented out, it compiles. But if I uncomment the LM_DESTROY one, it crashes with Panic: Internal compiler error, exiting
forms(52,5) Fatal: Internal error 9999

Line 52 is the end of TForms class declaration.

Thoughts?

Shane

Shane are you going to work from the CVS now. I will jump back in if this is the case and
maybe help you guys resolve the issues...

cliff

Yes, I am sure. the data stamp is 1999/07/09

Test it with more than 2 messages. It still crashes (at least for me).

Shane

>> Peter Vreman 07/09 11:45 AM >>>

you wrote

I JUST did a CVS and make cycle and I still get the error with the multiple "message" procedures in a class.

Are you sure you're using the latest compiler? (using -l you can see the date the compiler was build).

_________________________________________________________________ To unsubscribe: mail with
"unsubscribe" as the Subject
archives at http://www.miraclec.com/list_archives/lazarus

I JUST did a CVS and make cycle and I still get the error with the multiple "message" procedures in a class.

Shane

>> "Michael A. Hess" 07/09 9:42 AM >>>

Did you get my mail from last night?

I indicated that I cycled a new compiler out of CVS last night sometime around 8:00-9:00. When you do that do a "make clean" of everything first. That is the RTL, GTK, compiler, etc.. I think Peter said that a change was made to the ppu format. He didn't correct me from last nights email so I still assume that might be correct.

Anyway I cycled the new compiler, rebuilt all the RTL, GTK, FCL units and then tried to compile my msgtest program which sets up multiple messages in one class file. The same test that failed before. Now it compiles and now the program runs and does Dispatch to every message when called.

I commented out all but one of them and then it compiles.

This has definitly been fixed.

You mentioned that InitProcedure.Init (or something) isn't being called? How do I fix it? The error with the exceptonaddressspace is still appearing.

TApplication.Initialize()

calls the initprocedure thusly

if InitProcedure  nil then TProcedure(InitProcedure);

InitProcedure is a pointer that is defined in interfaces.pp. In the initialization section of the interfaces unit it sets the value of InitProcedure to point to the the procedure that contains the gtk_init call. The problem is that the order of unit start up has now been muddled and TApplication.Create resets InitProcedure to nil.

To get around the problem until I make a fix comment out the line

InitProcedure := nil;

in the Tapplication section of forms.pp.

Once I get the code out of CVS I'll fix it up so that it works correctly.

I assume that this might fix the exception error but I don't know. As another alternative you can leave the InitProcedure := nil line and add a call to the procedure that has gtk_init in it.

Since it appears that there might have been a bug in StrPCopy and DispatchStr according to Peter you might definitly cycle out a new compiler before doing anything else.

That should be getting called from the Initialization method of TApplication. I'll do a check and see if that is working.

Shane Miller wrote

I updated CVS now so you can pull the latest source.

I'll get it as soon as I hit my office this afternoon. :-)

Not sure if this is the best idea seeing as though I believe there's still a problem with having multiple "message" procedure's in a class definition.

Shouldn't be a problem. As I stated last night I modified my msgtest program to use Dispatch with several messages. I was able to Dispatch to every one of them.

Sorry about the disconnect yesterday. I had to run then wasn't able to use my computer because of the weatther.

I updated CVS now so you can pull the latest source.

I changed all the DispatchSTR's to Dispatch's and am passing an integer now (LM_SHOW = $102, etc)

Not sure if this is the best idea seeing as though I believe there's still a problem with having multiple "message" procedure's in a class definition.

Take a look

Shane

Shane Miller wrote

Is there still an issue when using more than one procedure? When I comment out the other 3 it compiles.

Did you build a new compiler out of CVS? Peter just fixed this this morning. At least that is what he reported.