Page 1 of 1

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

Posted: Sat Apr 19, 2025 9:52 am
by 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! :D

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

Posted: Sat Apr 19, 2025 10:58 am
by 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. 

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

Posted: Sat Apr 19, 2025 11:04 am
by mk-soft
Axolotl was faster.

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

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

Posted: Mon Apr 21, 2025 9:29 am
by Andre
Thank you both! :D

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...