Illegal type conversion of "Pobjc_object"

[inferno]

Hi,
During Cocoa compilation I get many errors  about illegal type conversion of "Pobjc_object":

NSGraphicsContext.inc(334,13) Error: Illegal type conversion: "Pobjc_object" to "NSImageInterpolation"
NSGraphicsContext.inc(367,13) Error: Illegal type conversion: "Pobjc_object" to "NSCompositingOperation"
NSBox.inc(115,13) Error: Illegal type conversion: "Pobjc_object" to "NSBorderType"
NSBox.inc(120,13) Error: Illegal type conversion: "Pobjc_object" to "NSTitlePosition"
NSBox.inc(145,13) Error: Illegal type conversion: "Pobjc_object" to "NSBoxType"
NSButton.inc(198,13) Error: Illegal type conversion: "Pobjc_object" to "NSCellImagePosition"
NSButton.inc(388,13) Error: Illegal type conversion: "Pobjc_object" to "NSBezelStyle"
NSControl.inc(358,13) Error: Illegal type conversion: "Pobjc_object" to "NSTextAlignment"
NSControl.inc(468,13) Error: Illegal type conversion: "Pobjc_object" to "Single"
NSControl.inc(619,13) Error: Illegal type conversion: "Pobjc_object" to "NSWritingDirection"
NSFont.inc(474,13) Error: Illegal type conversion: "Pobjc_object" to "Single"
...

Any idea how to fix it?

Best regards,
Inferno

[Jonas Maebe]

Which FPC version are you building and how?

There is no line 334 in the NSGraphicsContext.inc of either FPC 3.2 or FPC trunk.

[inferno]

Hi Jonas,
I use FPC 3.3.1. NSGraphicsContext.inc have 376 lines. Below you have the lines where the errors are generated:

Code: Pascal  [Select][+][-]

1. function NSGraphicsContext.imageInterpolation: NSImageInterpolation;
2. begin
3.   Result := NSImageInterpolation(objc_msgSend(Handle, sel_registerName(PChar(StrNSGraphicsContext_imageInterpolation)), [])); //NSGraphicsContext.inc(334,13)    

Code: Pascal  [Select][+][-]

1. function NSGraphicsContext.compositingOperation: NSCompositingOperation;
2. begin
3.   Result := NSCompositingOperation(objc_msgSend(Handle, sel_registerName(PChar(StrNSGraphicsContext_compositingOperation)), []));   //NSGraphicsContext.inc(367,13)
4. end;  

Code: Pascal  [Select][+][-]

1. function NSBox.borderType: NSBorderType;
2. begin
3.   Result := NSBorderType(objc_msgSend(Handle, sel_registerName(PChar(StrNSBox_borderType)), []));   //NSBox.inc(115,13)
4. end;

Code: Pascal  [Select][+][-]

1. function NSBox.titlePosition: NSTitlePosition;
2. begin
3.   Result := NSTitlePosition(objc_msgSend(Handle, sel_registerName(PChar(StrNSBox_titlePosition)), []));   //NSBox.inc(120,13)
4. end;

Code: Pascal  [Select][+][-]

1. function NSBox.boxType: NSBoxType;
2. begin
3.   Result := NSBoxType(objc_msgSend(Handle, sel_registerName(PChar(StrNSBox_boxType)), []));   //NSBox.inc(145,13)
4. end;  

Best regards,
Inferno

[Jonas Maebe]

The trunk version of that file only has 83 lines: https://svn.freepascal.org/svn/fpc/trunk/packages/cocoaint/src/appkit/NSGraphicsContext.inc

The quoted code seems to come from the ancient https://wiki.freepascal.org/PasCocoa code. That has been deprecated for about 10 years now. Also, the above code is wrong. You have to typecast objc_msgSend to the signature of the called message. Calling it as a regular varargs function results wrong parameter passing (mainly on AArch64, but I think also with some types on x86-64). I have to admit I don't immediately see why it would give a compilation error now though.

[CCRDude]

Old topic, but since I and another user came across the same error, I looked for the file and found it in two locations:

fpcsrc/packages/cocoaint/src/appkit/NSGraphicsContext.inc (new)
lazarus/lcl/interfaces/carbon/pascocoa/appkit/NSGraphicsContext.inc (old)

How can one make sure FPC/Lazarus uses the new one?
Why is the old one still there?

My project has LCLWidgetType:=cocoa and seems to work; my package with the same source file didn't compile with above error. Currently it does, but I'm unsure why.

[dbannon]

...
lazarus/lcl/interfaces/carbon/pascocoa/appkit/NSGraphicsContext.inc (old)
....

That file is in the Carbon tree, my guess is you are not using carbon ?

Davo

[CCRDude]

My issue is basically: when I press "Compile" on the package window, which widgetset is used? One day, these errors occured (the IDE seemed to have used Carbon to compile), the other day they did not.
I like to click "Compile" to verify my code before I add a package to the IDE or a project.

If Carbon has been so deprecated that it cannot be used, why keep it in there at all?
But if it's basically a different version of the same file, why does Carbon not use the newer one as well?
Or maybe at least add a comment to the old Carbon file telling the user that if he's encountering an issue in this line, he probably forgot to set the widgetset to Cocoa?

I'm not using this file directly, I'm simply using CocoaAll.

