@Callback() references in Macros - changes with PB6.21 ?

[Andre]

Hello all,

while PB6.21 is mostly running well I have a problem with some new behaviour introduced with PB6.21...

The following snippet is taken from a large module, which was running fine until PB6.20.
But now causes an error message with the debugger (see the comment in the code), while it's still running without debugger.

Do I need to change all codes written in this way, and how? Or could it be a debugger problem?

Code: Select all

Macro filter(callback, lParam=0)                           
  to_filtering=lParam                                      
  CustomFilterCallback(callback)
EndMacro                                                           

Procedure filter_callback_1(x, y, source_color, destination_color)
  ; do some stuff...
  ProcedureReturn source_color
EndProcedure


OpenWindow(0, 0, 0, 300, 200, "Test", #PB_Window_SystemMenu)
StartDrawing(WindowOutput(0))
  filter(@filter_callback_1(), invisible_color_)   ; <= gives a "CustomFilterCallback(): the procedure given in @Callback() doesn't have the needed argument or return value" error!
StopDrawing()

Repeat
  event = WaitWindowEvent()
Until event = #PB_Event_CloseWindow

Thank you for your help and Happy Eastern!

[Axolotl]

Hi Andre,
I have no idea what this code does, but with this changes I can run your example code....
(w/o the change I got the same error you mentioned.)

Code: Select all

filter_callback_1(x, y, source_color.l, destination_color.l) ; <== .l instead of .i which is the default. 

[mk-soft]

Axolotl was faster.

Rules have been added to all callbacks that the parameter types must be correct.

[Andre]

Thank you both!

Using the ".l" convention works... allthough I've now other anomalies using the large code I use (GFZ_Wizzard module), so I've to investigate further...