Author Topic: Weird issue with callback functions  (Read 1582 times)

0 Members and 1 Guest are viewing this topic.

Brian Alvarez

  • Guest
Weird issue with callback functions
« on: January 08, 2019, 11:17:37 AM »
 Hello Charles, i am experiencing an issue with a callback function. I am trying to get an example to
work:

http://www.jose.it-berater.org/smfforum/index.php?topic=5438.msg23730#msg23730

But, even though everything seems fine, it doesnt work as expected.

This line of code:

Code: [Select]
origlvproc = SETWINDOWLONG(hlistview, GWL_WNDPROC, @NEWLVPROC)   
Is supposed to subclass a listview, when NEWLVPROC is a callback function declared as follows:

Code: [Select]
FUNCTION NEWLVPROC(SYS hwnd, DWORD msg, SYS wparam, SYS lparam) AS INT
NEWLVPROC never gets fired, in fact there is absolutely no action on that function.

 However, when the function is a callback, as follows:

Code: [Select]
FUNCTION NEWLVPROC(sys cbhndl, uint cbMsg, sys wParam, sys lParam) as int callback
 The messages come trough just fine.

 Normally that would fix the issue. However, there are tons of code that uses regular functions as callback functions, and i would like to be able to port those as well. Do you know what is going on in the background? As far as i know a uint = dword, so, i have no idea what is happening. In fact, compiling the exact same code in PowerBASIC causes the exact oposite, fails with callback and works with regular functions. And other oposite stuff as well.

 Thanks for any help. :)
 


« Last Edit: January 08, 2019, 11:32:12 AM by Brian Alvarez »

Brian Alvarez

  • Guest
Re: Weird issue with callback functions
« Reply #1 on: January 08, 2019, 07:55:51 PM »
I believe being able to use non-conventional callback functions is important, because there is a number of system API's that require having callback functions with different parameter configurations. Even one of the sorting features requires this.

Charles Pegge

  • Guest
Re: Weird issue with callback functions
« Reply #2 on: January 08, 2019, 08:46:24 PM »
Hi Brian,

In o2, callback functions preserve the ebx, esi and edi registers, whereas normal internal functions do not.

To make any set of functions fit for callbacks, you can put them into an extern block, so that external callers won't get these registers messed up.

extern
...
end extern

Brian Alvarez

  • Guest
Re: Weird issue with callback functions
« Reply #3 on: January 09, 2019, 05:28:20 AM »
Thanks Charles, i will see how can i implement this to be done automatically... :)

Brian Alvarez

  • Guest
Re: Weird issue with callback functions
« Reply #4 on: January 09, 2019, 05:51:35 AM »
Ok, from now on, when a function is used with CODEPTR, the function will be generated between extern/end extern tags.