And I'm not the only one affected, see this thread - someone who tried to compile my package had the same issue.

[Zvoni]

If Carbon has been so deprecated that it cannot be used, why keep it in there at all?

Backwards-Compatibility to High-Sierra and older?
https://en.wikipedia.org/wiki/Carbon_(API)

[dbannon]

My issue is basically: when I press "Compile" on the package window, which widgetset is used? One day, these errors occured (the IDE seemed to have used Carbon to compile), the other day they did not.

I'm not using this file directly, I'm simply using CocoaAll.

My guess, and its just a guess, you are probably using a Mac that does not support Carbon. So, anything that builds and runs is not using the Carbon one.

I am unsure what you mean by CocoaAll.  If (IFF) you are using LCL, on a Mac, its either Carbon (and it probably won't compile, certainly wont run on anything recent) or Cocoa (an obvious choice). You would select that in Lazarus->Project->ProjectOptions->Additions&Overrides. But if you are working directly with fpcsrc/packages/cocoaint, all bets are OFF !

Davo

[CCRDude]

I'm running Ventura, 13.6.4, while Carbon was only available until Catalina, 10.15, so that's right, my Mac doesn't support it.

CocoaAll means the name of the unit I include, and that that's my only reference to anything Mac specific. To clarify: I'm not using any NSGraphicsContext.inc specifically, but that it only got involved by referring to the CocoaAll unit.

I am using the LCL, and yes, for apps I can set Cocoa, but not for packages (which should work on multiple widgetsets, that's right, but which shouldn't fail on a post-Carbon Mac trying to compile a package!).

Here's the source I'm working on:
https://gitlab.com/ccrdude-pascal/firefly-macos
I'm trying to create a LCL component making it easier to provide a form with a NSToolbar.

Here's my thread in this forum about it:
https://forum.lazarus.freepascal.org/index.php/topic,66309.0.html
And user Hansaplast, trying up to date trunk builds of aarch64-darwin-cocoa, had the same issue with the package.

I guess it leads to this question: which widgetset does the IDE pick to compile for when compiling a package?

Once the package has been added to the current project, it will be built with the projects current setting when recompiling the project, and later probably the same when directly compiling the package, but what is when the package is really new, hasn't been added to project or IDE yet?

[dbannon]

....

I guess it leads to this question: which widgetset does the IDE pick to compile for when compiling a package?

Once the package has been added to the current project, it will be built with the projects current setting when recompiling the project, and later probably the same when directly compiling the package, but what is when the package is really new, hasn't been added to project or IDE yet?

As I understand it, a package should be widget set agnostic. But, obviously, many are not because the author has included platform or even widget specific code. For example, if you did use NSToolbar (and I understand you do not), then the package would be Mac only or you would need to add equivalent code for other platforms. So, depending on what a package does, its somewhere between trivial to make it cross platform and impossible !

Only you know whats in your package. But if it MUST be cross platform, I suggest testing early in the development process. Especially so when I hear you muttering words like NSToolbar. Generally, if you stick to LCL components and don't hit platform specific API, the result should be down towards the trivial end of the spectrum.

Davo

[CCRDude]

I think we're still speaking past each other, but your answer lead me into a possible "solution" or "workaround".

I'll wrap my code into {$IFDEF LCLCocoa} to avoid that it causes this issue. I might also add a warning into a {$IFDEF LCLCarbon} that the mac user needs to use Cocoa instead of Carbon.

...

My main issue was user friendliness, and it seems even on a Cocoa IDE, Carbon might be preselected if the user does not manually pick a widgetset.

And an option to compile packages against different targets instead of the one currently active in the active project would be something helpful as well, but not a necessarity

[dbannon]

My main issue was user friendliness, and it seems even on a Cocoa IDE, Carbon might be preselected if the user does not manually pick a widgetset.

I was under the impression that was fixed in Lazarus 3.0, but don't know, I very rarely initiate a new project on the mac.

And an option to compile packages against different targets instead of the one currently active in the active project would be something helpful as well, but not a necessarity

Thats why Lazarus has 'modes'. Button to the left of the green triangle "run", selects the mode. You setup a mode for every type of build you want. You can setup target, binary name, widget set, debug and release modes and even specific defines if you wish. If you have setup your FPC to be able to cross compile, you can build cross compiled binaries that way, else its a case of taking the sourse set to another machine.

Davo

[CCRDude]

Default for projects is Cocoa, I just checked. Bad assumption on my part then.

Thats why Lazarus has 'modes'.

I use modes quite a lot, sometimes cross-compiling from Win32 to Win64, Linux and rarely macOS, having debug and release modes.

But how does that selection affect package compilation? The code as part of a project compiled, the code as part of a package open at the same time failed with this error.

[dbannon]

I use modes quite a lot, sometimes cross-compiling from Win32 to Win64, Linux and rarely macOS, having debug and release modes.

But how does that selection affect package compilation? The code as part of a project compiled, the code as part of a package open at the same time failed with this error.

Not sure how others work, but I would get the code working as an application first, tested as much as possible on all the needed platforms and only think about packaging once the core code is proven.

Then, when testing a package, you would normally use that package in an application, and that application, again, can have 'modes'.

My real point was the importance of cross platform testing, one way or another, early in the process and sticking with LCL components.

Davo