Well the exact same problem exists on dapper too as mentioned above I will download his package now and begin investigation...
EDIT:
Ok I think it is a serious problem, however I had luck and could find some things out.
I startet the PB code with the Debugger, all works well until one clicks a button, then the Debugger show a Memory access violation at the end of the procedure. I know nothing about gtk and have never used it howeverr I suspected that the callbacks are called by the signal handlers
Code: Select all
g_signal_connect_object_( *toolbutton1, "clicked",@on_toolbutton1_clicked(),#Null, #Null);
so I removed all of the signal connects and ran again now I couldn crahsh it, so I enabled the first one and added a few simple commands to it and a CallDebugger in the beginning. This showed that the commands are run, and it crashes only at the ProcedureReturn. Though I know very little ASM I suspected that ProcedureReturn uses the assembler "ret" menemonic so I added !ret between the commands and this lead to:
Code: Select all
Procedure on_toolbutton1_clicked (toolbutton,user_data)
;Your code here
CallDebugger
a.l=10
b.l=20
Debug a+b
Debug b-a
!inc eax
debug a*b
!ret
c.l=10
d.l=20
Debug c+d
EndProcedure
Again stepping through this part of the code showed that it is now crashing at the !ret instruction. This leads to the conclusion that the problem is that the processor doesn't know where to jump when a ret happens. As I said I know nothing about asm, but I suspect that it has to do with how the procedure is called, as far as I know this is called the calling convention and it seems that different GTK versions use different calling conventions. And that PB is using a different one. I will now try to declare the callback as ProcedureC and report wether this solves the problem...
I hope this news may help you walker or maybe even Fred, since he might run into the same problem.