Mac osx callback functions parameters: wrong values in 386 mode.

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Mac osx callback functions parameters: wrong values in 386 mode.

fpanasiti@tiscali.it
Using control callback function with a control (a button) apparently
results in wrong
parameter values when compiling to 386 (values are correct compiling
to
ppc).

The attached case refers to a callback procedure myActionProc
(lControlRef: ControlRef; PartCode: ControlPartCode) applied to a push
button. Essentially:
- Compiling to ppc, everything is correct (in particular PartCode=
10)
- Compiling to 386, the value of lControlRef is correct, but the
value of PartCode is wrong (a random value)

As I  got the same results (first parameter, i.e. the ControlRef,
correct, others wrong) with callbacks with more parameters (as the ones
used with DataBrowser), it would seem related to different
architecture's parameter passing modes, but I couldn't get it out.

Thanks in advance for any suggestion.

Regards
Francesco Panasiti
=============================================================
(The following code is derived from the default FPC Carbon
Application 2.4.0 template).
unit MainUnit;
interface
procedure RunMainProcedure;
implementation
uses
    MacOSAll;
procedure RunMainProcedure;
var
    err : OSStatus;
    nibRef : IBNibRef;
    window : WindowRef;
    lRect: Rect;
var
    theControlRef: ControlRef;
    lControlActionUPP: ControlActionUPP;
procedure myActionProc (lControlRef: ControlRef; PartCode:
ControlPartCode);
var
    lstring: string;
begin
    MoveTo(7, 280);
    Str(partCode, lstring);
    DrawString(lstring);
end;
begin
    // Create a Nib reference passing the name of the nib file
(without the .nib extension)
    // CreateNibReference only searches into the application bundle.
    err := CreateNibReference(CFSTR('main'), nibRef);
    // Once the nib reference is created, set the menu bar.
"MainMenu" is the name of the menu bar
    // object. This name is set in InterfaceBuilder when the nib is
created.
    err := SetMenuBarFromNib(nibRef, CFSTR('MenuBar'));
    // Then create a window. "MainWindow" is the name of the window
object. This name is set in
    // InterfaceBuilder when the nib is created.
    err := CreateWindowFromNib(nibRef, CFSTR('MainWindow'), window);
    SetRect(lRect, 10, 100, 110, 200);
    theControlRef := NewControl(window, lRect, 'OK', true, 0, 0, 1,
kControlBevelButtonNormalBevelProc, 0);
    lControlActionUPP:= NewControlActionUPP(ControlActionProcPtr
(@myActionProc));
    SetControlAction(theControlRef, lControlActionUPP);
    // We don't need the nib reference anymore.
    DisposeNibReference(nibRef);
    ShowWindow(window);
    SetPort(GetWindowPort(window));
    RunApplicationEventLoop;
    Halt(byte(err));
end;
end.
=============================================================
program Start;
uses
    MainUnit;
begin
    RunMainProcedure;
end.
=============================================================


Risparmia con Tutto Incluso Light: telefono + adsl 8 mega a soli 19,95 € al mese per un anno!SCONTO DI 120 EURO! http://abbonati.tiscali.it/telefono-adsl/prodotti/tc/tuttoincluso_light/?WT.mc_id=01fw
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Mac osx callback functions parameters: wrong values in 386 mode.

Jonas Maebe-2

On 06 Sep 2010, at 17:21, [hidden email] wrote:

> Using control callback function with a control (a button) apparently
> results in wrong
> parameter values when compiling to 386 (values are correct compiling
> to ppc).

The default calling convention on non-i386 platforms is mostly the same as the C calling convention. On i386, it's different for Delphi compatibility. Add the "mwpascal;" modifier at the end of the function declaration to get the same calling convention behaviour as with MetroWerks Pascal (that's also the calling convention expected by the declarations in the macosall unit).

>    lControlActionUPP:= NewControlActionUPP(ControlActionProcPtr
> (@myActionProc));

By adding an explicit typecast you make it impossible for the compiler to tell you that the routines are incompatible. Remove the ControlActionProcPtr typecast, and if you are using MacPas mode then also remove the "@". The compiler will then give an error if the callback's signature is wrong, and it will also print the signature of the expected type.


Jonas_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal